Archive

Archive for August, 2012

INE 10 day bootcamp – First 5 days done

August 25, 2012 10 comments

So we have the first 5 days completed now and it is time for some relaxing in the weekend and a bit of labbing as well.

So far it has been great. Brian Dennis is both a great teacher and a great guy as well. With Brian you don’t only get explained how things work, you get explained WHY they work that way. He as a lot of background and knowledge and the good thing is he will show you also how things should work in production. He’s absolutely one of the top guys out there and I would recommend anyone to attend the class.

Some people like to take a bootcamp early to get their journey started but I would not recommend that. You will be expected to know the basics so if you have never configured frame relay before then this bootcamp is not for you. I would recommend to take it in your final stages of preparation or in the middle, no earlier than that.

Brian has a nice way of explaining things and he drew some pictures that just says it all. What could take people 2 pages to explain he just explained with one picture. I’ll try to put some things online later to show you what I mean.

For the first 5 days we have gone through L2, frame relay, OSPF, BGP and MPLS. Class runs from 9 AM to about 19 – 20 PM so in the evening you will be very tired. You also get some labs to complete and you can do that in the evening or leave it for the weekend.

During the OSPF section we discussed some interesting things about convergence. Many people falsely believe that convergence is about hello timers which it really isn’t. By default SPF will wait 5 seconds before it is run when receiving a LSA. To trim convergence you need to trim SPF. If you are using non P2P links then yes then you will have to rely on hello timers to detect link failure but in that case you would rather run BFD if you had that option as well.

That is all for now. I will post sometime when I get back from London as well.

Categories: CCIE Tags: , , , ,

INE – 10 day bootcamp

August 17, 2012 13 comments

Hey guys,

On sunday I’m leaving for London. I’m attending INEs 10 day bootcamp. Hopefully this will be the next step in my studies. I hope to learn a lot and to meet a few new buddies as well. I’m going to meet up with Darren in the weekend so he can show me a bit of London.

If I learn anything cool I’ll try to keep you posted 🙂 The class is taught by Brian Dennis.

Categories: Announcement, CCIE Tags: , , ,

Route redistribution – Route-maps and tagging

August 16, 2012 2 comments

Earlier I have done some posts on route redistribution and on
route filtering in different protocols. I wanted to expand on this
by showing different ways we can tag and do filtering with route-maps
when doing route redistribution.

We start out with this topology where two different OSPF segments are
separated by an EIGRP segment.

R2 will redistribute between OSPF and EIGRP mutually. R1 is redistributing
its loopback so it will be an external OSPF route. R4 and R5 will mutually
redistribute between EIGRP and OSPF. One interesting aspect about EIGRP is
that in the EIGRP packet we can see which protocol that originated the
route from the beginning. Take a look at this output showing the R1 loopback
in the EIGRP domain.

