Cisco BGP soft-reconfiguration and received-routes relation

A while ago I received the following question:

“Why I’m not seeing the prefixes received from the BGP peer when using the show ip bgp neighbors x.x.x.x received-routes while the soft-reconfiguration inbound is not enabled?”

I must admit that I had to stop and think for a second before giving my response.

Simple BGP

For the above diagram I have a simple BGP configuration:

router bgp 65301
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 192.168.0.2 remote-as 65302
 neighbor 192.168.0.2 timers 5 15
 !
 address-family ipv4
  network 1.1.1.1 mask 255.255.255.255
  network 2.2.2.2 mask 255.255.255.255
  network 3.3.3.3 mask 255.255.255.255
  neighbor 192.168.0.2 activate
 exit-address-family
router bgp 65302
 bgp log-neighbor-changes
 neighbor 192.168.0.1 remote-as 65301
 neighbor 192.168.0.1 timers 5 15

Focus is on the secondary router. I’m trying to see what prefixes I receive from my BGP neighbor, so I rapidly hit the following command:

R2#sh ip bgp neighbors 192.168.0.1 received-routes
% Inbound soft reconfiguration not enabled on 192.168.0.1

OK, that’s not good. Am I missing the command? Let’s see:

R2#sh ip bgp neighbors 192.168.0.1 ?
  advertised-routes  Display the routes advertised to a BGP neighbor
  dampened-routes    Display the dampened routes received from neighbor (eBGP
                     peers only)
  flap-statistics    Display flap statistics of the routes learned from
                     neighbor (eBGP peers only)
  paths              Display AS paths learned from neighbor
  policy             Display neighbor polices per address-family
  received           Display information received from a BGP neighbor
  received-routes    Display the received routes from neighbor
  routes             Display routes learned from neighbor
  |                  Output modifiers

-> received-routes – Display the received routes from neighbor

OK, I know the soft-reconfiguration inbound is not enabled, but what has this to do with the fact that the command is not showing me what routes I receive from BGP neighbor?

Let’s recall what “soft-reconfiguration inbound” command actually does.

BGP soft-reconfiguration inbound
*Cisco BGP-4 Command and Configuration Handbook

According to the above explanation, if you have an inbound policy (like a route-map) applied to a BGP neighbor and you change that policy, you need to clear the BGP session before it take effect. This is the procedure without having “soft-reconfiguration inbound” configured. I remember it like this and most of the network engineers out there remember this behavior associated with the “soft-reconfiguration inbound” command.

Still, I just want to see what routes I received from BGP neighbor and according with “sh ip bgp neighbors 192.168.0.1 received-routes” description is the right command . I have no inbound policy on R2 for R1 BGP neighbor.

A less remembered fact about the “soft-reconfiguration inbound” command is that when added, the router begins to store updates from the specified neighbor. These updates are unmodified by any existing inbound policies so that the router can correctly apply the new policies when soft reconfiguration is triggered.

Where are these updates stored?

In the BGP Adj-RIB-in (Adjacent Routing Information Base, Incoming) table. So, what the “received-routes” command does actually is looking in the BGP Adj-RIB-in table for the received routes from the BGP neighbor. I consider that the “received-routes” command has an ambiguous explanation leading to confusion.

When “soft-reconfiguration inbound” is not present, the BGP router does not store anything in Adj-RIB-in. Rather it process the update and discard the Adj-RIB-in table, but not before adding the information in the Loc-RIB (Local Routing Information Base) table. Knowing these facts of course the BGP router returns an error when trying to check the received prefixes using the “received-routes” command.

To check actually what’s received from BGP peer and stored in the Loc-RIB (after being processed by inbound policies) use only the “routes” parameter in the command:

R2#sh ip bgp neighbors 192.168.0.1 routes | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i
 *>  3.3.3.3/32       192.168.0.1              0             0 65301 i

Total number of prefixes 3

-> routes – Display routes learned from neighbor

The output is what exists in the Loc-RIB table, after processed by the inbound policy.

Let me show you an example of the above explanation.

