What will the administrative distance be of a EIGRP route redistributed into OSPF (assuming default metrics)
How bout the reverse.
I have a network design with remote sites dual homed to the head-end. One side runs OSPF (sprint IPVPN). The other side is point-to-point running EIGRP. The OSPF network terminates on a 3640 at the head-end. The Point-to-point terminates on a 7200 at the head end. Remote routers will be running both EIGRP and OSPF (no redistribution). The 3640 will be running both EIGRP and OSPF with redistribution both ways. The 7200 will only roun EIGRP. I want to make sure that the point-to-point network is always prefered over the Sprint network unless a point-to-point link fails.Won't the administrative distance of EIGRP 90 insure this?
It all depends on where the routes are coming from in the first place. If they are originally EIGRP internals, then the amin distance will be 90, and the EIGRP internals will be preferred over the OSPF routes on all the routers you've described. If they are EIGRP externals (it sounds like they would be from your description?), then the OSPF routes will be preferred.
You could set the OSPF admin distance to something higher than 170, say 180, to make the EIGRP routes preferred all the time.
I guess I'll have to build it out in our lab to confirm. I believe that a static route (or any external route) redistributed into EIGRP will have a distance of 170. I don't understand why an EGRP route (distance 90) redistributed into OSPF will be lower than the default OSPF distance of 110 for those routes.
If the routes are redistributed into EIGRP, they will have an administrative distance of 170, not 90, so they won't be lower than an OSPF route at 110. If the routes are native EIGRP routes, coming in from a network statement, then they will have an administrative distance of 90, so they will be preferred over OSPF, at 110.
Are the routes originally redistributed into EIGRP, or are they originally injected using a network statement?
All EIGRP routes originating from the 3640 and the 7200 are internal EIGRP (90) routes via network statements (except the default which is a redistributed static into EIGRP).
The question I still need to figure out is what the OSPF administrative distance will be for EIGRP routes that are redistributed into OSPF.
The remote router will be getting native EIGRP updates from then 7200 (via the T1 circuit) and OSPF routes from the sprint network (EIGRP routes redistributed into OSPF from the head-end 3640). I would anticipate that the OSPF routes will be something higher than the default 110. Therfore the EIGRP routes will always be preferred.
EIGRP routes redistributed into OSPF will have an administrative distance of 110, the same as all other OSPF routes. That's why I was commenting before that if you want EIGRP routes to always be preferred over OSPF routes, you'll need to change the administrative distance on OSPF for it's higher than 170, or change EIGRP externals to 105, so they are lower than OSPF routes.
Understood. And thanks for the insights. I did build this out and the results are as you explained. The only route that I'm going to have an issue with is the static default that I am redistributing into EIGRP. As you've said, it comes into the remote router via OSPF with 110 and EIGRP with 170. I tried to add a statement to my OSPF router (distance ospf external 190) to alter the default-route distance but this had no effect. I'll keep researching.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...