10-14-2013 11:56 PM - edited 03-04-2019 09:19 PM
Hi Friends,
I made the following topology:
-----------------R3------------------------
| |
| |
R5--------R4 R1
| |
| |
-----------------------R2----------------------
R3-R1-R2-R4 running eigrp
R3-R4-R5 running ospf
EIGRP and OSPF is mutually redistributed at R3.
At R2, EIGRP is sending summary address 192.168.0.0/21 towards R4
At R3, OSPF is aggregating EIGRP learned prefixes to 192.168.0.0/21 towards R4
At R4, distance command is used to alter the OSPF AD to 90 for routes learned via R3.
Now, if we go by routing rules, the lowest AD get installed in routing table. However the scenario which I create prefix 192.168.0.0/21 would be learned via EIGRP at R4 with AD of 90 and also via OSPF at R4 with altered AD of 90; So I assume that both of them should be installed in the routing table ( assuming that metric of both are same, which I ensured), but only EIGRP was getting installed.
To further check I was correctly setting the OSPF AD to 90, I shut down the EIGRP running interface and as expected, prefix learned via OSPF got installed in routing table with AD of 90.
So, question boils down to how is routing table build when AD and metric is same ??
Tried searching Cisco DOC, but didn't found anything usefull.
Regards,
Smitesh
10-15-2013 12:20 AM
Hi,
As you observed the route learned by the routing protocol with the lowest default AD will get installed.
Regards
Alain
Don't forget to rate helpful posts.
10-15-2013 12:25 AM
Hi Cadet,
But problem is I changed the AD of OSPF to 90 using distance command
So now prefix 192.168.0.0/21 has got AD of 90, whether learned by EIGRP or OSPF; also metric is same.
So, if AD is equal, then why EIGRP learned route is only getting installed in routing table.
Regards,
Smitesh
10-15-2013 12:33 AM
Hi,
because default AD for EIGRP is 90 and default AD for OSPF is 110 so it will install the route learned from the protocol with lowest default AD which is EIGRP.
Regards
Alain
Don't forget to rate helpful posts.
10-15-2013 02:03 AM
Hi Alain,
because default AD for EIGRP is 90 and default AD for OSPF is 110 so it will install the route learned from the protocol with lowest default AD which is EIGRP.
I am somehow doubting this. I am not sure if there is any document that would confirm this assumption - do you know of any?
Best regards,
Peter
10-15-2013 02:12 AM
Hi Peter and Alain,
I change the EIGRP to RIP and applied the same concept there and it still seems that routing table is giving preference to protocol, instead of AD.
Just to make sure on the same, i changed AD of both protocol to 50 and guess what OSPF learned route got installed.
I guess it Routing table when faced with same AD gives preference to protocol whose default AD is lower; though not able to find any official doc on this.
Regards,
Smitesh
10-15-2013 02:28 AM
Smitesh,
I do not have an option of running a lab on my own but can you do two experiments for me?
Best regards,
Peter
10-15-2013 02:46 AM
Hi Peter,
R4#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.32.0.0/16 is variably subnetted, 5 subnets, 2 masks
C 172.32.8.0/24 is directly connected, Loopback0
C 172.32.9.0/24 is directly connected, Loopback1
O 172.32.10.0/24 [50/2] via 10.10.45.5, 00:28:49, FastEthernet1/0
O 172.32.11.0/24 [50/2] via 10.10.45.5, 00:28:49, FastEthernet1/0
O E2 172.32.0.0/21 [50/20] via 10.10.14.1, 00:27:50, FastEthernet0/0
10.0.0.0/24 is subnetted, 5 subnets
O E2 10.10.12.0 [50/20] via 10.10.14.1, 00:27:50, FastEthernet0/0
C 10.10.14.0 is directly connected, FastEthernet0/0
O E2 10.10.23.0 [50/20] via 10.10.14.1, 00:27:51, FastEthernet0/0
C 10.10.34.0 is directly connected, FastEthernet0/1
C 10.10.45.0 is directly connected, FastEthernet1/0
-----------------------------------------------------
shutting down OSPF interface
R4(config-if)#int fa0/0
R4(config-if)#shut
R4(config-if)#
*Mar 1 01:13:00.983: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: True
*Mar 1 01:13:00.987: %OSPF-5-ADJCHG: Process 1, Nbr 172.32.2.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar 1 01:13:00.991: RT: interface FastEthernet0/0 removed from routing table
*Mar 1 01:13:00.995: RT: del 10.10.14.0/24 via 0.0.0.0, connected metric [0/0]
*Mar 1 01:13:00.995: RT: delete subnet route to 10.10.14.0/24
*Mar 1 01:13:00.995: RT: NET-RED 10.10.14.0/24
*Mar 1 01:13:00.999: RT: Pruning routes for FastEthernet0/0 (3)
*Mar 1 01:13:01.039: RT: delete route to 172.32.0.0 via 10.10.14.1, FastEthernet0/0
*Mar 1 01:13:01.039: RT: no routes to 172.32.0.0, flushing
*Mar 1 01:13:01.039: RT: NET-RED 172.32.0.0/21
*Mar 1 01:13:01.043: RT: delete route to 10.10.12.0 via 10.10.14.1, FastEthernet0/0
*Mar 1 01:13:01.043: RT: no routes to 10.10.12.0, flushing
*Mar 1 01:13:01.047: RT: NET-RED 10.10.12.0/24
*Mar 1 01:13:01.047: RT: delete route to 10.10.23.0 via 10.10.14.1, FastEthernet0/0
*Mar 1 01:13:01.047: RT: no routes to 10.10.23.0, flushing
*Mar 1 01:13:01.047: RT: NET-RED 10.10.23.0/24
*Mar 1 01:13:02.971: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 1 01:13:02.975: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: False
*Mar 1 01:13:03.971: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
*Mar 1 01:13:03.975: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: False
*Mar 1 01:13:05.043: RT: add 10.10.14.0/24 via 10.10.34.3, rip metric [120/3]
*Mar 1 01:13:05.043: RT: NET-RED 10.10.14.0/24
*Mar 1 01:13:18.751: RT: add 10.10.12.0/24 via 10.10.34.3, rip metric [120/2]
*Mar 1 01:13:18.755: RT: NET-RED 10.10.12.0/24
*Mar 1 01:13:18.755: RT: add 10.10.23.0/24 via 10.10.34.3, rip metric [120/1]
*Mar 1 01:13:18.759: RT: NET-RED 10.10.23.0/24
*Mar 1 01:13:18.759: RT: network 172.32.0.0 is now variably masked
*Mar 1 01:13:18.763: RT: add 172.32.0.0/21 via 10.10.34.3, rip metric [120/15]
*Mar 1 01:13:18.763: RT: NET-RED 172.32.0.0/21
R4(config-if)#do sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.32.0.0/16 is variably subnetted, 5 subnets, 2 masks
C 172.32.8.0/24 is directly connected, Loopback0
C 172.32.9.0/24 is directly connected, Loopback1
O 172.32.10.0/24 [50/2] via 10.10.45.5, 00:00:32, FastEthernet1/0
O 172.32.11.0/24 [50/2] via 10.10.45.5, 00:00:32, FastEthernet1/0
R 172.32.0.0/21 [120/15] via 10.10.34.3, 00:00:17, FastEthernet0/1 <----- I have changed hop count to 15 just to rule out any consideration of metric if any
10.0.0.0/24 is subnetted, 5 subnets
R 10.10.12.0 [120/2] via 10.10.34.3, 00:00:17, FastEthernet0/1
R 10.10.14.0 [120/3] via 10.10.34.3, 00:00:08, FastEthernet0/1
R 10.10.23.0 [120/1] via 10.10.34.3, 00:00:18, FastEthernet0/1
C 10.10.34.0 is directly connected, FastEthernet0/1
C 10.10.45.0 is directly connected, FastEthernet1/0
-------------------------------------------------------------------------------------------
No shut OSPF interface
R4(config-if)#no shut
R4(config-if)#
*Mar 1 01:14:08.291: RT: is_up: FastEthernet0/0 1 state: 4 sub state: 1 line: 1 has_route: False
*Mar 1 01:14:08.291: RT: closer admin distance for 10.10.14.0, flushing 1 routes
*Mar 1 01:14:08.291: RT: NET-RED 10.10.14.0/24
*Mar 1 01:14:08.295: RT: add 10.10.14.0/24 via 0.0.0.0, connected metric [0/0]
*Mar 1 01:14:08.295: RT: NET-RED 10.10.14.0/24
*Mar 1 01:14:08.303: RT: interface FastEthernet0/0 added to routing table
*Mar 1 01:14:10.267: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar 1 01:14:10.271: RT: is_up: FastEthernet0/0 1 state: 4 sub state: 1 line: 1 has_route: True
*Mar 1 01:14:11.267: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
*Mar 1 01:14:11.271: RT: is_up: FastEthernet0/0 1 state: 4 sub state: 1 line: 1 has_route: True
*Mar 1 01:14:13.527: %OSPF-5-ADJCHG: Process 1, Nbr 172.32.2.1 on FastEthernet0/0 from LOADING to FULL, Loading Done
*Mar 1 01:14:23.811: RT: closer admin distance for 10.10.12.0, flushing 1 routes
*Mar 1 01:14:23.811: RT: NET-RED 10.10.12.0/24
*Mar 1 01:14:23.815: RT: add 10.10.12.0/24 via 10.10.14.1, ospf metric [50/20]
*Mar 1 01:14:23.815: RT: NET-RED 10.10.12.0/24
*Mar 1 01:14:23.819: RT: closer admin distance for 10.10.23.0, flushing 1 routes
*Mar 1 01:14:23.819: RT: NET-RED 10.10.23.0/24
*Mar 1 01:14:23.823: RT: add 10.10.23.0/24 via 10.10.14.1, ospf metric [50/20]
*Mar 1 01:14:23.823: RT: NET-RED 10.10.23.0/24
*Mar 1 01:14:23.823: RT: closer admin distance for 172.32.0.0, flushing 1 routes
*Mar 1 01:14:23.827: RT: NET-RED 172.32.0.0/21
*Mar 1 01:14:23.827: RT: add 172.32.0.0/21 via 10.10.14.1, ospf metric [50/20]
*Mar 1 01:14:23.831: RT: NET-RED 172.32.0.0/21
-----------------------------------------------------------------------------------------------------------------------------
Hope it helps.
I also tried changing the order of route been learned, but it didn't mattered.
PS: I'm trying this on Dynamips and not on physical routers.
Regards,
Smitesh
10-15-2013 02:54 AM
Hi Peter,
The only doc stating this that i've found is for the ASA not the IOS devices:
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/route_overview.html#wp1097490
You can change the administrative distances for routes discovered by or redistributed into a routing protocol. If two routes from two different routing protocols have the same administrative distance, then the route with the lower
default
administrative distance is entered into the routing table. In the case of EIGRP and OSPF routes, if the EIGRP route and the OSPF route have the same administrative distance, then the EIGRP route is chosen by default.
Regards
Alain
Don't forget to rate helpful posts.
10-15-2013 02:57 AM
Hi,
IMHO, it has no sense to configure two routing protocols with the same AD.
You will never get both OSPF and EIGRP routes to the RIB at the same time.
As those are different routing protocols, so the router will never compare their metrics.
This is what Alex Zinin is writing in his famous Cisco IP Routing: Packet.Forwarding and Intra-domain Routing Protocols book:
"When a route is passed to the RT process, the router uses the following logic.
1. Check whether the routing table already has a route to the same network.
2. If no route is found, install the new route.
3. If an existing route is found, compare the AD and metric values of the old and new routes as follows.
a. If the AD of the new route is different from the AD of the route in the table, the route with the lower AD value is preferred. If the new route is chosen, all paths in the old route are removed, the new path is installed, and the associated AD and metric values of the route are changed accordingly. Otherwise—the already installed route has a better AD value—the new route is not installed, but the router saves information about the protocol that submitted the new route for installation in the prefix descriptor and sends a query to the protocol when a backup route is needed.
b. If the AD values of the routes are equal and both routes were submitted by the same process, the new route is processed according to the rules of distance-vector protocols (see Chapter 8).
c. If the AD values are equal but the routes are from different sources, the behavior depends on whether the routes are submitted by processes of the same type. If they are, the metrics of the routes are compared as if the routes were from the same protocol. If metrics are the same, the route from the process with the lower process number wins. If the routes are from different sources, the new route is ignored. (Note that this check is implemented for EIGRP routes only. All other routes are treated as from different protocols, so the old route is left in the routing table.)"
So I guess Peter is correct and the first route received should stay in the routing table when you configure two routing protocols with the same AD.
Best regards,
Milan
10-15-2013 03:30 AM
Hi Milan,
That was very good insight.
However it seems that it is not been followed.
My OP was taking the consideration of EIGRP and OSPF.
Later I replaced EIGRP with RIP.
So I assume both RIP and OSPF are of different proccess type. Now considering that OSPF interface is shut, routing table ends-up with RIP learned route. Now when interface is brought UP back, RIP been still the oldest learn route should be still kept in the routing table; however it is replaced by OSPF.
Haviing said this, I also tried deleting the OSPF process, then reloading all the routers. Once the topology was converged; then I reconfigured OSPF and again OSPF learned route ended-up in the routing table.
Regards,
Smitesh
10-15-2013 11:27 PM
Friends,
Any consensus to this ?
Though my experiments ( using all the protocols) resulted more on what Alain said about taking default AD of the protocol.
Regards,
Smitesh
10-15-2013 11:51 PM
Smitesh,
The experiments would corroborate what Alain suggested but I would like to perform a few more tests. Will report back in a day or so.
Best regards,
Peter
10-16-2013 10:43 PM
Peter,
Thanks for your personal interest on this issue.
Will wait your experiments...
Regards,
Smitesh
10-22-2013 01:24 AM
Just to keep thread live...
Regards,
Smitesh
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: