SECONDARY PROVIDER MPLS LINK NOT GETTING PRIORITIZED

[isaaco001]

Dear community,

I have a branch with two service provider links provider A and provider B connecting to HQ office. We normally prioritize one link over the other by introducing delay into the mpls configuration. we have other branches operating in this exact way. 

However, for this particular issue branch provider B remains always active no matter what kind of influence we do to attempt failover to provider A.

What could be causing provider A not to get preffered/prioritized. I have attached relevant configurations.

Thank you for your support as always.

Regards,

Isaac.

[loris.marcellini · Accepted solution]

The title is misleading as this seems to be a MPLS traffic-erng issue until one looks at the config. This is an eigrp issue you are having right? If not, please share the actual mpls traffic-eng config. Regardless.. please provide outputs indicated below.

Could you please indicate destination ip? Can you provide "show ip cef", "show mpls ldp bindings", "show bgp ipv4 / show ip bgp", "show run mpls traffic-eng", "show ip eigrp neighbors", "show ip eigrp topology", "show ip route eigrp", "show ip iegrp interfaces", "show ip route <your destination>"

Thanks, L.

[isaaco001]

Hi Ioris,

Thanks for your response, sorry about the title. I cant' tell wether I have an eigrp issue or not or what is causing the seconds link not to be preferred. Unfortunately, I don't have access to provider router for the mpls configs but I have attached all other show commands you have requested for. I hope it will give us some insight.

Regards,

Isaac.

[isaaco001]

 Loris,

This turned out to be an eigrp issue as you had alluded earlier. A subnet for tunnel 41 was missing in the overlay eigrp configuration. What made you have an inkling that its an eigrp issue and not other protocols?

Regards,

Isaac.

[loris.marcellini]

Hey, glad you got this sorted this. I guess the lack of MPLS level config under the tunnel interfaces and absence of mpls traffic-eng tuning around delay made me realise this was an EIGRP level issue and that MPLS was not in the picture at all in this case.