IPv4 Redistribution - Implementing Advanced Redistribution.......Cont
Okay, so what we need to ensure here, is routes in EIGRP land aren't being redistributed into OSPF (R4/R2 to R1) then redistributed again from OSPF from R3 back into EIGRP, and round and round we gooo ...
What we can do is modify one the route-maps we created earlier, as we are tagging OSPF routes that are being redistributed into EIGRP with tag 40, so we could setup a filter than blocks them coming back into R2 from EIGRP
Likewise we have EIGRP routes that are being redistibuted into OSPF with tags 10, 20 and 30, so again we can put a filter on R3 stopping them from coming back into EIGRP
It really helps drawing this stuff out first .... otherwise as Jeremy says "you can blow your own mind" lol!
So lets modify the route-map on R2, and deny the redistributed OSPF routes in EIGRP with tag 40 from leaving R2. (so deny anything trying to get into OSPF domain with tag 40)
R2(config)#route-map EIGRP-TO-OSPF deny 5
R2(config-route-map)#match tag 40
So iv sneaked in this sequence, so it is processed first and it will match EVERYTHING as we have not specified anything, and its matching tag 40;
R2#show run | s route-map EIGRP-TO-OSPF
route-map EIGRP-TO-OSPF deny 5
match tag 40
route-map EIGRP-TO-OSPF permit 10
match ip address METRIC100
set metric 100
set tag 10
route-map EIGRP-TO-OSPF permit 20
match ip address METRIC200
set metric 200
set tag 20
route-map EIGRP-TO-OSPF deny 25
match ip address DENY-10.4.4.0
route-map EIGRP-TO-OSPF permit 30
set metric 300
set tag 30
Now lets fix the otherway lol, these will be the redistributed OSPF routes in EIGRP
R2(config)#route-map OSPF-TO-EIGRP deny 5
R2(config-route-map)#match tag 10 20 30*
*(when aligned this acts as OR, when on new line, its AND)
So just to clarify;
route-map OSPF-TO-EIGRP, deny, sequence 5
Match clauses:
tag 10 20 30
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map OSPF-TO-EIGRP, permit, sequence 10
Match clauses:
Set clauses:
metric 400 20 255 1 1500
tag 40
Excellent, lets copy these new sequence numbers onto R3 and we are good to go
Lets check which route R4 currently favours for the 10.1.0.0/24;
R4#traceroute 10.1.0.1
Type escape sequence to abort.
Tracing the route to 10.1.0.1
1 10.1.24.2 4 msec 4 msec 4 msec
2 10.1.12.1 8 msec 4 msec *
As expected we go to R2, then R1
R4 knows about the route via EIGRP from R2:
R4#show ip route 10.1.0.1
Routing entry for 10.1.0.0/24
Known via "eigrp 100", distance 170, metric 6917120
Tag 40, type external
Redistributing via eigrp 100
Last update from 10.1.24.2 on Serial0/0, 00:19:38 ago
Routing Descriptor Blocks:
* 10.1.24.2, from 10.1.24.2, 00:19:38 ago, via Serial0/0
Route metric is 6917120, traffic share count is 1
Total delay is 20200 microseconds, minimum bandwidth is 400 Kbit
Reliability 255/255, minimum MTU 150 bytes
Loading 1/255, Hops 1
Route tag 40
RIGHT, so we have to make the route from R3 look "better" than the route that R2 is getting from R1 (over OSPF)
Looking at the routing tables, R3 has the route 10.1.0.0/24 with an
AD of 170
R2 has the route with an
AD of 110 (from R1);
R2# show ip route 10.1.0.1
Routing entry for 10.1.0.0/24
Known via "ospf 1", distance 110, metric 65, type intra area
... so even if we were to play with metrics, it still would NOT matter, it could have a metric of 1! would not matter as the AD for the route being learnt is still 170!
We could use policy routing to correct this or another approach is we could lower the Admin Distance of External routes of
EIGRP to say 105 (anything below the AD of OSPF which is 110)
Because if you look at the network map, R3 is advertising the route / redistributing that network 10.1.0.0/24 into EIGRP, but its not in the routing table as OSPF has a lower admin distance!
Remember R4's routing table above (scroll up)
R4#show ip route 10.1.0.1
Routing entry for 10.1.0.0/24
Known via "eigrp 100", distance 170, metric 6917120
R4#show ip route | i 10.1.0.0
D EX 10.1.0.0 [170/6917120] via 10.1.24.2, 00:45:36, Serial0/0
He knows about it, becuase of the redistribution and look at the AD! so if we make the AD lower than OSPFs default AD of 110, R2 will go to R3 to reach the 10.1.0.0/24 network
R2(config)#router eigrp 100
R2(config-router)#distance eigrp ?
<1-255> Distance for internal routes
R2(config-router)#distance eigrp 90 ?
<1-255> Distance for external routes
R2(config-router)#distance eigrp 90 101
*Mar 1 01:31:55.087: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.24.4 (Serial0/2) is down: route configuration changed
*Mar 1 01:31:55.119: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.23.3 (Serial0/0) is down: route configuration changed
R2(config-router)#
*Mar 1 01:31:56.243: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.23.3 (Serial0/0) is up: new adjacency
*Mar 1 01:31:57.231: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.24.4 (Serial0/2) is up: new adjacency
So.... whadda think...
R2# show ip route | i 10.1.0.0
D EX 10.1.0.0 [101/6917120] via 10.1.23.3, 00:01:20, Serial0/0
R2# show ip route 10.1.0.1
Routing entry for 10.1.0.0/24
Known via "eigrp 100", distance 101, metric 6917120
Tag 40, type external
Redistributing via eigrp 100, ospf 1
Last update from 10.1.23.3 on Serial0/0, 00:00:50 ago
Routing Descriptor Blocks:
* 10.1.23.3, from 10.1.23.3, 00:00:50 ago, via Serial0/0
Route metric is 6917120, traffic share count is 1
Total delay is 20200 microseconds, minimum bandwidth is 400 Kbit
Reliability 255/255, minimum MTU 150 bytes
Loading 1/255, Hops 1
Route tag 40
YEAH BOI!!! check that out! R2 is now favouring the route via R3 with the new Admin Distance of 101, which beats the OSPF AD!
lets check the route on R4 again:
R4#traceroute 10.1.0.1
Type escape sequence to abort.
Tracing the route to 10.1.0.1
1 10.1.24.2 48 msec 4 msec 0 msec
2 10.1.23.3 40 msec 12 msec 4 msec <---- THERE's our bud, R3!!!
3 10.1.13.1 12 msec * 36 msec
SWEEEEEEEET!
NOW! that is kool, very kool, BUT we do have to be careful with and
where we make these changes, becuase if say we also go and make this
change on R3, we would create ourself an infinite loop! as R3 would
prefer R2 over R1 to get to 10.1.0.0/24, the packet would go back over
to R2, same thing, it is going to prefer R3 ... and round and round we
go! ... although split horizon would prolly kick in, but the point is
still valid!
