The undesired intermittent bridging behavior of Cisco 871 using old ROMMON software can lead to hard-to-diagnose problems if you're connected to an Internet access network through a cable modem that accepts only a single MAC address. The right sequence of events can leave the router/modem combination in a state with no external connectivity requiring a modem power-cycle:

1. The router and the cable modem are power-cycled.
2. The router starts to bridge between all LAN interfaces, effectively connecting inside workstations directly to the cable modem.
3. One of the workstations could detect a LAN failure (due to router reload) and restart the DHCP process (a Windows XP host would definitely do that).
4. The DHCP requests from the workstation are bridged straight to the cable modem which caches the workstation's MAC address and forwards the DHCP request.
5. The workstation is assigned a public IP address (at this time, the workstation is connected directly to Internet and thus vulnerable).
6. The router loads Cisco IOS and reinitializes the Ethernet interfaces. Bridging between internal and external interfaces is stopped.
7. The router sends DHCP request on the outside interface, but the modem ignores it, as the MAC address of the DHCP request differs from the previously cached one.

In most cases, the cable modem has to be power-cycled to lose the cached MAC address.

Multihoming to a single ISP is a design scenario in which a customer uses multiple Internet connections to the same Internet Service Provider. This design provides resilience against link and device failures, but does not provide protection against major outages within the Service Provider network.

There are three major decisions to be made when designing multihoming to single ISP:

• Will the customer use provider-assigned or provider-independent address space?
• Should the customer use static or dynamic routing with the ISP?
• When using dynamic routing with BGP, does the customer need its own public autonomous system?

Keep in mind: Use private IP addresses, AS numbers and domain names in all technical documentation you're producing (unless, of course, you're describing an actual network). If you're forced to use public addresses or AS numbers (for example, to illustrate how the neighbor remote-private-as command works), you should clearly state that they are imaginary.

You can safely use:

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.

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.

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.

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.

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