Building network automation solutions

9 module online course

Start now!

Blog Posts in September 2008

Why is RIP still kicking?

One of my readers called RIP “Rest in Piece” routing. Although it’s probably the routing protocol that dinosaurs used to find their way around, it’s still useful in modern networks. Imagine that you have to deploy hundreds (or thousands) of low-cost remote sites with dual uplink capability (for backup purposes). They could be automated kiosks, point-of-sale terminals or even ATM machines.
If you’re infinitely lucky (and have huge budget), you could afford an ISR router at each location and use different design options that Cisco IOS gives you. In most cases, you have to work with devices that barely know what routing is … but you still need dynamic routing protocol to give them the ability to detect primary route failure and switch over to the backup route.

Assuming your purchasing department didn’t buy boxes that don’t have enough memory to run OSPF, you could usually choose between RIP and OSPF as the routing protocol … and I would always select RIP in this scenario. Let’s start with the “management-level” arguments: RIP is simpler to design (there is almost nothing to design) and troubleshoot than OSPF. It uses less memory and CPU cycles and I would also expect low-end boxes to have fewer bugs in RIP than in OSPF. More in-depth arguments are coming in the follow-up post.
add comment

Enhance the Traceroute Output

After working with MPLS Traffic Engineering lab for a few days and interpreting IP addresses from various traceroute outputs, I finally had enough and wrote a simple Perl script (below) that parses router configurations and produces ip host configuration commands for every interface IP address it encounters. When you paste the ip host commands into the configuration of the edge router from which you do the tests, the meaningless numbers finally make sense.

read more see 3 comments

Do you need LDP with MPLS TE?

An anonymous commenter to my implicit NULL/PHP post made a very valid point:

Most Cisco documentation states that you must enable LDP before doing MPLS-TE, which is a complete fallacy.

If you're using MPLS TE simply to shift IP traffic around your network, he's absolutely right: there is no need to run LDP if you have an IP-only network. If you're running MPLS VPN or BGP on edges/MPLS in the core, the answer becomes “it depends.”

I documented the detailed rules and undesired side effects if you ignore them a long while ago, but that article disappeared into /dev/null. Fortunately archive.org caught a copy before that.

Would you like me to migrate that article to ipSpace.net? Send me a message and I just might do it...

see 4 comments

Load balancing quirks

One of my readers has noted an interesting load-balancing behavior: when he was running traceroute tests from various routers in a topology similar to the one displayed below, the traceroute outputs indicated per-packet load balancing (both paths were used) when they were initiated from R2 or R3, but used a single path when initiated from R1 or R4.
 
The reason for this behavior is very simple: if you do traceroute from R1 to R4, R2 and R3 perform CEF switching, which usually does load balancing based on source-destination IP address pairs, so all probe packets from R1 to R4 travel along the same path. If you start traceroute from R2 or R3, the packets are process-switched on the first hop (from R2 to R3, for example) and thus alternate between the parallel links.

This article is part of You've asked for it series.

see 5 comments

Interesting links | 2008-09-21

The blogosphere is amazing: I was complaining about lack of posts a week ago, but the last days were a real bonanza:
see 1 comments

PE-to-PE Troubleshooting in MPLS VPN Networks

End-to-end troubleshooting of MPLS VPN solutions is one of the more complex network troubleshooting tasks. On top of several sophisticated technologies and protocols used in MPLS VPN solutions, we have to deal with customer-to-provider interaction on the IP routing protocol level, which makes the troubleshooting efforts even more convoluted.

To minimize the impact of your customers on your troubleshooting efforts, you might want to start with the PE-to-PE troubleshooting. When used as the first step in your troubleshooting process, the PE-PE tests will bypass customer errors, intra-site customer routing problems, PE-CE interactions, and route redistribution issues.

read more add comment

Default routing in NSSA area

The RFC 3101 (OSPF NSSA Option) states:

In addition, an NSSA border router should originate a default LSA (IP network is 0.0.0.0/0) into the NSSA. Default routes are necessary because NSSAs do not receive full routing information and must have a default route in order to route to AS-external destinations.

I am pretty sure that IOS inserted the type-7 default route into an NSSA area when the NSSA feature was introduced.

read more add comment

Are VLANs safe in DMZ environment?

The Thinking problem management! blog had an interesting article on The Leaky VLANs myth, quoting a test report from SANS Institute that documents how you can inject frames into other VLANs even if you're not connected to a trunk port. The report is eight years old (so one would hope this issue has been fixed in the meantime), but there's another question you should ask yourself is: what happens when you lose the configuration of the switch (and I've seen devices losing configuration after a power glitch). If you're using a router to perform L3 switching, no harm is done; a router with empty configuration forwards no packets. But if you're using a low-end switch, you're in deep trouble; by default, a switch forwards packets between all ports ... and if you use static IP addresses on all subnets, you won't even notice they're connected. If you want to be very safe, you're better off having a different set of switches for the inside and the outside zones of your firewall.
see 7 comments

Some DHCP clients do not use Client identifier option

A while ago I've documented how you can cope with DHCP clients that do not send Client identifier (DHCP option 61) in their DHCP Discover/Request messages, but some people are still trying to persuade me that the client-identifier pool configuration command should work. I really wanted to be sure I hadn't missed something, so I started Wireshark and captured the actual DHCP Discover packet generated by a Linux host:
 
As you can see, the DHCP packet does not contain the Client identifier option, so the DHCP server (the router) has nothing to compare the value of the client-identifier parameter with. The only parameter the DHCP server can use is the Client MAC address field in the DHCP Discover message, which is matched with the mac-address pool configuration command.
In contrast to the default Linux behavior, DHCP Discover messages generated by other platforms (for example, Windows or a Cisco router) include the Client identifier option:
 
see 1 comments

Practical BGP-based hijack/man-in-the-middle attack

One of the presentations at the recent Defcon 16 event demonstrated how you can use the very common laziness of the Internet Service Providers to hijack any prefix you want (just ask YouTube). Nothing new so far, but the part where they fake the AS path in the hijacked announcement to create a safe (hijack-free) conduit back to the destination is brilliant ... and the TTL manipulation is the icing on the cake.

Of course this is a well-known BGP vulnerability (actually, implementation sloppiness on the part of ISPs) that we've been writing about for a long time, but the Defcon presentation is probably the first documented step-by-step recipe for a realistic MITM attack.

Hat tip to Jeremy Stretch; I found the link to the Defcon presentation on his blog.

add comment

Send e-mail after a router reload

In previous posts, I’ve explained how you can use the SYS-5-RESTART syslog message to detect router reloads and execute commands (for example, fix router configuration or enable debugging) right after the reload. If you want to perform actions that require network connectivity (for example, send an e-mail when a router is reloaded), you cannot execute them right away, as the routing protocols might not have converged yet (in our example, the e-mail server might not be reachable).

You can use the timer countdown event to execute an EEM applet within a fixed delay after the reload. When the router is reloaded, all EEM applets stored in the startup configuration are registered and the one-time countdown timer will fire after the specified time.

read more see 16 comments
Sidebar