INE Workbook Vol 1 RIP

Starting on RIP today. So many people forget about RIP and don't think it's a big deal, but I've seen many scenarios where RIP and it's nuances can really get you. So never forget anything, cover the entire blueprint!!

During task 1, I just blindly enabled RIP across all my routers. This is fine, but I need to change my mindset to immediately think of what problems I may encounter with RIP within my topology, especially items such as split-horizon and authentication with backbone routers. Also, an easy way to check your MD5/text password is to do "show key chain" which will place your configured passwords in quotations. This way, if there is a trailing space messing up your authentication, you will now see it!

This isn't new to me, but 'show ip interface s0/0' will show split-horizon behavior...


R5(config)#do sh ip int s0/0
Serial0/0 is up, line protocol is up
  Internet address is 155.1.0.5/24
  Broadcast address is 255.255.255.255
  Address determined by non-volatile memory
  MTU is 1500 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Multicast reserved groups joined: 224.0.0.9
  Outgoing access list is not set
  Inbound  access list is not set
  Proxy ARP is enabled
  Local Proxy ARP is disabled
  Security level is default
  Split horizon is disabled
  ......


To disable split horizon...



R5(config)#int s0/0

R5(config-if)#no ip split-horizon

When changing RIP timers, you can change the hello timer on an interface basis (say for another RIP domain or BB routers)..

router rip

timers basic 10 60 60 80

int f0/0

ip rip advertise 30

You can use a '0' access list with offset-list. This will simply permit all prefixes to be offset.

router rip
offset-list 0 out 5 f0/0.146


INE presented an interesting scenario where a rip summary is configured on R4, advertised to it's neighbor R5 with split-horizon disabled, bounced back to R4, which then installs it's own summary pointing to R5. Wow, that was kind of crazy. The solution was to install a null route on R4 which was generating the summary. Other routing protocols already do this. You could also do offset-list/distribute lists to prevent the summary from be advertised back to itself. This would be something to keep an eye out for on the lab exam!


One thing that always trips me up is using an extended ACL to filter routes in RIP. I can always put it together that I need to you a distribute-list, but I always forget..network routes or host routes? Crap. Here is the config to filter VLAN 7 and 9 from R3 and filter VLAN146 and R1 Lo0 from R1.


router rip
distribute-list 100 in s0/0
!

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.0
access-list 100 permit ip any

So you match the route source (or gateway) first using a host statement, and then you match the route subnet address with another host statement.


I had another task that asks to use an offset-list to filter a route for VLAN5 from SW1 to SW3 which are connected via VLAN79. Ok, simple enough. I do a 'sh ip rip database' on SW3 to see the hop count SW3 is receiving for vlan 5.



155.1.5.0/24
    [3] via 155.1.79.7, 00:00:03, Vlan79

Ok, now to configure this on SW1.

access-list 1 permit 155.1.5.0 0.0.0.255
router rip
offset-list 1 out 13 vl79


In essence, SW1 receive 155.1.5.0/24 with a hop count of two, so when I add 13 to two on the advertisement out of SW1, I will advertise this to SW3 with a hop count of 16. When SW3 goes to add this to it's routing table, it will find the route inaccessible and will not install the route. This is where I prefer Narbik over INE. Their solution was like this:


router rip
offset-list 1 out 16 vlan79
!
access-list 1 permit 155.1.5.0


Does that work? Sure it does! If you advertise anything out with a metric of 16 it will be poisoned. Narbik's point is that you need to really understand the protocol and what is going on. And in the end, if a proctor hand-grades your lab, and see something very specific such as that, it may make the difference between pass or fail.

Another good scenario was showing how the distance command can affect routing within the RIP domain. If you blackhole a route (distance 255), RIP cannot advertise a route that it does not have in it's domain. This is similar to EIGRP.

Be aware that when you advertise a default route out only one interface (route map set-interface command) that default route can make it's way back to the originating router in on another interface. This will loop around the network, incrementing along the way until it is unreachable. This is similar to the summary issue above. If you advertise out all interfaces, this will never happen because of split horizon. Otherwise you can do the usual static null route or distribute list to curb this activity.

I don't have many other notes from RIP. One thing I did come across was IPCP. You can use PPP to assign IP addresses. Use 'peer default ip add x.x.x.x' on one side, and 'ip address negotiated' on the other side.This affects RIP because the two links negotiate a host route and are no longer considered on the same network. So you would need to enable 'no validate update-source' within the RIP process to get them talking.

Well, that is it for now. I am enjoying the INE workbook so far. I like the very thorough step-by-step process and validating using debugs. As a result, I am finding myself using debugging more and more. I am hoping to study some more tomorrow, and then I have a CCIE study group I will be joining later in the evening. As always, if you have any questions, feel free to post them.