Blog Posts in September 2008
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.
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 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.
I have always intuitively assumed that the interface bandwidth on MLPPP bundles is the sum of interface bandwidths of individual interfaces that are part of the bundle. Recently I’ve tested my assumption and it works as expected.
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.” The detailed rules and undesired side effects if you ignore them are summarized in the MPLS Traffic Engineering in MPLS VPN environment article.
In a comment to my post describing the role of implicit NULL in LDP, an anonymous commenter complained about lack of Cisco’s standard compliance in MPLS TE tunnel setup process. Time for packet capture and Wireshark :). The tests were performed on the MPLS TE network I’ve used to illustrate MPLS troubleshooting with LSP ping; packets were captured on the link between C4 and C2 (the penultimate hop and the tunnel tail-end) at the time when the MPLS TE tunnel was established from C1 to C2. In all tests, an ICMP Echo Request packet was sent over the tunnel to verify whether C4 performed PHP or used an MPLS shim header on the last hop of the tunnel.
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.
To display bandwidths of all interfaces configured on the router use show interface | include protocol|BW command.
We all know that you have to use the default-information originate router configuration command if you want to advertise an external default route into an OSPF domain ... unless the router from which you want to advertise the default route resides in an NSSA area. The default-information originate command does not work within an NSSA area.
To display IP addresses assigned to router’s interfaces (excluding interfaces with no IP address) use show ip interface brief | exclude unassigned command.
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. Today (at least in IOS release 12.4, 12.4T and 12.2S) you have to configure the type-7 default route origination explicitly with the area nssa default-information-originate router configuration command, in which you can also specify the route metric and metric type (N1 or N2). Entering the area xx nssa without the default-information-originate keyword will result in an NSSA area with no connectivity to external destinations redistributed into OSPF in other areas.
Default NTP settings on Cisco IOS allow intruders to change the router’s time or even current year as soon as the router is not synchronized directly with a primary (stratum 1) NTP server. In the Secure Time Management article, I'm describing a very simple NTP attack on an unprotected network and the safeguards you can put in place to prevent similar attacks.
If you’ve ever had the “privilege” of buying equipment from a large systems integrator (or directly from a large vendor), you’re probably familiar with this process:
Let me conclude that BGP aggregation is not widely used (so I will spend much energy covering it in my future posts) ... all the other potential conclusions are too pessimistic.
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.
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.