Blog Posts in April 2009
If you use multiple SNMP servers in your network, you might want to limit the traps each server receives. Configuring this functionality is easy: just list the traps you want a server to receive at the end of the snmp-server host configuration command.
When you specify the list of SNMP trap types a server should receive, a trap is sent to the server only if it’s listed in the snmp-server host command and enabled with the snmp-server enable traps command.
After I wrote the OSPF router ID selection trivia post, I wanted to figure out all the details of the OSPF router ID selection algorithm. As I’ve expected, the common wisdoms are mostly correct, but they fail to cover the interesting border cases.
Here’s the complete algorithm (as seen from the outside):
The Shortest Path First (SPF) algorithm used by all (read: both) popular link-state routing protocols should be well-known to all network engineers, but the fact that the IP routing table gets populated by a distance-vector-like second phase of the algorithm is oft forgotten.
Check this short presentation in case you’d like to get a bit more in-depth explanation of the SPF algorithm.
The second phase of the link state route selection algorithm is called Partial SPF in OSPF and Partial Route Calculation (PRC) in IS-IS. Obviously it’s beneficial if the router can react to a change in the network topology by running PRC, not the full SPF, and there are significant differences in the way OSPF and IS-IS respond to various topology change events. The differences are not architectural; you could make OSPF behave as well as IS-IS. They just prove that the old wisdom is still true: very large IOS-based networks use IS-IS because it’s better implemented than OSPF.
True or false: If you have an (enabled) loopback interface configured on the router, its IP address will always be used as the OSPF router ID.
IOS can generate numerous SNMP traps, but you have to enable most of them manually. Configuring a server that receives SNMP traps with the snmp-server host address community traps is not enough; you have to enable individual trap categories with the snmp-server enable traps group [ trap ] command.
In older releases, the standard SNMP traps (for example, link up/down traps) are enabled by default and cannot be disabled with the snmp-server enable traps command. Newer IOS releases have added the snmp-server enable traps snmp [ authentication | coldstart | linkdown | linkup | warmstart ] global configuration command. These releases require you to enable standard SNMP traps manually; otherwise the router will not generate them.
If you want to see the whole list, configure snmp-server enable traps and execute show running | include snmp-server enable. IOS 12.4T network management reference guide also includes a comprehensive list of all options.
My regular readers are probably not surprised to learn that I dislike buzzwords and marketectures. I’ve heard so much about Carrier Ethernet in the last few years (not including confusing definitions of what it’s supposed to be) that I decided to write an article about it. It was recently published by SearchTelecom as “Carrier Ethernet: Big picture issues for carrier deployment”.
One of the readers of my “When would an MPLS LSR have Untagged output label?” post made an interesting comment:
When a loopback network is advertised as 126.96.36.199/16, it's seen as »pop tag« on the neighboring router and I can't see it in the »show mpls forwarding« printout on the local router. What's going on?
As explained in the “When would an MPLS LSR have Untagged output label?” post, the Untagged (also displayed as No label in recent IOS releases) value means that the Label Switch Router (LSR) cannot use the inbound label to decide what to do with the packet and has to perform layer-3 lookup.
Years ago when vendors were pushing the MPLS story to Service Providers, an “independent analyst” wrote a report claiming that MPLS-based VPNs offer security equivalent to Frame Relay networks (to find those reports, ask Google about “MPLS security equivalent to Frame Relay”). This might be true from the functional perspective (and it’s absolutely true that using IP does not make MPLS-based VPNs inherently insecure), but anyone believing these reports might become mightily upset when learning about BGP and MPLS security issues.
Before going any further, please note that exploiting the MPLS architecture as described in All your packets are belong to us presentation requires access to the core SP network, which means that the network (or network management station) has already been successfully penetrated.
A few days ago (the) Steve Bellowin sent an e-mail to the NANOG mailing list pointing to a FUD-full article describing upcoming release of MPLS hacking tools. Christian Koch quickly pointed out a similar presentation given by the same group @ Schmoocon and numerous respondents correctly stated these are old issues … if you’re interested in BGP and MPLS security, of course. Nicolas Fischbach even provided link to a 7 year old presentation describing numerous BGP/IGP/MPLS risks and attack vectors.
Note: both photographs are from Wikimedia Commons.
George sent me a question that surfaced age-old memories:
I saw the Serial 0/1/0 interface in one of your articles. I understand the Serial 0/1 command as accessing the sub interface of Serial 0 with the 1st interface. But I have never seen the 2nd 0 being used. What is the 2nd "0", and how is it to be used?
In the ancient times when the high-end router was an AGS+, the interface names were kept simple (for example, Serial0). When the Cisco 7000 was introduced with online insertion and removal (OIR) capability, router's life became more complex, as its actual hardware (and thus the interface names) might change while it's running.
The high-end books published by Cisco Press are usually pretty good, but every now and then they manage to produce a masterpiece that has all the potential to become a legend. The “IPv6 Security” book by Scott Hogg and Eric Vyncke is definitely in this category and is a must-read for anyone who plans to deploy IPv6 in the future (that should include around 100% of the network engineers).
Recently I’ve received numerous questions about the traffic shaping functionality of Cisco routers (and how it can be used to create artificial queues). Obviously it was time to write a long-overdue article on traffic shaping basics, the Cisco IOS algorithms and queuing structures.
Chris sent me an interesting question:
How many secondary IPs can you put on a Vlan on a Catalyst switch?
The best way to figure out the answer to this question is to close the browser window pointing to google.com (you won’t find the answer there), generate a test configuration and try to load it into your box.
Sometimes you need numerous BGP sources in your lab, but have only a fixed number of routers. Although you could introduce an extra BGP source with Quagga running on Linux (or use tricks to generate more than one BGP source on a single Linux host), it’s usually best if you could avoid the introduction of extra devices in your lab.
Recent releases of Cisco IOS provide a perfect solution: you can run as many BGP instances as you wish on a single router (each one in its own VRF) and use the BGP Support for Dual-AS Configuration to replace actual AS number with the desired one.
One of the readers of my BGP Route Reflectors article spotted an “obvious deviation from how we always though the route reflectors work":
An IBGP route received from a route-reflector client is sent to all IBGP peers, including the client from which it was received.
A quick lab test confirmed the validity of my claims: a BGP route reflector does send an update back to the client from which it was received (and it’s perfectly legal according to the updated BGP Route Reflector RFC).
Cisco has unveiled numerous green solutions in the last few months, including energy-saving ASR 9000 router and GreenWise initiative. Now they went a step further and implemented some of the old energy-efficient wireless technologies, proving that you don’t always need new technologies to address the energy efficiency (see also Myth #8 in Top 10 Myths about Sustainability).
The first step in GreenWise wireless rollout are the new high-density line cards for the ASR 9000 routers. The port adapters and SFP modules in these line cards will support RFC 1149 with its low-electricity requirements, low-emission focused RFC 1926 as well as RFC 4824 addressing the needs of the health care vertical market. The first release of the line cards will not support all QoS requirements of RFC 2549 due to the limited processing power of the on-card PPU.
You can find detailed information on these revolutionary line cards and adapters among the other in-depth data sheets documenting ASR 9000 platform and line cards (snapshot of the page).