Tag: rip

RIPv2 Route Filtering Methods

On By MikeIn CCIELeave a comment

Today we ill be providing route filtering examples for RIPv2 with the below methods.

  • Passive Interfaces
  • Distribute-Lists
  • Offset-Lists
  • Administrative Distance

Passive Interface

Configure a passive interface so that R8 receives routes from R10 but does not advertise routes to R10.

rip.passive.PNG

Configure a passive interface with the passive-interface interface command.

When configuring a passive interface RIPv2 updates are no longer sent out of that interface but RIPv2 updates are still received. We can see this to be true by viewing the rip database for R8 and R10.

rip.passive1

R10 last received and update from R8 two minutes and 35 seconds ago 02:35. Based on this value we know that the routes are on their way to be withdrawn from R10s RIP database and RIB when it meets the default RIP flush timer of 240.

Distribute-Lists 

Distribute-List with prefix-list

On R5, prevent R8 from receiving R6 and R7 Loopback addresses while permitting everything else.

On R5, Prevent R4 from sending IPv4 updates in through Tun 0 while permitting everything else

Here we configured prefix-list R5_STOP_R6R7R8 to prevent R6 Loopback 150.1.6.6 and R7 Lookback 150.1.7.7 and permit everything else. Then applied to the interface leading to R8.

rip.prefix1.PNG

The second prefix-list R5_STOP_R4 will prevent R4 from sending IPv4 updates in through Tun 0 while permitting everything else. We need a “permit any” in our prefix just as you saw int the last one, 0.0.0.0/0 le 32 will accomplish this.

The PERMIT_ALL prefix-list is needed because we are applying this to all interfaces.

This line distribute-list prefix PERMIT_ALL gateway R5_STOP_R4 in is saying permit all routes on all interfaces as long as it didn’t come from R4 155.1.0.4.

Distribute-List with standard access-list

Here is how we can filter the IPv4 prefixes with an even number in the third octet with a one line standard access-list.

rip.access3

Distribute-List with extended access-list

When an extended access-list is used as a distributed-list in IGP application, it is important to remember that the behavior of the access-list changes. Instead of the source representing the network address and the destination representing subnetmask.

The source field in the ACL matches the update source of the route (who is sending us the route), and the destination field represents the network address.

access-list 100 deny ip host 155.1.0.3 host 155.1.7.0
access-list 100 deny ip host 155.1.0.3 host 155.1.9.0
access-list 100 deny ip host 155.1.0.1 host 155.1.146.0
access-list 100 deny ip host 155.1.0.1 host 150.1.1.1
access-list 100 permit ip any any

Offset-list

An offset-list was configured to prevent R9 from installing 150.1.5.5. Hop count was set to 16 to poison R9 and have it remove it from it routing table and to prevent R9 from installing it in the future.

rip.offset

You can see that R9 won’t install the route because of 150.1.5.5 having a hop count of infinite (16). The off-set list  worked.

rip.offset2

Administrative Distance

I want to configure an administrative distance so that hosts in the network cannot reach R4s Loopback.

The first is to create an access-list for R4s Lookback address. Then to apply it under the routing process.

rip.ad

These scenarios were curated by INE. Thank you to them.

Mike

Advertisement

RIPv2 Authentication

On By MikeIn CCIELeave a comment

RIP is an old distance vector routing protocol. I wanted to give a quick over view of a potential problem when using authentication with RIP.

Below is the topology that we will be using.

rip.auth1

RIPv2 has been enable on R1,R2, and R3. We have full reachability between our nodes. I have enabled plain text authentication on each link. Here is R2s output.

rip.auth2

Key Chain = PASSWORD_TEXT
Key Number = 1
Key String = CCIE

I am going to setup a packet capture so we can view our RIP packets.

rip.auth3

Notice that R2 10.0.12.2 is sending updates to the Multicast address for RIP 224.0.0.9. Authentication type: Simple password. Our password is CCIE. One thing in particular is that the Key identifier or our key number in our case 1 is arbitrary.

RIP plain text authentication doesn’t transmit the key identifier so you could have different key numbers on each of our routers. Say R1 = Key 1, R2 = Key 2, R3 = Key 3 and authentication would succeed as long as the password matches.

Lets switch our plain text authentication to use MD5 authentication between R1 and R2.

rip.auth4

I created a new key chain and used MD5 authentication between R1 and R2. The link between R2 and R3 are still using plain text authentication.

Key Chain = PASSWORD_MD5
Key Number = 2
Key String = CCIE

I’ll setup a new packet capture between R1 and R2.

rip.auth5

We have the same information as our last capture with two slight differences. We are using Authentication type: MD5 and now have a Key identifier field Key ID: 2

I’m going to change the Key ID on R1 to 1. Let’s see what happens when we have two different Key IDs.

rip.auth6

R1 is now using Key ID of 1. And below you see R1 ignoring RIP updates from R2 because authentication failed.

rip.auth7

The point here is that when using RIP authentication with MD5 the Key identifier needs to match between routers. You see this in the packet capture, the Key identifier field is transmitted in the RIP payload. If Key ID differs, authentication will fail.

Mike