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

Establishing parallel EBGP sessions across parallel links between two edge routers (EBGP peers) – as displayed in the diagram below – is the most versatile form of EBGP load balancing. It does not require static routing or extra routing protocol (like the design running EBGP between routers’ loopback interfaces), device-specific tricks like configuring the same IP address on multiple interfaces) or specific layer-2 encapsulation (like Ethernet LAG or Multilink PPP).

It even allows proportional load-balancing across unequal-bandwidth links and combinations of various layer-2 technologies (for example, load-balancing between a serial line and an Ethernet interface). The only drawback of this design is the increased size of the BGP table, as every BGP prefix is received from the EBGP neighbor twice.

Ralf sent me a SNMPv3 question:

If I create a SNMPv3 user which has a password (snmp-server user userthree groupthree v3 auth md5 user3passwd), this user does not appear in the running- or startup-config. Cisco even documents this if you know what to look for.

I strongly suspect (although I did not test this) that these users are also missing from configuration exported to TFTP servers. What would be the recommended way to make usable config backups of routers with such users?

Like certificates, the SNMPv3 users are stored in private-config and thus never appear in the router configuration. If you want to have a backup of the user data, create a text file on one of your NMS servers, add SNMPv3 usernames and passwords in the text file and use the copy somewhere running-config to configure SNMPv3 users on the routers.

Peter Weymann sent me a really intriguing question:

A few days ago I started reading the Ciscopress book End-to-End Network Security: Defense-in-Depth and stumbled over the scheduler command. This one could be used to allocate time that the cpu spends on fast switching packets or process switching packets, if I understand it correctly. They also mention interrupting CPU processes but honestly I don't really understand how it works.

Cisco routers support (at least) three forms of layer-3 switching (formerly known as routing). CEF switching and fast switching are performed entirely within the interrupt context (I/O adapter interrupts a process the CPU is currently executing and all the work is done before the process resumes). Process switching is performed in two steps: packet is briefly analysed within the interrupt context and requeued into the IP Input process where it's eventually switched. Almost all I/O adapters used these days use a concept of RX/TX rings to communicate with the CPU, meaning that the CPU potentially has to handle more than one packet for each interrupt.

Did you know that RIP, the venerable routing protocol that is present in Cisco routers for the last 20 years, uses an internal database, not the IP routing table, to process RIP updates? This database contains no fancy information (like EIGRP topology table) that would allow RIP to converge faster, but there are still minor differences between the RIP database and the IP routing table.

The article in which I described that feature is long gone, but fortunately archive.org saved the day.

For the last 10 years, I've been preaching that you should use static BGP prefix advertising (with the network mask router configuration command) to advertise your IP address space into the public Internet, not the BGP aggregation. I might see some use for BGP aggregation in enterprise networks (or MPLS VPN networks) using BGP as the core routing protocol with other routing protocols serving the edge, but I cannot find a good scenario where BGP aggregation in public Internet would be a good solution. Do you use BGP aggregation in your network? Do you have a good scenario that you'd like to share with us? Write a comment.

Shivlu Jain sent me an interesting question:

I'm wondering whether a router performing penultimate hop popping (PHP) imposes an IGP label or not.The value of implicit null is 3; does it mean the router imposes this label (and adds four bytes to the packet)?

The penultimate router does not impose the IGP label (that's why this behavior is called penultimate hop popping). However, the egress router has to signal to its upstream neighbor (the penultimate router) that it should NOT impose a label, so it uses "implicit null" label (= 3) in TDP/LDP updates to signal that the top label should be popped, not rewriten.

If you store the reverse mapping for the routers’ loopback interfaces in DNS or configure the name-to-address mappings with the ip host commands, you can use the ip ospf name-lookup global configuration command to display the OSPF router IDs as router names.

Working on an implementation of a split DNS design, I encountered an interesting bug in Cisco IOS: the ip dns view-group command works only on interfaces, but not on subinterfaces. As it’s a pure IP feature, there obviously no reason why it shouldn’t work on anything that has an IP address; obviously someone forgot to insert the correct entry in the parser tables.

My favorite provocateur has dreamed up another sensational story ... and even has numbers to back it up. Reverse engineering the increase in reported number of CCIEs and taking in account the estimated number of seats in Cisco's labs worldwide, he concluded that the pass rate for CCIE R/S is currently at 35% whereas in the past the rumors claimed it was only around 10%. The conclusions in the story should not surprise you ... it must be the braindumps and the devaluing of the CCIE program. Of course it's the braindumps: people like Petr Lapukhov, Jeremy Stretch, Arden Packeer, Joe Harris and tens of others (including yours truly) are dumping the contents of their gray cell matter into blogs and wikis, creating astounding amount of information that we've never got from Cisco in the past.