The inability of Control Plane host interface to detect inbound OSPF packets has prompted Sebastian and myself to search for more documentation and conduct further tests. Sebastian already had a working configuration from which he could infer most of the configuration rules and he also found the well-written Understanding CPPr document on CCO. Together with the tests I ran in my router lab, we're pretty confident the CPPr inbound packet classification rules are (approximately) as follows:

Use the latest 12.4T software (at least 12.4(15)T5) if you want reliable CPPr operation.

• control-plane aggregate service-policy disables any control-plane subinterface service policies.
• If you want to use the per-subinterface (host, transit and cef-exception) policies, you have to remove the inbound service policy from the control-plane aggregate path.
• Routed packets that cannot be CEF-switched (have to be punted to another switching mechanism) are classified as transit packets.
• Local multicast packets with destination IP addresses within IP prefix 224.0.0.0/24 and packets with TTL <= 1 are classified as transit packets in 12.4(15)T5. These packets will be classified as cef-exception packets in the future (see the Understanding CPPr document).
• Unicast packets without IP options addressed to the router and having TTL > 1 are classified as host packets.
• Non-IP traffic (ARP, Frame Relay keepalives, CDP ...) is classified as cef-exception.

The TTL-related rules explain why the router classifies IBGP packets as host packets and EBGP packets as transit packets. As soon as you configure neighbor ebgp-multihop on the router router, inbound EBGP packets become host packets.

Years ago EIGRP and OSPF had strong presence in large enterprise networks, BGP was used solely by Internet Service providers and IS-IS was a rarity (and there were people using Banyan Vines).

The situation has probably changed over the last years, I would (sadly) expect EIGRP to decline and (happily) BGP to grow. Let's figure it out; please respond to this week's readers' poll. Of course you can choose more than one routing protocol.

Euphrates Greene sent me a report of a very annoying “functionality” of Cisco 851/871: they're bridging between the inside (LAN) ethernet and outside (WAN) ethernet interfaces while they're running the ROMMON code (from the reload/power-up throughout the software decompression process until the control is transferred to the Cisco IOS). It's worth mentioning that these routers are commonly used as SOHO firewalls and that the internal LAN is exposed while the router is in the bridging mode.

Our security experts have replicated the behavior and reported it to Cisco PSIRT. Fortunately it's a known vulnerability, documented as CSCsd60259 (release note is available on CCO to registered users) and fixed with a ROMMON upgrade.

New routers are shipped with new ROMMON version, so you shouldn't be seeing this behavior on brand new boxes … but one cannot help but wonder why such a nasty behavior was not documented as a field notice/security advisory.

One of the comments to my Sunday post mentioned RTBH. Obviously I'm not geeky enough, as I had to ask uncle Google for help (but don't worry, I'll work on my geekiness factor :).

The search results produced a few very interesting links, among them a well-structured presentation on RTBH that refers to a paper describing how you can detect remote DoS attacks with the backscatter analysis (assuming the attackers are randomly spoofing source IP addresses).

1. You're creating a multi-AS BGP test lab on Sunday evening;
2. The core AS is running 12.2SRC code;
   
3. You insert a P-router in the core network ... because every large network has P-routers;
4. You create BGP session templates instead of configuring two parameters of a few IBGP neighbors;
5. You configure MPLS in the core network instead of using BGP on all routers ... because it saves you a few BGP sessions ... and that's the way things should be done anyway;
6. When configuring OSPF, you define inter-AS links as passive interfaces ... not because you're running OSPF in the other AS but for security reasons :)
   
7. ... add your comment here ...
   

We've always been trying to minimize asymmetric routing, in both design and implementation phase, as it impacts a number of IP services/features, including:

• Network Address Translation;
• Content-based Access Control (CBAC);
• Reflexive access lists;
  
• Redundant firewalls (at least until recently);
• IP Multicast;

In some scenarios, asymmetric routing can impact delay/jitter and consequently the perceived quality of service.

However, asymmetric routing is a reality within the Internet (it's close to impossible to guarantee symmetric routing even for multi-homed end users) and it might even help in some scenarios (low-speed/low-delay upstream link with high-speed/high-delay downstream link).

What's your opinion? Is asymmetric routing harmful? Should we strive to avoid it ... or do you just accept it as one of facts of life?

Cheng sent me an interesting question:

I'm reading your book MPLS and VPN Architectures and I've found the ip vrf forwarding name fallback global command in the “Additional Lookup in the Global Routing Table” section. I can only find this command in Junos, but not in IOS.

… and he was right. When we were writing the book, we described several features that were still in development as it looked like they would be in the production code by the time the book was published. Many of them made it into the public IOS releases (for example, the Carrier's Carrier architecture), but some of them (like this command) simply vanished from the surface.

However, it looks like the engineers that switched from Cisco to Juniper took the concept with them and implemented it in JunOS, so JunOS has this feature but IOS doesn't.

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

The section filter of the show commands contains a nasty bug (at least in the IOS release 12.4T) in IOS release 12.2SRC: if a line in the section matches the same regular expression as the section header, the rest of the section is not printed.

The blogging world is an interestingly dynamic place ... sometimes a page would vanish moments after you would mention it in a blog post :) Google Cache might be a short term solution, but you could use a much better tool: Webcite gives you the ability to store a snapshot of a web page at the time you've cited it.

Central Europe has a venerable tradition of celebrating Labor Day (May 1st in this part of the world) by not working … and while this might sound like an oxymoron, we definitely have to respect traditions, don't we? See you on Monday :)

Setting the size of the hardware output queue in Cisco IOS with the (then undocumented) tx-ring-limit (formerly known as tx-limit) has been a big deal when I was developing the first version of the QoS course that eventually became the initial release of the Implementing Cisco Quality of Service training.

However, while it's intuitively clear that the longer hardware queue affects the QoS, years passed before I finally took the time to measure the actual impact.

The brief display of the state of IPv6 interfaces in the router (show ipv6 interface brief) is significantly different from the well-known show ip interface brief display as the IPv6 address might not fit in the same line as all the other data. To filter the printout and display only the operational interfaces, you have to replace the include filter with the section filter, which displays all the lines matching the regular expression as well as associated follow-up lines.

PE-A#show ipv6 interface brief | section up
Serial1/0                  [up/up]
    unassigned
Serial1/1                  [up/up]
    FE80::C800:CFF:FEA7:0
Loopback0                  [up/up]
    unassigned

The definition of the associated follow-up lines depends on the printout. Usually the indented lines are assumed to belong to a section, but you might be surprised.

According to the results of my recent Do you use CLNS poll, around 10% of my readers use CLNS in their network, while 36% of them wonder what that acronym stands for.

Let's start with the acronyms. CLNS (Connection-Less Network Service) in combination with CLNP (Connection-Less Network Protocol) is the ISO (International Standards Organization) equivalent to IP.

CCIE Pursuit writes about the usage of MAC addresses on SVI (VLAN) interfaces on various Catalyst switches. Some switches might reuse the same MAC address on multiple VLANs, leading to interesting problems if another box bridges those VLANs (for example, a transparent firewall).

Recently I had to implement Internet access using ADSL as the primary link and ISDN as the backup link. Obviously the most versatile solution would use the techniques described in my Small Site Multi-homing articles, but the peculiarities of Cisco IOS implementation of the ADSL technology resulted in a much simpler solution.

IOS implementation of PPPoE links uses dialer interfaces. However, the “dialing” on these interfaces is activated as soon as the underlying PPPoE session is active (before the first interesting packet is routed to the interface). When the simulated dial-out occurs, the router starts PPP negotiations including the IPCP handshake, which usually results in an IP address assigned to the dialer interface. Net result: if the dialer interface has an IP address, the PPPoE session is obviously active (and vice versa).