Archive
INE 10 day bootcamp – First 5 days done
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.
INE – 10 day bootcamp
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.
Route redistribution – Route-maps and tagging
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
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.
100k views – Thanks for visiting!
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 🙂
RIP – request and response packets
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.
RIP MD5 authentication – mismatch in key ID
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.
OSPF – Use of forwarding address
In OSPF and other routing protocols we have something called forwarding address.
This can be used to route traffic in another direction than to the router that
originated the LSA. We start with the following topology.
It’s a basic OSPF setup where area 1 is a NSSA area. As you can see we have
two ABRs. Remember that in NSSA area, redistributed routes will be seen as N
internally but as E outside the area. To make this happen the ABR must translate
the type 7 LSA to type 5 LSA. If we have multiple ABRs, which one is responsible
for this task? The ABR with the highest RID will do the translation.
If we look at the LSA at R1, this is what it looks like.
R1#sh ip ospf data ex 10.10.4.0
OSPF Router with ID (10.10.13.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 1373
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.10.4.0 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0x7306
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.10.234.4
External Route Tag: 0
So R3 is the ABR doing the translation but the forward address is set to
10.10.234.4 which is the address of R4. This means that traffic doesn’t need
to pass through R3 to reach the R4 network. The router will lookup the
10.10.234.0/24 prefix and use the routing information to reach the
10.10.4.0 network. This is proven by a traceroute.
R1#traceroute 10.10.4.4 Type escape sequence to abort. Tracing the route to 10.10.4.4 1 10.10.12.2 44 msec 44 msec 20 msec 2 10.10.234.4 60 msec * 72 msec
What happens if the forwarding address network is not advertised? We will
do some filtering on R2.
R2(config-router)#area 1 range 10.10.234.0 255.255.255.0 not-advertise R3(config-router)#area 1 range 10.10.234.0 255.255.255.0 not-advertise R1#sh ip route 10.10.4.0 % Subnet not in table
There is no reachability for the network any longer? How can we resolve
this without removing the filtering?
We can tell R3 to suppress the FA in the LSA.
R3(config-router)#area 1 nssa translate type7 suppress-fa
The network is back and we have reachability but now traffic must pass
through R3 since the FA is not set.
R1#sh ip route 10.10.4.0
Routing entry for 10.10.4.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
Last update from 10.10.12.2 on FastEthernet0/0, 00:00:07 ago
Routing Descriptor Blocks:
* 10.10.12.2, from 3.3.3.3, 00:00:07 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1
R1#traceroute 10.10.4.4
Type escape sequence to abort.
Tracing the route to 10.10.4.4
1 10.10.12.2 52 msec 76 msec 48 msec
2 10.10.23.3 36 msec 48 msec 40 msec
3 10.10.234.4 72 msec * 72 msec
So by setting the FA we achieve more effecient routing. The reason to have
a forwarding address is to reduce the number of LSAs needed. If all ABRs were
doing type 7 to type 5 translation then there would be more LSAs than what is
optimal.
Lets take a look at the LSA now. Note that the FA will be set to 0.0.0.0.
R1#sh ip ospf data ex 10.10.4.0
OSPF Router with ID (10.10.13.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 212
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.10.4.0 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000003
Checksum: 0x6218
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
By default the FA is always set when using NSSA areas. Now we take a look
at another use case where we have another routing protocol involved and
redistribution is done between the routing domains.
This is our example topology. Very similar to before. We just changed from
OSPF to RIP on the lefthand side.
R3 will be the router doing mutual redistribution between RIP and OSPF.
We will see that the FA will be set to 0.0.0.0. We check the route on R1.
R1#sh ip route 10.10.4.0
Routing entry for 10.10.4.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
Last update from 10.10.12.2 on FastEthernet0/0, 00:01:07 ago
Routing Descriptor Blocks:
* 10.10.12.2, from 3.3.3.3, 00:01:07 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1
R1#sh ip ospf data ex 10.10.4.0
OSPF Router with ID (10.10.13.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 79
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.10.4.0 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0x6616
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
As expected the FA is set to 0.0.0.0. This means that traffic must traverse
R3. We confirm with a traceroute.
R1#traceroute 10.10.4.4 Type escape sequence to abort. Tracing the route to 10.10.4.4 1 10.10.12.2 64 msec 28 msec 24 msec 2 10.10.23.3 68 msec 40 msec 40 msec 3 10.10.234.4 96 msec * 76 msec
Now what happens if we enable OSPF on R3 interface towards R4?
R3(config-if)#ip ospf 1 area 0 R1#traceroute 10.10.4.4 Type escape sequence to abort. Tracing the route to 10.10.4.4 1 10.10.12.2 56 msec 32 msec 24 msec 2 10.10.234.4 60 msec * 72 msec
Traceroute is now takinig the shorter path. How did this happen? Take a
look at the LSA on R1.
R1#sh ip ospf data ex 10.10.4.0
OSPF Router with ID (10.10.13.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 59
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.10.4.0 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000002
Checksum: 0x7107
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.10.234.4
External Route Tag: 0
The FA has now been set. How did this happen? The FA will be set for
external routes if we meet the following conditions.
- OSPF is enabled on the ASBR’s next hop interface AND
- ASBR’s next hop interface is non-passive under OSPF AND
- ASBR’s next hop interface is not point-to-point AND
- ASBR’s next hop interface is not point-to-multipoint AND
- ASBR’s next hop interface address falls under the network range specified in the router ospf command.
So we have met all the conditions needed to set the FA. I hope that
you know have a better understanding of the forwarding address and
as usual always poste questions/feedback in the comments field.
Daniels networking blog 