trick | IPNET

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.

RIPv2 MD5 authentication – routing trick

I must admit that the following example is more a CCIE exam topic and not a solution that you would add in real network environments.

Let’s assume that we have the following topology:

[adsense_id=”1″]
The Loopback interfaces are there to have some networks which we will advertise into RIPv2. The request for this topic is to have RIPv2 MD5 authentication in place, Router1 to receive all routes from Router2, but Router2 will not have any prefixes in routing table from Router1. Don’t use any access-list, prefix-list, distribution-list, RIP packet version send / receive command under interface…well not use anything which is common to carry out this task.

Let’s start the configuration:
Router 1
!
version 2
network 10.0.0.0
network 192.168.0.0
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
network 192.168.4.0
network 192.168.5.0
no auto-summary
!
!! Let’s define the key chain
!! The RIPv2 MD5 authentication need
!! to have the same key number on
!! both ends
key chain RIP
key 1
key-string cisco
!
!! let’s apply RIPv2 authentication
int fa0/1
ip rip authentication mode md5
ip rip authentication key-chain RIP
!
Now the configuration on Router 2
!
router rip
version 2
network 10.0.0.0
network 172.16.0.0
no auto-summary
!
key chain RIP
key 1
key-string cisco
!
int fa0/0
ip rip authentication mode md5
ip rip authentication key-chain RIP

If you want to check if the RIPv2 authentication is running fine, shutdown / no shutdown one interface and on the other end do:
debug ip rip
You should see something like:
*Mar 12 03:22:08.261: RIP: received packet with MD5 authentication

OK, let’s check the routing tables.

Router1

R1#sh ip route rip
R 172.16.4.0 [120/1] via 10.10.12.2, 00:00:20, FastEthernet0/1
R 172.16.5.0 [120/1] via 10.10.12.2, 00:00:20, FastEthernet0/1
R 172.16.0.0 [120/1] via 10.10.12.2, 00:00:20, FastEthernet0/1
R 172.16.1.0 [120/1] via 10.10.12.2, 00:00:20, FastEthernet0/1
R 172.16.2.0 [120/1] via 10.10.12.2, 00:00:20, FastEthernet0/1
R 172.16.3.0 [120/1] via 10.10.12.2, 00:00:20, FastEthernet0/1

Router 2

R2#sh ip route rip
R 192.168.4.0/24 [120/1] via 10.10.12.1, 00:00:23, FastEthernet0/0
R 192.168.5.0/24 [120/1] via 10.10.12.1, 00:00:23, FastEthernet0/0
R 192.168.0.0/24 [120/1] via 10.10.12.1, 00:00:23, FastEthernet0/0
R 192.168.1.0/24 [120/1] via 10.10.12.1, 00:00:23, FastEthernet0/0
R 192.168.2.0/24 [120/1] via 10.10.12.1, 00:00:23, FastEthernet0/0
R 192.168.3.0/24 [120/1] via 10.10.12.1, 00:00:23, FastEthernet0/0

We have all routes. Until now we just configured a RIPv2 with authentication which is working fine, but still we haven’t accomplish our task.
Here is how we will do it. I found out this recently. I believe some of you already know this trick, but for the rest will be pretty interesting.

MD5 authentication in RIPv2 states that the key number in the key chain has to be the same so everything is running fine. But what if we change one key to a higher number than (in our case) 1?

The result will be that the router with the higher key number will receive ALL routes and the one with the lower key number will receive NO routes. Our task is that R1 has all routes but R2 has no prefixes (from RIP process) in routing table. Since both keys are having number 1, we cannot lower the key number on R2 so we have to increase it on R1

On Router 1
!
R1#conf t
R1(config)#key chain RIP
R1(config-keychain)#no key 1
R1(config)#key chain RIP
R1(config-keychain)#key 5
R1(config-keychain-key)#key-string cisco
R1(config-keychain-key)#end

Let’s check again the routing table on those 2 devices. You may want to clear the IP routing table to speed up the process.

Router 1

R1#sh ip route rip
R 172.16.4.0 [120/1] via 10.10.12.2, 00:00:06, FastEthernet0/1
R 172.16.5.0 [120/1] via 10.10.12.2, 00:00:06, FastEthernet0/1
R 172.16.0.0 [120/1] via 10.10.12.2, 00:00:06, FastEthernet0/1
R 172.16.1.0 [120/1] via 10.10.12.2, 00:00:06, FastEthernet0/1
R 172.16.2.0 [120/1] via 10.10.12.2, 00:00:06, FastEthernet0/1
R 172.16.3.0 [120/1] via 10.10.12.2, 00:00:06, FastEthernet0/1

Router 2

R2#sh ip route rip

There is nothing in the routing table.

Let’s check with ping:

R1#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/13/24 ms

Of course is working, as the source interface from which the packet is send will be the direct connected interface. Let’s try to ping having the source one of the Loopback interfaces on R1:

R1#ping 172.16.1.1 source lo10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
…..
Success rate is 0 percent (0/5)

It’s not working as R2 doesn not have a route back to Loopback10 subnet which is 192.168.0.0 /24

If you’ll do a “debug ip rip” on R2 you will see something like this:

*Mar 12 03:39:57.001: RIP: ignored v2 packet from 10.10.12.1 (invalid authentication)
*Mar 12 03:39:58.261: RIP: received packet with MD5 authentication

I hope this example will help in your preparation.

[adsense_id=”3″]

Cisco: Engineer’s trick to avoid suboptimal path

I was explaining in the previous post what is the difference between optimal and suboptimal path and how to avoid the use of not such a good path in your routed environment. Also there I presented this so call “dirty trick” you can use to force the routing protocol to choose the path that you want, based on the Administrative distance modification.

As I said there is another way (for sure more than one) to do it, using a more elegant approach and from the networking point of view more safe considering the complex routing environment. I will use the same topology like in the previous post to offer you the possibility to compare these 2 methods presented and to choose the one that you understand and fit better to your needs. Also there are some other ways to do it and please feel free to discussed them in the comments section and maybe to present them here in a future post.

We will achive the desired results by setting one community on R1 for the advertised network 192.168.82.1 and dropping the prefixes, marked with the same community, on R2. Please be aware that for this method to work you have to allowed BGP peers to send communities list with the command “neighbor xx.xx.xx.xx send-community …” under “router bgp xxx” process.

Please see the example by clicking the image below: