cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2924
Views
25
Helpful
18
Replies

Dilemma in understanding routing table building

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

18 Replies 18

cadet alain
VIP Alumni
VIP Alumni

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.

Don't forget to rate helpful posts.

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

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.

Don't forget to rate helpful posts.

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

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

Smitesh,

I do not have an option of running a lab on my own but can you do two experiments for me?

  • Have debug ip routing on when testing this, and post the output - perhaps some information will shed more light on this
  • Test whether the behavior is temporal or deterministic - does the order of routing protocols matter in time, i.e. if first and then second routing protocol try to add the route, would the same result be obtained if the order of protocols adding the route was reversed?

Best regards,

Peter

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

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.

Don't forget to rate helpful posts.

milan.kulik
Level 10
Level 10

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

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

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

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

Peter,

Thanks for your personal interest on this issue.

Will wait your experiments...

Regards,

Smitesh

Just to keep thread live...

Regards,

Smitesh

Getting Started

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: