without going into it too deeply ...
All I need to know is, if I create a GRE tunnel from my 4507 to the 6500k will the AD no longer been seen as 170 for external and be seen as AD 90.
I'm assuming it will but if anyone here can poke holes in my theary I would much appreciate it.
The AD of EIGRP-learned routes depends on whether they have been injected into EIGRP by the network command (in such case, the AD=90), or whether they have been redistributed into it using the redistribute command. In other words, it is the origin of a network that decides its AD, not the route through which it has been learned. Having a tunnel alone does not imply any change in the AD.
I am afraid you will need to go into more details although you did not originally plan to
yes I thought I might have to
170 is being seen over the MPLS line because of the redistribution from EIGRP to BGP. This is adversly affecting my ability to manipulate paths. I have a DMVPN which means that AD=90 is what's being seen there.
My plan to eliminate the AD=170 accross the MPLS line was my original proposal. Simply encapsulate the path and 90 should be seen as the AD
I see your point now. You have an MPLS VPN, is that correct?
The fact is that if you create a GRE tunnel between your two devices and run EIGRP over it then you will avoid the CE/PE redistributions with your MPLS VPN service provider and the networks will be learned as internal EIGRP routes with the AD=90. The downside of this solution, however, is that you are essentially nullifying the presence of the MPLS VPN because you are creating yet another VPN above it. Also, the traffic will be carried over the GRE tunnel, increasing the overhead by 24 bytes for each packet, resulting in possible MTU issues.
Have you considered redefining the AD of EIGRP-external routes to 90 or perhaps even lower? Would that help to solve your problem? The EIGRP distance can be redefined using the distance eigrp 90 90 command in the EIGRP configuration.
Yeah I can't do that because I have 2 MPLS links into another MPLS cloud and those routes need to be seen as 170.
I think I'm ok with losing a little bit off the top of the MPLS VPN.
Thanks for the heads up though.
If anything else comes to mind please let me know.
There is also an option of defining a custom administrative distance for individual networks selected by an ACL, not necessarily by their type (internal/external). The command is
distance distance gateway-address wildcard-mask [ access-list-number | access-list-name ]
So, this command essentially allows you to specify an administrative distance for all routes learned from a particular gateway specified by the gateway-address argument (this will be the next-hop of all these routes) and the wildcard mask (allows you to define a set of gateways for which the distance will be modified). The ACL can be further used to select only a subset of network learned by the specified gateways.
So I believe this could be used to actually set the AD in quite a fine-grained way. Assuming that your MPLS VPN's PE router address is 192.0.2.1 and all EIGRP-external networks you are currently seeking to lower the AD for are learned via this next hop, then the command would be:
distance 90 192.0.2.1 0.0.0.0
In addition, if you wanted to modify the AD only for selected networks learned by that next hop, the commands would be:
access-list 1 permit 172.16.0.0 0.0.255.255
access-list 1 permit 192.168.1.0 0.0.0.255
distance 90 192.0.2.1 0.0.0.0 1
This example would modify only the AD of networks 172.16.0.0/16 and 192.168.1.0/24 (and all their possible subnets) that are learned via 192.0.2.1.
See these two documents as well:
Would this work for you?
I agree with Peter here. Creating GRE tunnels across the MPLS network is not really the solution to use. Adjusting the distance is a much better solution.
Another alternative depending on how you are doing your routing is to have the specific routes sent across the MPLS cloud and have only summary routes over the DMVPN network. That way the more specific routes will be used unless the MPLS connection fails and then the more specific routes should be used. But this does depend on what routes you are currently exchanging across the 2 networks.
I am not an expert on this but would't it be easier to run two different EIGRP AS processes, one for MPLS and second for the dmvpn with AD higher than 170. I know two processes will mean more more cpu and memory at the routers but it does solve the issue.
So the solution I've decided to go with is to run a seperate EIGRP process and redistribute the routes I want back into my original AS.
Can someone through up a link to EIGRP redistribution into EIGRP ??
Thanks everyone for your input!!
If you have decided to run two different processes of EIGRP ( one for mpls & other for Gre routes with increased AD ), then you do not have to do any redistribution as the router will place routes belonging to MPLS EIGRP process in to its routing table becasue of lower AD.
Hope i make sense here
I'm not going to use a GRE tunnel accross the MPLS at all.
I'm going to run two EIGRP processes.
I'm going to redistribute ONLY the MPLS routes into my "base" process.
Can you explain your point please manishora111?
here's what i have seen at one of my client's :-
they have a mpls connection between their sites and also have DMVPN for failling over. They were running an eigrp process for MPLS and another process of EIGRP for DMVPN, they wanted to send all traffic using the MPLS links so they Increased the AD for the EIGRP process for dmvpn routes. so all site router were running two eigrp processes and were using mpls links as primary link but would fail over to DMvpn routes.
I was able only to find some terse comments here:
I do not believe there are going to be significant issues related to redistributing between two EIGRP processes (anyone having different experiences please share them with us!).