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.

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

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

read more see 7 comments

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.

It looks like everyone has better things to do after the summer holidays than providing free content to the blogosphere. The only really interesting post I found was Colin McNamara's response to my DMZ VLAN post, in which he looks at the much bigger picture: it's not only the switching infrastructure we're sharing; in the virtualization rush, we're sharing memory, disks, interfaces and even firewalls.

read more add comment

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 IOS inserted the type-7 default route into an NSSA area when the NSSA feature was introduced.

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.

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:

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:

A week ago I've asked whether anyone has a good use for BGP aggregation. Out of 1300 daily visitors of my blog and 2200 subscribers to the RSS feed,  four (4) people found the time and energy to reply. Thank you for your thoughts!

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.

read more see 16 comments

In the Deploying Zone-Based Firewalls book I wrote:

In early releases supporting zone-based policy firewall configuration (IOS 12.4(6)T), match protocol command cannot be used to classify traffic to or from the self zone. Only IP access lists can be used for traffic classification purposes.

Misha Volodko reported that the match protocol icmp command works for him when used with the self zone. Another small step toward perfect implementation :) ... and don't forget that you can always use class class-default to catch all the unclassified traffic (and log it before it's dropped, for example).