I’ll apply the “soft-reconfiguration inbound” first:

R2(config-router)#neighbor 192.168.0.1 soft-reconfiguration inbound

Now I’ll check again the received routes:

R2#sh ip bgp neighbors 192.168.0.1 received-routes  | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i
 *>  3.3.3.3/32       192.168.0.1              0             0 65301 i

Total number of prefixes 3

OK, so I have three prefixes, reflected in the Adj-RIB-in table.
Checking next the Loc-RIB tables (so the routes installed after being processed by inbound policies):

R2#sh ip bgp neighbors 192.168.0.1 routes | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i
 *>  3.3.3.3/32       192.168.0.1              0             0 65301 i

Total number of prefixes 3

The Adj-RIB-in and Loc-RIB tables are identical.

Now, I’ll apply an inbound policy that will filter the 3.3.3.3 prefix.

R2(config)#ip prefix-list LIST permit 3.3.3.3/32
R2(config)#route-map INBOUND deny 10
R2(config-route-map)#match ip address prefix-list LIST
R2(config-route-map)#route-map INBOUND permit 1000
R2(config-route-map)#router bgp 65302
R2(config-router)#neighbor 192.168.0.1 route-map INBOUND in

OK, we have the “soft-reconfiguration inbound” in place, so the inbound policies should be applied automatically denying the 3.3.3.3 prefix.

R2#sh ip bgp neighbors 192.168.0.1 received-routes | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i
 *   3.3.3.3/32       192.168.0.1              0             0 65301 i

The above output is what we receive from BGP peer. Notice that the 3.3.3.3 prefix is still there, in the Adj-RIB-in table, as the inbound policies are not applied yet. The only visible change is the missing > sign (best).

R2#sh ip bgp neighbors 192.168.0.1 routes | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i

Now we can see that the inbound policy is working fine as the 3.3.3.3 prefix is not installed in the Loc-RIB table. This is also the explanation why the > (best) sign was missing from the 3.3.3.3 prefix in Adj-RIB-in.

I hope you understood the logic behind the confusion which these commands “received-routes” and “routes” and their explanation in IOS is creates.

Please let me know in Comments if you have any questions.

CCIE Home Lab, what to do when your router has too little Flash space for IOS

I already explained in an older post my home lab for CCIE preparation. My BB1-BB3 routers are Cisco 2600 series and the rest of R1-R6 are emulated with Dynamips. The only problem is that one of the C2600 has too little Flash space to hold the required IOS. Memory is sufficient, but Flash not.

The only workaround I have is to load the IOS image from a TFTP server. I will explain here my procedure, maybe it’s useful for somebody else out there.

First, I recently upgrade to Ubuntu 12.04 and for some reason the TFTPD (default tftp server) was not working properly. I found TFTPD-HPA to be a good alernative, so I did install it:

sudo apt-get install tftpd-hpa

After installation you may want to check /etc/default/tftpd-hpa. On my system it looks like this:

# /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure"

Next step is to get a IOS image and copy it under /var/lib/tftpboot. If you need a hint, I’m using c2600-adventerprisek9-mz.124-25d.bin which needs only a small amount of memory to be installed on the Cisco 2600 platform and it’s enough for testing.

Now we need to get the IOS image on the C2600 using TFTP. Depending on your topology used for CCIE exam practice, this can be done in different ways.

Currently I’m using the workbooks from Micronicstraining (Narbik’s workbooks, if this sounds more familiar). Previously I used the ones from Internetwork Expert. The idea is that topology is pretty similar and it looks something like this:

MicronicsTraining
Narbik’s workbook topology

My problematic router is the BB3. Somehow I need that BB3 is communicating with my Ubuntu server, as simple as possible, without changing ethernet cables all the time.
You noticed int the above diagram that BB3 has an interface on the SW1 (Fa0/13) and SW1 has F0/1 connected to my Ubuntu server as explained in this post. What I need is to have Fa0/13 and Fa0/1 on the SW1 on the same VLAN for proper communication. Usually I just default the interface and then everything is fine.

