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.

Sometimes it would be nice to have the full complement of Unix utilities available on Cisco IOS. That's not going to happen for a while, but we can use Tcl to make our life simpler in the meantime. Xavier Brouckaert, a regular contributor to my blog, has sent me the Tcl implementation of line counting utility (equivalent to wc -l on Unix).

First you have to define the wc Tcl procedure:

proc wc { cmd } { llength [split [exec $cmd] "\n" ] }

You can define the procedure interactively in Tclsh (but then you have to do it every time you start Tclsh) or you could store the code in a flash file and execute the file every time the Tclsh is started with the scripting tcl init filename global configuration command.

Once the wc procedure is defined, execute wc { IOS command } in Tclsh and you'll get the line count. For example, to get the number of directly connected routes use

wc { show ip route ¦ include ^C }

The include ^C filter includes all lines that start with letter C; in our case all directly connected routes

Obviously you could turn this idea into a full-blown Tclsh script that would accept CLI arguments … but I'll leave this as an exercise for the readers (you can probably tell I've been reading some academic literature lately :). However, if you find the time to write a more complete wc implementation on IOS, please do post the URL here.

When trying to extract the OSPF route selection rules from RFC 2328, I've stumbled across a very weird rule (section 16.4.1): if an ASBR within a non-backbone area advertises an external route (or if the forwarding address is within the non-backbone area), it's preferred over external routes advertised by ASBRs in other areas regardless of its metric. I simply had to test this on Cisco IOS … and found out that Cisco engineers prefer common sense to OSPF RFC.

Any serious (or at least security-aware) ISP should not blindly accept BGP routes from its customers but at the very minimum do some sanity checks on them. For example, if a multi-homed customer is clumsy enough to advertise BGP routes between service providers, it’s nice if you still stop him from turning into a transit AS. The required filter is conceptually quite simple: all the BGP routes from the customer should contain only his AS number in the AS-path.

The initial non-scalable approach is obvious: accept only the AS paths that have exactly the customer’s AS number in the AS path. For example, if your customer’s AS number is 65001, you could use this filter: ip as-path access-list 100 permit ^65001$.

When we’ve been assigning router interfaces in OSPF areas with the network router configuration command, it was impossible to start OSPF only on some unnumbered interfaces and not on others (or place the unnumbered interfaces in different areas). These restrictions are removed if you use the ip ospf area interface configuration command.

Every now and then, EEM applets fail to recognize a new configuration prompt generated by the router and abort due to timeout (or hang-up forever if you're using IOS release prior to 12.4(15)T). You can use the new pattern keyword of the action cli configuration command to fix the bug.

Enterprise networks primarily use BGP with their Internet Service Providers if they want to be multi-homed (connected to more than one ISP). A very common requirement in a multi-homed design is the primary/backup setup where the lower speed (or sometimes lower quality) link should only be used when the primary link fails.

Competent ISPs help their customers reach this goal by using BGP local preference within their network and giving the customers the ability to indicate the desired value of BGP local preference through BGP communities: if the route received directly from the customer has low local preference, all other routes are preferred, resulting in the desired traffic flow that avoids the backup link if at all possible as shown in the next diagram:

Mohammad Faraz Rehan has encountered an interesting problem when using IP access-list based class/policy maps on Catalyst 3750:

When I try to apply the same service-policy to more than 15 interfaces, the configuration command fails and the switch generates the following syslog message:

%QOSMGR-4-POLICER_PLATFORM_NOT_SUPPORTED: Policer configuration has exceeded hardware limitation for policymap …

I've tried to help him with various TCAM-related information and in the end he found an interesting solution to the problem:

It looks like there is a limit related to using the same access-list/class-map/policy-map on multiple interfaces.

The first time I was applying the same policy-map (19 classes/19 ACLs/46 ACL lines) on all interfaces, but the switch would not accept it on more than 15 interfaces. Another test scenario had 18 classes/18 ACLs/52 ACL entries and the same policy-map would only work on 13 interfaces.

Now we implemented 24 different policy-maps, class-maps and ACLs remained the same, and the switch is happy.

If you use LDP-based MPLS as the only means of transporting data across your network core (for example, in MPLS VPN networks or in BGP-free ISP core), a router startup might disrupt your Label Switched Paths (remember: they are always based on IGP best paths) leading to a temporary disruption in service.

For example, when the router P1 in the network shown in the following diagram is powered on, and its IGP advertises its presence, the IGP-derived path from PE1 to PE2 will go over P1. If the LDP on P1 has not exchanged labels with PE1 and PE2, there will be no LSP on the shortest path between PE1 and PE2, resulting in a loss of traffic until the labels are exchanged and LSP is built.

BGP communities are extra attributes you can attach to an IP route carried by BGP. You can use communities to indicate which routes should be propagated or filtered (for example, the well-known NO_EXPORT community signifies that the route it’s attached to shall not be sent outside of the local AS), to influence route selection on remote routers or to trigger other BGP-dependent IOS features (for example, quality-of-service marking based on BGP).

Each BGP community is a 32-bit value. The best practice dictates that the top 16 bits should be the AS number of the network defining the community meaning and the bottom 16 bits are defined by the network administrator.

Catalyst switches have an interesting internal architecture that uses a Ternary Content Addressable Memory (TCAM) to perform a variety of lookups. For example:

• If a CAM entry matches on destination MAC address, it performs L2 switching (aka bridging)
• If it matches on destination IP address, it performs L3 switching (aka routing)
• If it matches on a combination of source/destination IP addresses and ports, it can be used to implement access lists, QoS mechanisms or policy routing

To make things even more interesting, multiple TCAM entries use the same mask (don't care bits) as explained in the Understanding ACL on Catalyst 6500 Series Switches white paper. Most of that information also applies to the Catalyst 3750 platform, more details are available in the Understanding and Configuring Switching Database Manager on Catalyst 3750 Series Switches document (here is the corresponding document for Catalyst 3550). As the TCAM size on Catalyst 3750 might not be large enough, you can split it in various ways with the SDM templates.

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.

Configuring a large number of similar BGP peers on a router and ensuring that the changes in your routing policy or BGP design are applied to all of them can be a management nightmare. BGP peer groups were the only scalability tool available on Cisco IOS until the IOS release 12.3T and they had significant limitations as they were also used as a performance improvement tool.

IOS releases 12.0S and 12.3T introduced peer templates, a scalable hierarchical way of configuring BGP session parameters and inbound/outbound policies. For example, to configure the session parameters for all your IBGP sessions, use the following session template:

router bgp 65001
 template peer-session IBGP
  remote-as 65001
  description IBGP peers
  password s3cr3t
  update-source Loopback0

After the session template has been configured, adding a new IBGP peer takes just a single configuration command (two if you want to add neighbor description):

router bgp 65001
 neighbor 10.0.1.2 inherit peer-session IBGP
 neighbor 10.0.1.2 description R2

Policy templates are similar to session templates, and contain neighbor parameters that influence processing of prefixes of an individual BGP address family (example: filtering of inbound updates).

Continuing the IBGP example, you might want to group route reflector clients in a policy template, and ensure the route reflector propagating all BGP communities to them:

router bgp 65001
 template peer-policy Internal
  route-reflector-client
  send-community both
 exit-peer-policy

After defining a policy template, you can apply it to multiple address families, for example:

router bgp 65001
 neighbor 10.0.1.2 inherit peer-session IBGP
 neighbor 10.0.1.2 description R2
!
 address-family ipv4
  neighbor 10.0.1.2 activate
  neighbor 10.0.1.2 inherit peer-policy Internal
 exit-address-family
 !
 address-family vpnv4
  neighbor 10.0.1.2 activate
  neighbor 10.0.1.2 inherit peer-policy Internal

The chances that you would be able to start SSH or Telnet session from an EEM applet were pretty slim, but the comment from melwong triggered my curiosity and I simply had to try it. After all, as the action cli command uses a VTY line (like a regular user session), you might be able to use the pattern option of the action cli command to write something similar to an expect script. This was my best shot at getting it done:

event manager applet SSH
 event none
 action 0.9 cli command "enable"
 action 1.0 cli command "ssh -l ssUser R2" pattern "word:"
 action 1.1 cli command "ssPassword" pattern "#"
 action 2.0 cli command "clear ip route *" pattern "#"
 action 3.0 cli command "exit" pattern "#"

My applet got past the SSH authentication (debugging on R2 confirmed that the SSH session was started) but could not send data through the session itself (it hung on the clear ip route command).

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

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.