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.

If you're too young to remember the days of IBM mainframes, punched cards and 132-column printouts, you could get a feeling for what we had to cope with by looking at the original RFC texts. Even the latest RFCs are published in text-only fixed-font format with no extra formatting, making it a nightmare to quote a section of the RFC in a post or an article (not to mention the very real danger of falling asleep just by looking at an RFC).

A variety of third-party web sites have tried to fill the gap by providing RFCs in hyperlinked or PDF format. I've tried a few of them and usually got turned away by inconsistent or broken links.

Finally, IETF recognized that we live in the third millenium and started offering IETF documents (including RFCs) with HTML markup. To get hyperlinked versions of the RFCs, go to IETF tools web site and enter RFC number or use Google to search the IETF repository.

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:

1. Configure IP SLA and a corresponding track object as before;
2. Use reliable static routing to configure a static host route for a bogus IP address (for example, 10.0.0.1/32) pointing to null0 (for example, ip route 10.0.0.1 255.255.255.255 null 0 track 100). Obviously, this host route should not be redistributed into any routing protocol.
3. Conditionally advertise default route into OSPF based on presence of the static host route.

The routing information you source into the public Internet with BGP should be as accurate and stable as possible. The best way to achieve this goal is to statically configure the IP prefixes you’ve been allocated on your core routers and advertise them into BGP:

• BGP will only advertise an IP prefix if a matching entry is found in the IP routing table. To ensure the IP prefix you want to advertise is always present, configure an IP static route to null interface, unless you're advertising a connected interface (example: Internet edge router on a DMZ segment).
• Most public IP prefixes advertised today do not fall on the classful network boundary. To advertise a classless prefix, you have to configure the prefix and the mask in the BGP routing process.

Internal BGP (IBGP) sessions (BGP sessions within your autonomous system) are identified by the neighbor’s AS number being identical to your AS number. While the external BGP (EBGP) sessions are usually established between directly connected routers, IBGP sessions are expected to be configured across the network.

The current best practice is to configure IBGP sessions between the loopback interfaces of the BGP neighbors, ensuring that the TCP session between them (and the BGP adjacency using the TCP session) will not be disrupted after a physical link failure as long as there is an alternate path toward the adjacent router.

Terry Slattery took time (after 15 years) and wrote a short history of Cisco CLI. I've been involved with Cisco's software (it was remarketed as IOS in mid-nineties) for a few years and for me the CLI as we know it today was one of the best features introduced in IOS release 9.21 (I was ecstatic when I've got my hands on the first code during the beta tests). So now that I know who's responsible, I can only say “Thanks, Terry!”

I've stumbled across an interesting problem recently:

• I've added a Linux box to my home network;
• It used my Cisco router to get a dynamic DHCP address;
• I've inspected the DHCP bindings on the Cisco router to find the new MAC address and configured a host DHCP pool as I'm using the Linux box as a server;
• Even after multiple configuration changes, the IOS would fail to use the host DHCP pool.

The only solution I've found was to restart the IOS DHCP server with the no service dhcp followed by service dhcp configuration commands. Obviously, you lose all DHCP bindings when you restart the DHCP server (which could be a problem if you use conflict logging) unless you've configured the router to store them in an external file.

If you do a lot of telnetting in your lab, you could set up an internal DNS server to be able to use router names instead of IP addresses.