On the Ubuntu box, I can have an IP address on the physical card (this will not influence in any way the Dynamips emulated router attached to this interface):

eth1      Link encap:Ethernet  HWaddr 00:e0:b6:06:a6:3b
          inet addr:192.168.182.1  Bcast:192.168.182.255  Mask:255.255.255.0
          inet6 addr: fe80::2e0:b6ff:fe06:a63b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:64 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:14100 (14.1 KB)

By default on the BB3 router I have an IOS image that can fit the Flash size (c2600-i-mz.123-26.bin) and in case that for some reasons the TFTP Server is not reachable, it will boot that image.

The BB3 startup-configuration looks like this:

interface FastEthernet0/0
 ip address 192.168.182.13 255.255.255.0
!
boot system tftp c2600-adventerprisek9-mz.124-25d.bin 192.168.182.1

What you have to remember:
1. Start your TFTP server and assure that it has the correct IP address on the interface where you will server IOS files
2. Start your switch (if you have one in between Cisco router and the TFTP server) and be sure that the interfaces are able to exchange packet (same VLAN, etc)
3. Start your Router

In case you did miss any of the above steps, you’ll see something like this:

%SYS-4-CONFIG_NEWER: Configuration from version 12.4 may not be correctly understood
 Slot is empty or does not support clock participate
 WIC slot is empty or does not support clock participate
%SYS-6-READ_BOOTFILE_FAIL: tftp://192.168.182.1/c2600-adventerprisek9-mz.124-25d.bin File read failed -- Timed out.

 Hello from IFS_TYPE_ROM successful type-check

%SYS-6-BOOT_MESSAGES: Messages above this line are from the boot loader.
boot of "tftp:c2600-adventerprisek9-mz.124-25d.bin 192.168.182.1" using boot helper "flash:c2600-i-mz.123-26.bin" failed
error returned: File read failed -- Timed out
loadprog: error - on file open
boot: cannot load "tftp:c2600-adventerprisek9-mz.124-25d.bin 192.168.182.1"

and the router will boot your image stored locally on Flash.

Instead of doing all this work, which may generate some headache, I could just buy another router with enough Flash (and Memory). Currently I don’t want to make this investment, so I’ll stick with the above scenario.


[Infographic] The Journey to Cisco Certification Success

I found this great Infographic on Pinterest and I felt the need to share it though my blog. Even if not all information are 100% accurate of complete, it’s still a nice view that worth spending some minutes to check.


BGP Conditional Advertisement

BGP Conditional Advertisement – it let the impression of a very complex task. Actually you will find it very easy to implement once you understand it.

In simple words I would say  that BGP conditional advertisement it’s a feature that let you advertise a prefix to one of your neighbors if mandatory condition is satisfied. To implement this feature you must configure at least two of the following three maps:

– Advertise-map -> this contains the selected prefixes which will be advertised if the mandatory condition is satisfied
– Exist-map -> condition to be satisfied (e.g. advertise the prefixes in the “advertise-map” only if the prefixes in this condition exist)
– Non-exist-map -> condition to be satisfied (e.g. advertise the prefixes in the “advertise-map” only if the prefixes in this condition doesn’t exist)

Let’s take an example. We have the following topology:

We have here a simple topology, with eBGP peering between R1 – R2 and R2 – R3. Each router has a Loopback interface with the following IP addresses:

R1 – L0 – 1.1.1.1 /24
R2 -L0 – 2.2.2.2 /24
R3 – L0 – 3.3.3.3 /24

These interfaces are advertised into BGP and they have full reachability:

R2#sh ip bgp sum | b Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.12.1      4   100       5       4        0    0    0 00:01:27        1
10.10.23.3      4   300       2       2        0    0    0 00:00:24        0

R2#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.10.12.1               0             0 100 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       10.10.23.3               0             0 300 i

R2#sh ip route bgp
     1.0.0.0/24 is subnetted, 1 subnets
B       1.1.1.0 [20/0] via 10.10.12.1, 00:04:02
     3.0.0.0/24 is subnetted, 1 subnets
