Administrative distances are indeed assigned by the vendor, and the values you see in the lesson are values assigned by Cisco. This does make sense when you see that EIGRP is given a better AD that OSPF. Although they are assigned by vendors, they are not entirely based on preference of the proprietary over the open architecture protocols. The default ADs are specifically chosen to ensure an optimum functionality under the most common circumstances.
Other vendors use AD values as well, but the interoperation of routers from various vendors are not that much of an issue because the AD is local to the router and is not something that is shared in any routing updates. However, it is of utmost importance that the ADs on routers within the same routing domain be the same. Otherwise, routing loops and black holes may arise.
Like in many disciplines, professionals become attached to specific protocols and methodologies because they have experience with them. I too am not immune to this. . To be fair, both EIGRP and OSPF are exceptional protocols and I have seen both be implemented successfully in many large networks. The truth is that each has its strengths and weaknesses for specific situations. I stated that EIGRP was better than OSPF, at least as far as convergence goes, because it has the feasible successor built in which provides exceptional convergence speed. OSPF on the other hand is better in scalability due to the fact that you can separate a network into somewhat autonomous areas. So it really depends on what your requirements are.
Now Cisco has chosen to place EIGRP above OSPF, which is a design choice, which may indeed be influenced by the fact that it is proprietary, but it is based on valid technological research as well.
(But to go as far as to say that EIGRP is obsolete, in my opinion, simply shows contempt rather than rational thought.)
Just for argumentās sake, EIGRP has now been opened to be freely used by other vendors as well, and vendors such as HP for example, are indeed using it in their equipment. It is described in the IETF RFC 7868.
I have a question, which raised during lab practice.
I have two routers and there are multiple Loopback interfaces for testing. I implemented different routing protocols, specifically, OSPF, RIPv2, and Static routes.
I made the OSPF and RIP have the same Administrative Distance (90) for the same networks.
However, the routing tables of both routers only show OSPF routes not RIP or both (Since they have the same administrative distance). I also change the AD of the static route to have (90), which is the same advertised route in OSPF with the same AD (90). Nevertheless, the router table only shows the static route only not both static and OSPF.
My question is, since the administrative distance of OSPF, RIP, and Static is the same, then why the routing table is not showing both routes? Is there another factor that makes a router prefer one route over another?
The only answer that came to my mind is that when the AD is same, then the router would look which one has close IP match based on the Subnet mask. But Iām not sure about this.
I havenāt been able to find any Cisco documentation that describes what happens when you configure the AD to be the same for multiple routing protocols. However, I too did some experimentation in the lab and I found the following:
If eBGP, EIGRP, RIP, OSPF, and a static route are all advertising the same prefix with the same AD, then they are installed in the routing table in the same order as their original AD values. in other words, they are installed in the following order:
static
eBGP
EIGRP
OSPF
RIP
Load balancing will never take place between two paths that are advertised from different sources, even if the AD is the same. For example, a route to 192.168.55.0/24 learned from both EIGRP and OSFP with the same AD will never have two entries in the routing table, and will never be load balanced. EIGRP will take precedence over OSPF, and thus only the EIGRP learned route is installed.
The above are true only for identical prefixes. A prefix is the same only if the network address and the subnet mask are the same. For example, if EIGRP advertises a route to 172.16.0.0/23, and RIP advertises a route to 172.16.0.0/24, both routes will appear in the routing table, regardless of the AD. This is because they are considered different prefixes.
Great to hear that this was helpful. What kind of example did you have in mind? Can you give me some more information so that we can direct you to an example that may have already been implemented?
R1#show 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
C 192.168.12.0/24 is directly connected, FastEthernet0/0
C 192.168.13.0/24 is directly connected, FastEthernet0/1
R 2.0.0.0/8 [120/1] via 192.168.12.2, 00:00:09, FastEthernet0/0
3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
S 3.3.3.0/24 [1/0] via 192.168.13.3
R 3.0.0.0/8 [120/1] via 192.168.13.3, 00:00:06, FastEthernet0/1
The output is different from the output of the example . I donāt know why.
There are a couple of differences between your output and the output of the lesson. In the lesson, the IOS version that is being used is 15.X while the version that you are using seems to be 12.X. I know this because in IOS versions of 15.0 and later, a directly connected network will produce two entries in the routing table, one marked āLā and another marked āCā. Older version show only the āCā like in your output. The āLā appears as a host address (/32) referring to the interface itself. This doesnāt really change anything as far as configurations go, itās just one more entry that appears.
Secondly, the order that the routes appear in are slightly different. Some IOS versions put them in order of type or in ascending order of the actual address.
The above two donāt change the actual functionality, they just change the way that the routing table is displayed.
Finally, in your output, you have two routes advertised by RIP. These routes are:
2.0.0.0/8 and 3.0.0.0/8. It seems that you have advertised the classful routes (which gives a /8 prefix) rather than the /24 route which is indicated in the lesson. In order to get similar results to the lesson you must:
Make sure you have assigned the correct subnet mask to the loopback interfaces on R2 and R3.
Make sure that you have enabled RIP version 2 on all routers, which supports classless IP address scheme.
Once you do that you should get the /24 in your RIP learned routes. For more information about this, take a look at the following lesson:
Thank you for your explanation. Very clear.
I rebuild the lab in CML with VIOS-ADVENTERPRISEK9-M), Version 15.9(3)M6.
And used as advised, RIP version 2 and no auto summary. The output is much better now then the older version 12.9 in GNS3 and in line with the results in the lesson of Rene. See screenshot.
Random question but it has been messing with my brain. If I have a DMVPN topology dual hub dual cloud with three spokes. Both hubs have OSPF P2P link between them. On the DMVPN I have iBGP running sharing routes between the hubs and spokes. On the hubs I have OSPF running for internal routes. So, for routes going to spokes iBGP, internal routes OSPFā¦ if I redistribute iBGP routes into OSPF will I now have issues with routes to spokes since OSPF will be the preferred route over iBGP on the hubs?
Another way to ask this is if you have routes being learned by some route protocol with a high AD then redistribute into a route protocol that has a small AD does it screw up the whole route table on that device.
Yes, this is a concern, especially within a DMVPN topology like the one you described. If we take it step by step, this is what may occur on your topology when you redistribute iBGP routes into OSPF on your hubs:
Hub1 learns spoke routes via iBGP (Administrative Distance = 200)
Hub1 redistributes these routes into OSPF as external routes
Hub2 receives these routes via the OSPF P2P link between hubs (AD = 110)
Hub2 also learns the same routes directly from spokes via iBGP (AD = 200)
Hub2 prefers the OSPF route (110 < 200) and installs it in the routing table
The same happens in reverse when Hub2 redistributes
Result: Traffic destined for spokes will be sent across the inter-hub link first (creating a āhair-pinningā or ātromboningā effect) instead of going directly down the DMVPN tunnel. This defeats the purpose of dual active hubs and creates suboptimal routing or even potential routing loops.
There are several solutions to this problem, and Iāll mention them briefly here:
Adjust the OSPF external administrative distance using the distance ospf external command which can set the AD of external OSPF routes that are redistributed into OSPF. Make their AD higher than that of iBGP (200) to ensure the iBGP routes are preferred and installed in the routing table.
You can use route tagging and filtering when redistributing BGP routes into OSPF, choosing to filter out those routes you donāt want to be learned via OSPF.
Donāt redistribute. Let BGP carry spoke routes between hubs, and let OSPF carry only internal routes.
Any of these can be used to avoid suboptimal routing, but which you choose is up to you.
Thank you so much for this response. That all makes sense, and I thought that is what would happen but wanted to verify with someone such as yourself. Always nice to get that confirmation.
. To be fair, both EIGRP and OSPF are exceptional protocols and I have seen both be implemented successfully in many large networks. The truth is that each has its strengths and weaknesses for specific situations. I stated that EIGRP was better than OSPF, at least as far as convergence goes, because it has the feasible successor built in which provides exceptional convergence speed. OSPF on the other hand is better in scalability due to the fact that you can separate a network into somewhat autonomous areas. So it really depends on what your requirements are.
.
