RIP Authentication

[BlueyVIII]

Hello,

I'm implementing RIP in our network for the first time and I haven't worked with RIP for a long time so please bear with me.

My understanding is that when I enable RIP on our 6500 MSFC it will enable RIP on all interfaces. To mitigate this I plan to using authentication to the RIP router which I must exchange routes with. However, looking at the command reference guide I suspect that the authentication will only apply to interface which I apply it to.

For example, if I use the following configuration on interface Gi1/1 then only the RIP packets on interface gi1/1 will be authenticated.

interface Gi1/1

  ip address 141.108.0.10 255.255.255.252

  ip rip authentication key-chain kay

If someone plugs in a RIP enabled router into another port then there's a possibility that router could cause problems with our network by advertising conficting routes.

I thought I might be able to mitigate this by using the command "passive-interface default" but from what I've read, this will only stop the interfaces advertising RIP, it won't stop them processing RIP Packets that are received. Therefore, the only way I can think of to block all incoming RIP advertisements is to do the following :-

access-list 20 deny any

Router RIP

version 2

  no auto-summary

  redistribute eigrp xxx metric 10

  redistribute static metric 10

  passive-interface default

  no passive-interface gi1/1

  distribute list 20 in

Can someone who know's RIP better than me confirm this is correct? Or is there a better way to secure the network from unauthorised RIP advertisements. I only need to advertise routes to 1 RIP router and I don't need to receive any back. I guess I could use an access-list to deny RIP packets and then apply that to every interface but I'd like to try and keep the configuration to a minimum..

[manish arora]

access-list 20 deny any

Router RIP

version 2

  no auto-summary

  redistribute eigrp xxx metric 10

  redistribute static metric 10

  passive-interface default

  no passive-interface gi1/1

  distribute list 20 in

The above will filter all routes , also the one that are being redististributed using static and eigrp. I think you have to place distribute list for the interface and not the RIP process or allow the routes that you want to be redistributed from other process in the access list 20 :-

distribute list 20 in interface gi1/1

Manish

[Peter Paluch · Accepted solution]

Hello Manish,

You are supposing that the distribute-list configured without a reference to an interface applies also to redistributed routes.

That does not seem to be the case - I have just verified that. The distribute-list both in RIP and EIGRP applies only to routes already advertised within that very protocol. It does not influence routes that are being redistributed.

Bluey: I would say your configuration is fine.

Best regards,

Peter

[manish arora]

Hi Peter,

No offence, but how did you verifed that ? I did a similar lab few days back from the following Book :-

http://fengnet.com/book/CCIE%20Professional%20Development%20Routing%20TCPIP%20Volume%20I/ch13lev1sec1.html

example 13-22

It clearly shows that routes are being scaned against the access-list in distribute-list when it is applied for the routing process. It doesn't matter that routes are being learned from a rip process or from via redistribution.

Manish

[Peter Paluch]

Hello Manish,

No offense taken, don't worry

I have verified the working of a distribute-list with a fairly simple topology consisting of two routers. One of them performed a redistribution from static into RIP/EIGRP and I observed the advertised routes on the second router.

The configuration used on the redistributing router was:

ip route 1.0.0.0 255.0.0.0 192.0.2.3
ip route 223.255.255.0 255.255.255.0 192.0.2.2
!
access-list 1 deny   any log
!
router rip
 version 2
 redistribute static
 network 0.0.0.0
 distribute-list 1 in
 no auto-summary

On the second router, I observed that the redistributed routes 1.0.0.0/8 and 223.255.255.0/24 were injected and advertised into the RIP/EIGRP despite the fact that the distribute-list 1 should have filtered them out. In addition, the "log" option in the ACL did not produce any logs, hinting that the ACL was not consulted for the redistribution.

The distribute-list in Example 13-22 of the book you've referenced does not apply to redistribution performed on the box itself. Note that the ACL 2 used for distribute-list on the Bumble router simply allows only the networks that are native to the RIP domain, i.e. 192.168.1.0/24 (on Monks) and 192.168.6.0/24 (between Monks and Grimwig), to be learned by Bumble via RIP. However, this distribute-list does not prevent Bumble from advertising the OSPF routes via RIP to Monks. What it additionaly prevents is learning the OSPF routes via the RIP domain. Once again, the distribute-list concerns only the networks that are either

• received in the corresponding routing protocol from a neighbor (the in direction)
• being sent in the corresponding routing protocol to a neighbor (the out direction)

In both cases, the network must already be injected into the particular routing protocol.

Surely, a distribute-list would apply to all routes, including redistributed routes, if it was used after the redistribution in the out direction. However, that is not the case here.

Best regards,

Peter

[manish arora]

Rated as deserverd !

Thanks Peter, Very well explained ... Cleared my doubts . Infact I redid the simple test myself, cleared ip routes and noted that rip router was still advertising redistributed routes even after the deny all distribute list was in place.

Thanks Again

Manish

[BlueyVIII]

Hey Guys - I just thought I'd let you know that I applied this configuration yesterday and it worked exactly as expected.

Thanks for your help, the debate was interesting.