B       3.3.3.0 [20/0] via 10.10.23.3, 00:04:02

Task

An easy task would ask you to solve something like if 1.1.1.0 /24 is NOT in the BGP table of R2, then R2 should advertise its 2.2.2.0 /24 to R3.

Solution

Let’s analyze this request a little bit. The prefix to be advertised or not, depending of the satisfaction of the condition, is 2.2.2.0 /24. According to what I said before about the necessary “maps” for BGP conditional advertisement, this prefix will go into the “advertise-map”. R2 is the only router you need to configure to accomplish this task.

conf t
access-list 2 permit 2.2.2.0 0.0.0.255
route-map ADVERTISE permit 10
match ip address 2

OK, we have the advertisement map. What about the condition? The task request that 2.2.2.0 /24 should be advertised if 1.1.1.0 / 24 does NOT exist in the BGP table of R2. Using logical deduction we can say that “non-exist-map” is what we need to configure.

conf t
access-list 1 permit 1.1.1.1 0.0.0.255
route-map NOT-EXIST permit 10
match ip address 1

Let’s add everything together in BGP:

conf t
router bgp 200
neighbor 10.10.23.3 advertise-map ADVERTISE non-exist-map NOT-EXIST

Verification

On R2 check the BGP table:

R2#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.10.12.1               0             0 100 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       10.10.23.3               0             0 300 i

We have the 1.1.1.0 /24 prefix in the BGP table. According to our task, 2.2.2.0 /24 should be advertised if 1.1.1.0 /24 does NOT EXIST. By analogy, if 1.1.1.0 /24 EXIST, the 2.2.2.0 /24 should NOT be advertised. You see? It’s just a tricky words game.

R2#sh ip bgp neigh 10.10.23.3 adv | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.10.12.1               0             0 100 i

Total number of prefixes 1 

We advertise only one network. The 2.2.2.0 /24 is not advertised to R3:

R3#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.10.23.2                             0 200 100 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

To check that the conditional advertisement really works, stop R1 from announcing 1.1.1.0 /24 in BGP. You can just shutdown the interface.
Check if the L0 of R1 is in the routing table / BGP table of R2:

R2#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       10.10.23.3               0             0 300 i

1.1.1.0 /24 is not in the BGP table of R2, then 2.2.2.0 /24 should be advertised to R3:

R2#sh ip bgp neigh 10.10.23.3 adv | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.0/24       0.0.0.0                  0         32768 i

Total number of prefixes 1 

On R3:

R3#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.0/24       10.10.23.2               0             0 200 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

Remember that usually in the exams, the tasks related to BGP Conditional Advertisement are more word tricks than complex. As an example, base on the above topology, resolve the following:
– If 1.1.1.0 /24 and 2.2.2.0 /24 are both in the BGP table of R2, both prefixes should be advertised to R3
– If 1.1.1.0 /24 is not in the BGP table of R2, then 2.2.2.0 /24 should not be advertised to R3
– If 1.1.1.0 /24 and 2.2.2.0 /24 are not in the BGP table of R2, then none of them should be advertised to R3

If you don’t understand the trick, let me know and I will explain.


New blog section – Certification

I don’t know how many of my blog visitors had the curiosity to visit the About section to read something about me. If some of you did read that section, then you already know that I have several certifications from Cisco and other vendors and I’m on my way to CCIE. A long road with a slow progress due to my busy professional life.

These being said, I want to announce a new section of my blog called “Certification”. In this section I will discuss only about certifications and related topics like training providers, exam scenarios and tasks, recommended approach and so on. I will try to help engineers on the same path as me and, why not, ask for help when I have a blocking point.

I have some years of network engineering field experience, I attended some exams and for a while I’m preparing for the CCIE R&S exam, so I think I can do a good job in this section. Compared to other sections the technical parts discussed here will be more oriented to exams, and not real networking challenges.

I hope my experience together with your contribution with comments and suggestions to make this section interesting.

Last words. If you hope to find here braindumps or materials that violate the NDA (no matter if is Cisco or other vendor), then you are in the wrong place.