Archive

Archive for the ‘RIP’ Category

RIP – request and response packets

August 10, 2012 1 comment

I was discussing the other day with someone on IRC about a RIP issue he had.
Apparently he had RIP request packets coming in and then all routers were
responding with response packets with full routing table. It seemed like some
kind of amplification attack. That made me realize that I didn’t even know RIP
uses request and response packets. This is very overkill for the CCIE but you
want to know the protocols not just pass a test right? So I then went on to
read the RFC and realized this was the first time reading it.

So when a router boots up or has its RIP process started the following happens.
The router sends a RIP request packet to either 255.255.255.255 or 224.0.0.9
depending on which version is running (who runs v1?). The packet looks like
this.

We see that the command is request and it is basically a packet with no
address information and the metric set to 16 (infinity).

Now the routers hearing this request will respond with a response packet.
It looks like this.

So the other router responds with all RIP routes that it has in its routing
table. The updates that RIP sends every 30 seconds are basically unsolicited
response packets. So why do we have request packets in the first case? It’s
a way of speeding up the convergence process so when a router boots up it
gets the routes immediately instead of waiting for in worst case 30 seconds
before hearing a RIP update.

So that should give you some more insight into RIP. I might do a followup post
on flash updates and suppression of null updates as well.

Advertisements
Categories: CCIE, RIP Tags: , , , ,

RIP MD5 authentication – mismatch in key ID

August 7, 2012 Leave a comment

This is an interesting fact I just found out. When we configure MD5
authentication for RIP they key-ID and key-string must match, this is
well known. But what happens if we actually configure the wrong key-ID?
Take a look at the following config.

R1#sh run | s key chain
key chain RIP
 key 1
   key-string cisco
R2#sh run | s key chain
key chain RIP
 key 2
   key-string cisco

So R2 has a higher key-ID. No routes should be passing right? Wrong.
R2 will accept routes from R1 because it has the higher ID however
R1 will not accept routes from R2.

R1#show ip route rip

RIP: ignored v2 packet from 10.10.1.2 (invalid authentication)
R2#show ip route rip
     1.0.0.0/24 is subnetted, 1 subnets
R       1.1.1.0 [120/1] via 10.10.1.1, 00:00:26, FastEthernet0/0

RIP: received packet with MD5 authentication

The only thing I can think of why this works is that it is some form
of rollover process where they older key-ID is accepted until routers
have been migrated to the new ID. It is strange that it works though
since key-ID 1 does not exist on R2.

If we change the password on R1 then the authentication will fail on R2
also.

RIP: ignored v2 packet from 10.10.1.1 (invalid authentication)

So the password is surely checked but they key-ID is ignored if a higher
key-ID is locally configured.

If anyone has some background on this I would be very interested. All I
could find was a RFC for MD5 for RIP. It mentioned something about key rollover
but nothing definite.

Categories: CCIE, RIP Tags: , , , ,

RIP timers

October 15, 2011 4 comments

RIP timers are the most basic thing in the world right? Even the command to set them is named timers basic… However in some documentation it is not really clear what the difference is between the invalid and holddown timer. The default timers are 30 for updates, 180 for invalid, 180 for holddown and 240 for flush. I have heard and seen described in official documentation that when a route is in holddown it will not accept routes with a worse metric but routes with a better metric. This is however not true. First lets describe the different timers.

Updates – Updates are sent every 30 seconds by default to the address 224.0.0.9.

Invalid – If there has not been any updates for 180 seconds about the prefix it is consider invalid and the route will be poisoned (route advertised with a metric of 16).

Holddown – The timer for holddown will be activated when the route goes into an invalid state. This is set to 180 by default.

Flush – This timer is set to 240 seconds, when a routes is 240 seconds old it is flushed from the routing table.

So the holddown timer is used to stabilize the topology, even better routes will be suppressed which is not what some documentation says. Here is how I tested it.

I created a topology with 3 routers connecting to each other and both the routers announced 1.1.1.1/32 to the middle router. I created an ACL on the middle router to filter all traffic so that the best route will become invalid. On the third router I used an offset-list to make the route worse. After the route became invalid I stopped sending the route with a worse metric and sent it with a better metric. However the route is still not installed until the holddown timer has expired. If you manipulate the timers it is easier to see. I used 5 seconds for updates, 30 for invalid, 30 for holddown and flush of 240. You will see that it takes 60s before the route gets installed.

If you use the standard timers the holddown timer will not expire before the route is flushed since the 180 seconds start counting after 180s by default and then there is only 60s left until the route is flushed. Try this out for yourself and see if you get the same results as I.

Here is a good link describing the timers.

Categories: CCIE, RIP, Routing Tags: , , , ,

Conditional default route – RIP

October 13, 2011 2 comments

I did Vol1 RIP labs yesterday and I wanted to show you some cool stuff. How to do conditional default routing, this is lab stuff but some of it is definetely useful for real life deployments as well. I will be demonstrating RIP but the concepts are the same for other IGPs as well. I will show how to do it in two different ways. Lets start out with the topology.

This network has two exit paths to the Internet which is simulated by two routers with a loopback of 1.1.1.1. R2 has a static default route to ISP B which is the secondary exit. This route has an AD of 130 so it will only be used when the primary exit via RIP to ISP A is down. I have preconfigured the routers with addresses and the static route on R2 for ISP B. You can download the .net file and initial configs here.

Lets start by enabling RIP on R1 and R2. No routes will be learned since we only have a local link between them. We will now configure R1 to advertise a default route.

Let’s check R2 if we can see the route.

Yes it is there. This is not a very dynamic setup however. R1 will announce the route even if it looses the link to ISP A. Remember that RIP does not need to have a default route in its own RIB for it to announce it to neighbors. We will prove this by shutting down link to ISP A.

Interface has been shutdown. Is route still available at R2?

Yes it is. We now have a blackhole. Traffic will reach R1 and then it will be blackholed. Lets look at a way of solving this.

We can create a route-map and tie this to the advertisement of the default route. The route-map will wheck that the ISP A link (150.1.11.0/24) is in the routing table before advertising the default to R2. If the link to ISP A goes down the default should disappear, lets try this out.

We then shutdown the interface on R1.

We check R2, before and after shutdown of interface to ISP A.

If we debug RIP on R1 we can see that it poisions the route and sends it to R2 (hop count 16).

Now we have a way of doing a conditional default if the interface goes down. How can we solve a situation where we have issues but the interface stays up? Maybe we are connected via a fibre converter, not an optimal solution but sometimes we don’t get to decide.

Time to get funky, IP SLA is our friend. The basic idea is still the same. We will create a dummy route in R1 routing table. This dummy route will only be installed as long as R1 can ping ISP A IP address. If it can’t it will remove the dummy route and stop announcing the default route. We start by configuring R1.

We have a prefix-list that matches the dummy route. We use IP SLA to ping the other side, this is more reliable than relying on link down on the interface. Then we have the dummy route that is tied to track 1. Track 1 tracks the status of the SLA ping. We then have a route-map that looks for the dummy route prefix. If this prefix is missing we will stop announcing the default route. Lets look at R1 to see that the SLA is succeeding and that the dummy route is installed.

The reason we see some failures is because I had the interface shutdown when I brought the SLA probe online. Lets check that R2 still has a default route.

Indeed it does. Now lets see what happens when R1 can’t ping ISP A. I will temporary remove the IP on ISP A so that the interface still stays up but R1 won’t be able to ping any longer. We will run a debug of track to see what happens.

R1 can’t ping ISP A any longer so it stops announcing the deafult route as we can see on R2.

So now we have a more dynamic way of sending a conditional default. You can create even more exciting scenarios than this I am sure. If you want to lab it up just download the files from the beginning of this post.

Filtering RIP routes with an offset-list

March 18, 2011 1 comment

As you all know RIP is a distance vector routing protocol and that gives us a lot of options
when doing filtering. This time we will look at a feature that is not widely known, the
offset list. Assume that we have two routers, R1 and R2 and this is the task at hand.

  • R1 should filter all RIP routes coming from R2 with an even second octet
  • The access-list used may only contain one line
  • Do not use the distribute-list or distance command to accomplish this

So lets look at our tasks, how do we filter routes with an even second octet?
This might look a bit complicated but it’s easy when you’ve done it before. The routes we
are receiving from R2 are 30.0.0.0 to 30.3.0.0 and 31.0.0.0 to 31.3.0.0. Lets start
by focusing on the second octet. We will convert our even subnets to binary, we only care about the first and second octet.

30.0.0.0 – 00011110 00000000
30.2.0.0 – 00011110 00000010
31.0.0.0 – 00011111 00000000
31.2.0.0 – 00011111 00000010

See the pattern? If not look at the odd subnets below.

30.1.0.0 – 00011110 00000001
30.3.0.0 – 00011110 00000011
31.1.0.0 – 00011111 00000001
31.3.0.0 – 00011111 00000011

Do you see it now? Even subnets always end with a zero for the least significant bit.
Odd subnets always end with a one. This means that the final bit in the second octet is
interesting to us, the rest is don’t care. Now we need to convert this to a wildcard mask,
set all the bits we don’t care about to one and the one we do care about to zero.
Add them up, in binary it is 11111110 which equals to 254 in decimal.

Now we need to fill in the rest of the wildcard mask, remember that we were only allowed
to use one line in the access-list. How can we match both 30 and 31 in the first octet?
Look at the binary again, only the least significant bit in the first octet differs so we do
care about all the bits except for the least significant bit. Convert this to binary and we
have 00000001 which is 1 in decimal. So now we have the wildcard 1.254.255.255 since
we don’t care about the third and fourth octet.

As stated in the tasks we need to filter even routes, how can this be accomplished
in an access-list? Either we can deny odd routes, that would filter even routes
but since there is an implicit deny we would need a permit statement for the even
routes. That would break the one line requirement. So we need to permit the even
routes in the access-list and the implicit deny will solve the rest.

access-list 1 permit 30.0.0.0 1.254.255.255

Using a distribute-list would be the most common and easiest solution but
we are not allowed to do that. By using the distance command we could filter
routes by setting the administrative distance to something not believable like 255
but we are not allowed to do that either.

That only leaves us with the offset-list. The offset-list lets us manipulate routing
metrics, we are allowed to do this since it is distance vector and that is the reason
why distance vector is often called “routing by rumor”. In a link-state protocol we
would not be allowed to do this as we would need to send the original LSA.
So we can manipulate the metric, how can this help us? Remember that in RIP
we have the hop-count as metric and only metrics of up to 15 are valid, 16 and up
are regarded as invalid routes. So we then need to set our routes to have an offset of 16.

router rip
offset-list 1 in 16 Vlan783

So we have defined our offset-list, access-list 1 is used, the direction is
inbound, we want to filter routes we are receiving. We need to define the
offset, which is 16. We also need to define on what interface the RIP routes
are received. This is the layer three interface and may or may not be the
physical interface.

By now hopefully you have picked up a new way of filtering routes and can add it to your toolbelt.

Categories: CCIE, RIP, Routing Tags: , , , ,