R4#sh ip eigrp topo 10.10.1.0/24
IP-EIGRP (AS 100): Topology entry for 10.10.1.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560002816
  Routing Descriptor Blocks:
  10.10.24.2 (FastEthernet0/0), from 10.10.24.2, Send flag is 0x0
      Composite metric is (2560002816/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 110 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is 10.10.24.2
        AS number of route is 1
        External protocol is OSPF, external metric is 20
        Administrator tag is 0 (0x00000000)

We can see that it came from OSPF 1 and that the ASBR is 10.10.24.2.
We also see that it had a metric of 20 and no tag applied to it. Where
is this information carried? Take a look at this packet capture.

We can see that a lot of information is carried for external routes.
This gives us options when doing tagging and filtering.

We configure distribution on R2 and then look at our options for doing
tagging and filtering.

R2#sh run | s router
router eigrp 100
 redistribute ospf 1 metric 1 1 1 1 1

If we look at R4 we should have two external routes with AD 170 going towards
the OSPF domain.

R4#sh ip route eigrp | i EX
D EX    10.10.1.0 [170/2560002816] via 10.10.24.2, 00:07:22, FastEthernet0/0
D EX    10.10.12.0 [170/2560002816] via 10.10.24.2, 00:07:22, FastEthernet0/0

If we traceroute this traffic will go straight to R2.

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.24.2 32 msec 40 msec 28 msec
  2 10.10.12.1 60 msec *  64 msec

What if we want external routes to go through R5 instead? We can
match on the route-type and incoming interface to block R2 routes.
This is a pretty blunt tool but can be good for some scenarios.

R4(config)#route-map RM_DENY_EXT_FA0/0 deny 10
R4(config-route-map)#match route-type external
R4(config-route-map)#route-map RM_DENY_EXT_FA0/0 permit 100
R4(config-route-map)#router eigrp 100
R4(config-router)#distribute-list route-map RM_DENY_EXT_FA0/0 in fa0/0

So what we just did is filter all external routes coming in on Fa0/0.
Did we achieve the wanted result?

R4#sh ip route eigrp | i EX
D EX    10.10.1.0 [170/2560030976] via 10.10.45.5, 00:00:21, FastEthernet0/1
D EX    10.10.12.0 [170/2560030976] via 10.10.45.5, 00:00:21, FastEthernet0/1
R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.45.5 40 msec 36 msec 16 msec
  2 10.10.35.3 56 msec 40 msec 40 msec
  3 10.10.23.2 48 msec 28 msec 44 msec
  4 10.10.12.1 68 msec *  68 msec

Now all external routes will go through R5 instead.

Currently we are not doing redistribution on R4 and R5. What will
happen with the EIGRP external routes when we do redistribution?
First we remove the previous configuration and then we configure
redistribution.

R4(config)#router eigrp 100
R4(config-router)#no distribute-list route-map RM_DENY_EXT_FA0/0 in FastEthernet0/0
R4(config-router)#redistribute ospf 1 metric 1 1 1 1 1
R4(config-router)#router ospf 10
R4(config-router)#redistribute eigrp 100 sub
R5(config)#router eigrp 100
R5(config-router)#redistribute ospf 10 metric 1 1 1 1 1
R5(config-router)#router ospf 10
R5(config-router)#redistribute eigrp 100 sub

From R4 we now look at how it reaches 10.10.1.0/24.

R4#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "eigrp 100", distance 170, metric 2560002816, type external
  Redistributing via eigrp 100, ospf 10
  Advertised by ospf 10 subnets
  Last update from 10.10.45.5 on FastEthernet0/1, 00:00:52 ago
  Routing Descriptor Blocks:
    10.10.45.5, from 10.10.45.5, 00:00:52 ago, via FastEthernet0/1
      Route metric is 2560002816, traffic share count is 1
      Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1
  * 10.10.24.2, from 10.10.24.2, 00:00:52 ago, via FastEthernet0/0
      Route metric is 2560002816, traffic share count is 1
      Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1

Why does it have two entries for 10.10.1.0/24? Take a look in the
EIGRP topology table.

R4#sh ip eigrp topo 10.10.1.0/24
IP-EIGRP (AS 100): Topology entry for 10.10.1.0/24
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 2560002816
  Routing Descriptor Blocks:
  10.10.24.2 (FastEthernet0/0), from 10.10.24.2, Send flag is 0x0
      Composite metric is (2560002816/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 110 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is 10.10.24.2
        AS number of route is 1
        External protocol is OSPF, external metric is 20
        Administrator tag is 0 (0x00000000)
  10.10.45.5 (FastEthernet0/1), from 10.10.45.5, Send flag is 0x0
      Composite metric is (2560002816/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 110 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is 10.10.56.5
        AS number of route is 10
        External protocol is OSPF, external metric is 20
        Administrator tag is 0 (0x00000000)

We can see that one route is originating from OSPF 1, which is the true
source of the route and one is originating via OSPF 10. R5 is learning
this route via OSPF and then redistributing it into EIGRP and R4 is
learning that via EIGRP. Let us confirm that R5 sees this as an OSPF
route.

R5#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 1 1 1 1 1
  Last update from 10.10.56.6 on FastEthernet1/0, 00:08:12 ago
  Routing Descriptor Blocks:
  * 10.10.56.6, from 10.10.46.4, 00:08:12 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1

Which it does. What would happen if R5 was redistributing with a
better metric than R2 is doing? First we enable debugging of ip
routing on R4. Remember that in a stable topology where everything
is converged there should be no changes.

R4#debug ip routing
IP routing debugging is on

Then we change the metric on R5.

R5(config)#router eigrp 100
R5(config-router)#redistribute ospf 10 metric 100000 10 255 1 1500
RT: eigrp's 10.10.1.0/24 (via 10.10.45.5) metric changed from distance/metric [170/2560002816] to 

[170/30720]
RT: del 10.10.1.0/24 via 10.10.24.2, eigrp metric [170/2560002816]
RT: NET-RED 10.10.1.0/24
RT: NET-RED 10.10.1.0/24
RT: eigrp's 10.10.12.0/24 (via 10.10.45.5) metric changed from distance/metric [170/2560002816] to 

[170/30720]
RT: del 10.10.12.0/24 via 10.10.24.2, eigrp metric [170/2560002816]
RT: NET-RED 10.10.12.0/24
RT: NET-RED 10.10.12.0/24

We can see that the metric change but at least we have no flapping.

R4#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "eigrp 100", distance 170, metric 30720, type external
  Redistributing via eigrp 100, ospf 10
  Advertised by ospf 10 subnets
  Last update from 10.10.45.5 on FastEthernet0/1, 00:02:33 ago
  Routing Descriptor Blocks:
  * 10.10.45.5, from 10.10.45.5, 00:02:33 ago, via FastEthernet0/1
      Route metric is 30720, traffic share count is 1
      Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Do we still have reachability?

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.45.5 40 msec 16 msec 28 msec
  2 10.10.56.6 48 msec 32 msec 28 msec
  3 10.10.46.4 24 msec 44 msec 28 msec
  4 10.10.45.5 52 msec 48 msec 52 msec
  5 10.10.56.6 60 msec 60 msec 64 msec
  6 10.10.46.4 64 msec 60 msec 60 msec
  7 10.10.45.5 84 msec 108 msec 100 msec

Now we have a routing loop. What is happening here is that R4
is learning the route first via EIGRP and redistributes it into
OSPF. R5 learns this route via OSPF and then redistributes it
back into EIGRP and then R4 learns this route. They are now
both pointing at each other which means we have a loop.

What are our options of solving this? One way of solving it is
to increase the OSPF external AD on R5. That way R5 should not
redistribute it back to R4.

R5(config-router)#distance ospf external 180

R4#sh ip route 10.10.1.1
Routing entry for 10.10.1.0/24
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 10.10.46.6 on FastEthernet1/0, 00:00:38 ago
  Routing Descriptor Blocks:
  * 10.10.46.6, from 10.10.56.5, 00:00:38 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.46.6 56 msec 36 msec 16 msec
  2 10.10.56.5 48 msec 40 msec 40 msec
  3 10.10.35.3 52 msec 52 msec 52 msec
  4 10.10.23.2 112 msec 76 msec 72 msec
  5 10.10.12.1 96 msec *  120 msec

That solved the loop changing the distance is a bit of a hack unless
we incorporate the same policy on all devices. At least all devices
involved in redistribution should have the same policy.

R4(config)#router ospf 10
R4(config-router)#distance ospf external 180

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.24.2 28 msec 32 msec 12 msec
  2 10.10.12.1 44 msec *  60 msec

Yes, that solved it. A more elegant way is to use tagging and
filtering. We remove the previous distance commands.

What we can do now is to tag all external routes coming from OSPF 1
and then deny those routes from coming in if they have a tag set.
On R4 we tag routes with tag 444 and on R5 we will tag with 555.
First we confirm that the loop is back. You should note that with
redistribution you may see different results than I due to order of
operation. If that happens you could shutdown R5 link to R3 and
the loop should be back.

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.45.5 16 msec 44 msec 24 msec
  2 10.10.56.6 36 msec 28 msec 36 msec
  3 10.10.46.4 32 msec 40 msec 32 msec
  4 10.10.45.5 48 msec 56 msec 48 msec
  5 10.10.56.6 64 msec 56 msec 68 msec
  6 10.10.46.4 48 msec 64 msec 60 msec

It is still there. Time for some route-maps.

R4(config)#route-map RM_DENY_EXT_FROM_R5 deny 10
R4(config-route-map)#match tag 444
R4(config-route-map)#route-map RM_DENY_EXT_FROM_R5 permit 100
R4(config-route-map)#route-map RM_SET_TAG_444 permit 10
R4(config-route-map)#match source-protocol ospf 1
R4(config-route-map)#match route-type external
R4(config-route-map)#set tag 444
R4(config-route-map)#route-map RM_SET_TAG_444 permit 100
R4(config-route-map)#router eigrp 100
R4(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R5 in
R4(config-router)#router ospf 10
R4(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_444 sub

First we will confirm on R5 that we now see a tag.

R5#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
  Known via "ospf 10", distance 110, metric 20
  Tag 444, type extern 2, forward metric 2
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 100000 10 255 1 1500
  Last update from 10.10.56.6 on FastEthernet1/0, 00:00:48 ago
  Routing Descriptor Blocks:
  * 10.10.56.6, from 10.10.46.4, 00:00:48 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1
      Route tag 444

We now see the tag. There should be no tag on EIGRP internal routes.
We can confirm this on R6.

R6#sh ip route 10.10.24.0
Routing entry for 10.10.24.0/24
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 1
  Last update from 10.10.56.5 on FastEthernet0/1, 08:28:39 ago
  Routing Descriptor Blocks:
    10.10.56.5, from 10.10.56.5, 08:28:39 ago, via FastEthernet0/1
      Route metric is 20, traffic share count is 1
  * 10.10.46.4, from 10.10.46.4, 08:30:34 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

There should be no loop on R4 now. We will test with a traceroute.

R4#traceroute 10.10.1.1 num

Type escape sequence to abort.
Tracing the route to 10.10.1.1

  1 10.10.24.2 28 msec 44 msec 12 msec
  2 10.10.12.1 36 msec *  48 msec

The loop is gone. We should implement the same policy on R5 so if
R4 sends routes back to R5 it should stop it from learning them.

R5(config)#route-map RM_DENY_EXT_FROM_R4 deny 10
R5(config-route-map)#match tag 555
R5(config-route-map)#route-map RM_DENY_EXT_FROM_R4 permit 100
R5(config-route-map)#route-map RM_SET_TAG_555 permit 10
R5(config-route-map)#match source-protocol ospf 1
R5(config-route-map)#match route-type external
R5(config-route-map)#set tag 555
R5(config-route-map)#router eigrp 100
R5(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R4 in
R5(config-router)#router ospf 10
R5(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_555 sub

And that concludes this lesson. Route redistribution is always fun 🙂
You can look at some of my older posts for more ideas about filtering
routes.

BGP – local-as command

August 13, 2012 6 comments

The neighbor local-as command is a useful command when doing AS migration or merging.
Many people get confused by the optional arguments of this command. As we all
know the AS-path is a well known mandatory attribute of the BGP protocol.
Normally a router will prepend its local AS number onto the BGP updates
and send them to the eBGP neighbors. We start out with this configuration.

R1#sh run | s router bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.0.0.2 remote-as 200
 no auto-summary
R2#sh run | s router bgp
router bgp 64512
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.0.0.1 remote-as 100
 no auto-summary

Obviously this will not work as R1 is expecting another AS in the BGP Open
message. So R2 has to pretend that it is coming from AS 200. First we add
another router R3 that will announce the 3.3.3.0/24 prefix to R2. This is
just to demonstrate the difference in AS-path in an easier way. We see
that R2 is receiving the prefix.

R2#sh bgp ipv4 uni
BGP table version is 2, local router ID is 10.0.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 3.3.3.0/24       20.0.0.3                 0             0 300 i

Now we will use the local-as command on R2 to fool R1 that it is coming
from AS 200.

R2(config)#router bgp 64512
R2(config-router)#nei 10.0.0.1 local-as 200

The adjacency is now up.

%BGP-5-ADJCHANGE: neighbor 10.0.0.1 Up

What does the AS-path look like over at R1?

R1#sh bgp ipv4 uni
BGP table version is 2, local router ID is 10.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 3.3.3.0/24       10.0.0.2                               0 200 64512 300 i

AS 300 originated the route and then we see that both AS numbers from R2 have
been prepended. The options we have now is to use no-prepend and replace-as.
We look at no-prepend first.

To understand how no-prepend works we need to announce a prefix from R1.
The no-prepend option applies to incoming updates and not outgoing which
is a common source of confusion. We announce 1.1.1.0/24 from R1 and look at
it without the no-prepend option.

R2#sh bgp ipv4 uni
BGP table version is 3, local router ID is 10.0.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.0.0.1                 0             0 200 100 i

We see that our local-as AS number has been prepended to the update
coming from R1. Now we will add the no-prepend option.

R2(config-router)#nei 10.0.0.1 local-as 200 no-prepend

Now the AS-path looks like expected.

R2#sh bgp ipv4 uni
BGP table version is 5, local router ID is 10.0.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.0.0.1                 0             0 100 i
*> 3.3.3.0/24       20.0.0.3                 0             0 300 i

So what does the update look like over at R3?

R3#sh bgp ipv4 uni
BGP table version is 5, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       20.0.0.2                               0 64512 100 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

We can see that the BGP AS from the BGP process has been added to the outgoing
update. Without the no-prepend we would see AS 200 here as well. This might
not be wanted if we want to appear as one AS to someone but not reveal it to
other peers.

We also have the option of using replace-as. Let us try that.

R2(config-router)#nei 10.0.0.1 local-as 200 no-prepend replace-as
R1#sh bgp ipv4 uni
BGP table version is 11, local router ID is 10.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       10.0.0.2                               0 200 300 i

R1 now only sees the AS from the local-as command so they don’t know that
we are really AS 64512. The final option is to use dual-as which means that
the peer can initiate the BGP adjacency to either AS 64512 or 200, both will
work.

So the summary is that local-as is used to pretend to be another AS. By default
both the local-as AS and the BGP process AS will be prepended to outgoing updates
where the local-as AS will be added last in the AS-path. Incoming updates will have
the local-as AS prepended and then the BGP process AS prepended last when set to
other eBGP peers, this might not be desirable and can be configured with no-prepend.
If we use replace-as then the neighbor that we have configured local-as for will only
see the AS we are pretending to be and not the locally configured AS from the BGP
process.

Categories: Uncategorized

100k views – Thanks for visiting!

August 11, 2012 2 comments

This site just hit 100 000 visitors! I have been blogging for roughly 2 years now and I never expected the site to grow to the size that it has today. Unfortunately I don’t have the CCIE yet but I am working on that 😉 I want to thank everyone for visiting and I hope in the future we can create great things together. I have some interesting plans for the future but that will have to wait until I pass the lab 🙂

Categories: Announcement, CCIE Tags:

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.

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: , , , ,