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: Quick IOS check in 4 simple steps

This post is rather for the beginners in Cisco’s world than for advance professionals, but still I encounter situation when IOS image was corrupted even if it was uploaded to the device by a network guru. Why? It’s quite simple! Because you can be the master of the Cisco networking,  but still sometime you cannot control the device behavior or the transport of the packets to destination.

The problems is that in case of a corrupted IOS image being uploaded on a Cisco device, and having that device reloaded you can run into situation when it will not boot up anymore. When the device is in front of you, or on your desk, there is not a problem, because you can troubleshoot, find the issue (e.g wrong or corrupted IOS image) and solve it! But, what if your device is at 5000 km distance, it is 3:00 AM and you have no professional help on that location?! That’s one ugly situation and the reason for which I always insist to verify the IOS image after it is uploaded and ready to go into production.

For those of you who are dealing with this stuff everyday, this post may seem like a joke, but I bet that there are out there IT’s which never check this stuff or they are beginners and don’t know how to do it. It’s more simple that you may think it is, make you spend about 4-5 minutes for a full check, but can spare you for bigger problems in the future.

So, what are the 4 steps:
1. Check what Cisco device you have (to know what IOS image you need)
2. Check what IOS image Cisco device has (to know what IOS release to download)
3. Verify the IOS image
4. Check the results of your verification
As simplest as it can get.

Please check the tutorial by clicking the image below:

IOS check

For those who cannot see a Flash movie, please read this text file, that consist of the command you should perform for IOS checking.

Cisco: Deny false information routing injection into OSPF domain

In a well controlled environment, false information routing should not reach your OSPF domain, as network engineer take care what to advertise and what not into OSPF. But there are cases when you have to deal with 3rd party companies somehow, and you want to be sure that nothing in injected by mistake into your domain. Also this can be a task for CCIE RS lab exam.

And since I specified that this can be an exam task, let take some “DO NOT USE” rule and we have to accomplish the task above without using the command “ip ospf authentication message-digest”. Download the used topology here. R1 from the topology is pre-configured. The OSPF timers have been reconfigured to hello 1 second and dead interval 5 seconds, not to wait “forever” until it rebuilds the adjacency.

Please see the tutorial below: