Blog Posts in January 2008

TCAM on Catalyst switches

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.

see 1 comments

Redistributing Customer Routes into BGP

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.

read more see 6 comments

… updated on Friday, November 20, 2020 15:27 UTC

BGP Peer Session and Policy Templates

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
Session template includes parameters that apply to a BGP session, including remote AS number, local AS number, MD5 password, and the source IP address of the BGP session. Parameters specific to individual address families are defined in a policy template.

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
see 5 comments

Telnet/SSH session cannot be started from EEM applet

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.

see 12 comments

The short story of the “ip default-network” command

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.

see 3 comments

Hyperlinked RFCs

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.
see 1 comments

OSPF Default Route Based on IP SLA

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.
see 1 comments

Advertising Public IP Prefixes into the Internet

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.
read more see 3 comments

Configuring Internal BGP Sessions

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.

read more see 4 comments

The history of Cisco CLI

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!”
see 1 comments

Restart IOS DHCP server after a change in DHCP pools

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.

see 1 comments

Copy the text files into router's flash through a Telnet session

Were you ever in a situation where a file that would have to be on the router was sitting on your laptop, but you couldn't store it into the router's flash across the Telnet session or through the console port?

If the file in question is a text file, and the router supports Tcl shell, _danshtr_ documented an interesting trick: you create the file in Tclsh interpreter, cut-and-paste the text through the telnet session into a Tcl string and write the string to the file. If you want to have a more cryptic solution here it is:
  • Start tclsh;
  • Enter puts [open "flash:filename" w+] {. Do not hit the ENTER key at the end of the line
  • Copy-paste the file contents. The contents should not include unmatched curly right brackets (every curly right bracket has to be preceded by a matching curly left bracket).
  • After the file contents have been pasted, enter } and press ENTER.
  • End the tclsh session with tclquit.
see 21 comments

DHCP Conflict between a Cisco Router and Windows DHCP Server

In a response to my post Redundant DHCP Server I've speculated that a Cisco router should coexist with a Windows-based DHCP server if you configure them with non-overlapping address ranges. I was wrong, Edgar Cahuana discovered that Microsoft's DHCP server wants to have complete control over the LAN it's serving and shuts down if it detects another DHCP server on the same LAN.

To make the two DHCP servers coexist, you have to disable rogue DHCP server detection in Windows DHCP server.

see 4 comments

Fix a BGP AS Number Mismatch

Sometimes you end up having wrong BGP AS number throughout your network. It could be a result of an unexpected merger or split or you could have started using a private BGP AS number and realized you have to connect to the Internet using a real AS number. The proper solution would be a total reconfiguration of the whole network, but of course not many engineers have the time and courage to do it ;), so it's time to introduce another kludge: the neighbor local-as configuration command.

read more see 4 comments

Simplify your lab work

If you do a lot of tests in a router lab, you're probably getting upset when you have to retype the login and enable password whenever you log into a router. What I do in my labs is to disable VTY login, set the default privilege level to 15 and disable exec timeout (to stop the router from terminating my session).

line con 0
 exec-timeout 0 0
 privilege level 15
line vty 0 4
 exec-timeout 0 0
 privilege level 15
 no login

Obviously, this would not bring you additional points on the CCIE lab exam :)

see 2 comments

Configure the default route based on the presence of a BGP session

You've probably already heard the phrase "When the only tool you have is a hammer, everything looks like a nail" (and seen people acting according to it). Likewise, if you have an IOS release with EEM support, a lot of things that would require smart design could be solved in a brute-force way with a few EEM applets. For example, the problem of the BGP default route could be solved “easily” with a few applets that track syslog messages reporting when the BGP neighbors go up/down.
read more see 7 comments

Define new IOS commands with the alias functionality

Cisco IOS allows you to define aliases for the commands you commonly use with the alias global configuration command. The alias command accepts the CLI mode (exec, configuration ...) for the new command and the string that replaces the command name. If you specify additional parameters in the new command, they are appended to the alias string.

For example, if want to have the ipconfig command that displays interface IP configuration, you can configure alias exec ipconfig show ip interface. When you execute ipconfig ifname the alias is expanded into show ip interface ifname and displays the IP configuration of a single interface.
add comment
Sidebar