Category: IP Routing

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:

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;

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.

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

Cisco has published a series of documents describing how you can connect a SOHO site to two ISPs.

Their configuration also includes a nice trick: the ip dhcp client route track number command is a convenient replacement for a static default route with the track option if one of the upstream interfaces uses DHCP and the router generates the default route based on DHCP replies.

When IOS started supporting dynamic allocation of IPCP (IP over PPP) addresses, it also got the mechanism to insert a dynamic host route toward the neighbor's IP address once the IP addresses were negotiated. This mechanism makes perfect sense in dynamic address allocation environments, as the subnet mask is not negotiated with IPCP. Without a host route toward the other end of the PPP link, there would be no easy way to reach the IP prefixes reachable via the PPP link.

I'm often promoting the idea of separating customer routing from core routing in the design articles I write. The only viable solution (unless you want to implement MPLS VPN and migrate customer routing into VPNv4) is to carry customer routes in BGP, redistributing them into BGP from other routing sources. On the other hand, I’m telling you that you should advertise only static IP prefixes into the public Internet. Obviously there’s a seeming disconnect between the two advices.

However, the dilemma is easily solved with the no-export BGP community that prevents an IP prefix from being advertised over EBGP sessions. Whenever you redistribute customer routes into BGP, you should attach the no-export community to them, ensuring that only the statically advertised IP prefixes will be propagated outside of your AS boundaries.

Brian Dennis wrote a long post about the unexpected side effects of the ip default-network command. The Cisco documentation describes the “side effects” but in an even more obscure manner.

What's really happening is this:

• If the parameter of the ip default-network command is a major network, it specifies the default route (how it gets inserted into the routing protocol you're using is a completely different story).
• If the parameter is a subnet of a major network, it specifies the default subnet for the network.

In any case, it's an obscure leftover from the classful days that should probably never be used today outside of a CCIE lab.

Olivier Guillemain has asked an interesting question: “how could I originate a default route into OSPF based on IP SLA (for example, based on pinging a remote IP address)?”

This is very easy to do when the router originating the default route into OSPF needs an SLA-based default route itself:

1. Configure IP SLA and a corresponding track object;
2. Configure a default route using reliable static routing
3. Advertise the default route into OSPF with the default-information originate router configuration command

The solution is a bit more complex when the router originating the default route into OSPF should not have a default route. In this case, you could use a routing trick:

In the last few months I ran across a number of IP fragmentation issues. Unfortunately I also encountered a lot of misconceptions about IP fragmentation, its impact on GRE and IPSec, as well as the fragmentation-related mechanisms like MTU Path Discovery. I documented most of what I found in the The Never-Ending Story of IP Fragmentation.