So, we want to make sure any tags that we sent out via EIGRP do not come back round in via R3 via OSPF
We already have a route-map (EIGRP-TO-OSPF) in place that is marking the routes and setting the metrics
R2(config)#route-map EIGRP-TO-OSPF deny 5
R2(config-route-map)#match tag 40
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
Lets to do the same on R3
route-map EIGRP-TO-OSPF deny 5
match tag 40
route-map OSPF-TO-EIGRP deny 5
match tag 10 20 30
STEP 5.
R3 has the preferred route to reach the 10.1.0.0/24 network. Ensure routers prefer this path over the path from R2.
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.0
Routing entry for 10.1.0.0/24
Known via "eigrp 100", distance 170, metric 6430720
Tag 40, type external
Redistributing via eigrp 100
Last update from 10.1.24.2 on FastEthernet0/0, 00:11:24 ago
Routing Descriptor Blocks:
* 10.1.24.2, from 10.1.24.2, 00:11:24 ago, via FastEthernet0/0
Route metric is 6430720, traffic share count is 1
Total delay is 1200 microseconds, minimum bandwidth is 400 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
RIGHT, so we have to make the route from R3 look "better" than the route from R2
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 ... so even if we were to play with metrics, it still would NOT matter,
One 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)
Lets try it;
currently R2's route for 10.1.0.0 is
R2#show ip route | i 10.1.0.0
O 10.1.0.0/24 [110/782] via 10.1.12.1, 00:52:01, Serial0/0
R2(config)#router eigrp 100
R2(config-router)#distance eigrp ?
<1-255> Distance for internal routes
R2(config-router)#distance eigrp 90 ? <-- dont need to change internal, keep at default
<1-255> Distance for external routes
R2(config-router)#distance eigrp 90 105
00:55:49: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 10.1.24.4 (Ethernet0/0) is down: route configuration changed
00:55:49: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 10.1.23.3 (Serial0/1) is down: route configuration changed
00:55:51: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 10.1.23.3 (Serial0/1) is up: new adjacency
00:55:53: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 10.1.24.4 (Ethernet0/0) is up: new adjacency
SO boys n gals, whadda reckon ......
R2#show ip route | i 10.1.0.0
D EX 10.1.0.0/24 [105/6917120] via 10.1.23.3, 00:02:12, Serial0/1
YEAH BOI!!! check that out! R2 is now favouring the route via R3 with the new Admin Distance of 105, which beats the OSPF AD!
lets check the route on R4 again:
R4#tracerou 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.23.3 8 msec 4 msec 4 msec <---- THEREs our bud, R3!!!
3 10.1.13.1 4 msec 4 msec *
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!
Gotta be careful with advanced route redistribution
