A short question I've got from Shahid Rox:

Today I read your article about scaling EIGRP using stub routers. I was wondering whether you can use the leak map only for routes learned from other EIGRP neighbors? Is it also usable to filter connected routes?

Leak-map controls what its name implies: the leakage of routes received from EIGRP neighbors to other EIGRP neighbors. To filter connected prefixes redistributed into EIGRP, use the route-map on redistribute connected command. The only way I've figured out to filter announcements of directly connected networks that are part of the EIGRP process is the distribute-list out command.

When the local Telco installed my blindingly fast 20 Mbps Internet-over-fiber-cable service, I was expecting to use DHCP on the router’s outside interface to connect to the Internet. After all, they’re running switched Ethernet VLANs over the fiber cable, and using DHCP seemed a logical choice. Imagine my surprise when I had to configure PPP-over-Ethernet (PPPoE) – it was as if I would be using a DSL connection, not a fiber-optic cable.

Yesterday, I introduced a scenario where RIP would (in my opinion) work much better than OSPF. If you were not persuaded by the “management-level” arguments, let’s focus on the technical details (but make sure you read the scenario first).

All you ever want to advertise to the remote sites in this design is the default route (or a network-wide summary). Alternatively, you might want to advertise only a route to a central LAN or server. Both requirements are easily met with RIP per-interface output filters. Doing something similar with OSPF is close to impossible. Either you place every remote site into a separate OSPF area (don’t even think about doing it; there could be hundreds of sites), or the routes within an area will leak between the remote sites.

RIP is also more stable than OSPF in this setup. Whenever a remote site disappears, the change in the OSPF area is unnecessarily propagated to all other remote sites in the same area. RIP doesn’t propagate the topology change; the central site’s output route filter stops all unnecessary updates.

As you know, OSPF requires hello packets and adjacencies to work correctly. Therefore, the central hub router must track the adjacency states of hundreds of neighbors. When using RIP, the central router couldn’t care less … it sends out its routes every so often, collects whatever comes back, and reports when a new remote route is received, or an old one disappears.

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.

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...

 

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

I've always believed that you need to teach your students (more so if they are engineers) how things work, so they'll be able to understand why they do things they way they do them. It seems to me, though, that the training courses I'm seeing veer ever more toward overviews and recipes ... but there are a few things you can do on your own.

• Jeremy Stretch started writing about BGP aggregation. So far he's covered the principles and the route suppression options. Unfortunately, my question still remains unanswered: why would you use these tweaks in a well-designed network?
• Anthony Sequeira started to explain the QoS mechanisms on PIX/ASA. So far he's covered the overview, modular framework, priority queuing and traffic shaping. Now we're waiting for part 5 of another trilogy in four parts.
• Joe Harris was bored during the meetings (his words, not mine) and preferred to focus on IOS configuration lock and Configuration Generation Performance Enhancement. Now we know why some people @ Cisco hate Dynamips: SEs have found yet another way to survive the boring meetings :).
• Greg Ferro described how TCP SYN cookies work and provided interesting insight into the brain maps of network- and server engineers, which is the first post you should read if you're depressed by the cloudy and cold autumn weather.
  

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.

In one of the MPLS-related posts, I’ve described the role of implicit NULL in penultimate hop popping (PHP). To make the distinction between implicit and explicit NULL even clearer, I’ve prepared a short explanation with corresponding diagrams.