Sometimes you'll see a weird route status (RIB-failure) in your BGP table, for example:

GW#show ip bgp ¦ include r>
r> 10.2.0.0/16      10.0.1.2                 0             0 65001 i

A more thorough investigation of the BGP entry does not give you a lot of additional information:

GW#show ip bgp 10.2.0.0
BGP routing table entry for 10.2.0.0/16, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Flag: 0x820
  Advertised to update-groups:
        1    2
  65001
    10.0.1.2 from 10.0.1.2 (10.0.1.2)
      Origin IGP, metric 0, localpref 100, valid, external, best

The “mistery” is solved when you inspect the entry in the IP routing table:

When writing EEM applets or policies that act on CLI commands, keep in mind that the pattern matching is not context sensitive. For example, if you want to disable the reload command and use the EEM applet …

event manager applet NoReload
 event cli pattern "reload" sync no skip yes

… you cannot enter the action x.y reload configuration command any more (or any other command that includes the string reload).

To distinguish the reload command from other appearances of the same string, use the ^reload pattern (reload occuring at the beginning of the line).

Occasionally someone would try to persuade me that the layer-2 VPN services are like aspirin (you know, totally harmless plus it could get rid of all your headaches). OK, that might be true if you take the layer-2 VPN offering as a pure transport solution and plug in an extra router (sometimes also called a layer-3 switch by marketing people) between the Service Provider’s Ethernet (or whatever they give you) and your LAN. But there are people who don’t know the details and plug the SP Ethernet straight into their L2 switch … and things might even work for a while … until the whole network collapses.

You've probably heard the joke about the honest salesmen: it's not that they're lying, what they know isn't true. I had a similar problem recently: in the 10 MPLS traffic engineering myths and half truths I wrote “Half-truth: MPLS TE only works with OSPF and IS-IS routing protocols.” Ivan Kuchin understood that as “You can run MPLS TE without OSPF or IS-IS.” Although I haven't written that anywhere, I also thought that was the case … so let me try to weasel out of this mess.

The action cli commands used in EEM applets as well as the cli* Tcl functions used in EEM Tcl policies open a virtual Telnet session to a VTY line to execute the CLI commands. The first command you have to execute in the EEM applet is thus the enable command to ensure the next commands will be executed with privilege level 15.

You don't have to specify the enable password.

Likewise, if you want to configure the router, the next command to execute is the configure terminal command, followed by the configuration commands.

You might have been there before: the BGP neighbor becomes reachable after you fix a fault in the network, but the BGP session takes “forever” to be established (actually, the hold off is less than a minute, but time is running slower when you are waiting for the network to recover). However, when testing the BGP fast peering session deactivation, I made an interesting discovery: the restart time is improved as well; as soon as the path to the BGP neighbor appears in the IP routing table, the BGP session is established. The debugging printouts from my router are included below (I've used neighbor 10.0.3.3 fall-over configuration command):

In response to my post about combining Tcl shell with EEM to get around the “no prompts” limitation of EEM action cli command, Xavier proposed using the undocumented pattern option of the action cli command, which changes the string the EEM script is expecting to indicate that the current command has been executed.

By default, the EEM action cli command waits until it receives exec-level prompt from the VTY (Router> or Router#), resulting in an endless wait and aborted EEM applet in IOS release 12.4(15)T (earlier releases would hang a VTY line forever) if a CLI command returns an additional prompt. With the pattern option, you can change the expected reply to whatever prompt the CLI command is outputting.

Designing and operating large BGP networks has always been a challenge, as you have to deploy BGP on all core routers and design a hierarchy of internal BGP routers to get around the full-mesh limitation. When MPLS was introduced, it gave us means of deploying BGP only on the network edges, with the core routers carrying just the information about the BGP next hops.

As I know some of you run large networks, could you help me understand what you're using (without giving away too much information, of course):

We all know that BGP is meant to converge slowly… well, the MPLS/VPN service providers tend to disagree, as their users are not used to minute-long convergence times. One of the major components of slow BGP convergence is the time it takes a router to discover that a neighbor has disappeared. Traditionally, the BGP keepalive packets were sent every minute and it took up to three minutes to discover that a neighbor is down.

Of course you could fine-tune those times with the neighbor timers configuration command, but the reduced timers resulted in increased TCP traffic and consequently increased CPU load, which could reach tens of percents if the timers were set to a few seconds and the router had lots of BGP neighbors.

After I've fixed the default routing in my home office, I've stumbled across another problem: the two ISPs I'm using for my primary and backup link have DNS servers that reply solely to the DNS requests sent from their own IP address range:

When the traffic is switched from the primary to the backup ISP, I therefore also need to switch the DNS servers. Fortunately, this is quite easy to do on a router; you just need to configure ppp ipcp dns request on the dialer interface and the router starts asking for the DNS server address as part of the IPCP negotiation.