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″]