Or at least let the routers on the network decide routing.
The issue we have is that we have redundant links at every location. Our primary link is MPLS and if the MPLS goes down the site will switch to VPN. It is done via static routes with metrics higher than that of EIGRP, and no ip redirects on the ethernet interface of the router. The initial switch works fine with ShoreTel.
The problem occurs when MPLS comes back up. All IP devices EXCEPT SHORETEL SWITCHES will go back to the proper routing. The ShoreTel switches hold their own routing tables, and since the VPN connection did not drop they believe this to be a good route. This then creates a loop where when users at HQ call the remote branch the call goes straight to VM. When users at the branch call HQ, the call is connected but neither party can hear each other.
If ShoreTel switches are responsible for IP routing, we should have some control over what routes they take or refreshing routing tables.
My preference is to let my routers do the routing.
The issue we have is that we have redundant links at every location. Our primary link is MPLS and if the MPLS goes down the site will switch to VPN. It is done via static routes with metrics higher than that of EIGRP, and no ip redirects on the ethernet interface of the router. The initial switch works fine with ShoreTel.
The problem occurs when MPLS comes back up. All IP devices EXCEPT SHORETEL SWITCHES will go back to the proper routing. The ShoreTel switches hold their own routing tables, and since the VPN connection did not drop they believe this to be a good route. This then creates a loop where when users at HQ call the remote branch the call goes straight to VM. When users at the branch call HQ, the call is connected but neither party can hear each other.
If ShoreTel switches are responsible for IP routing, we should have some control over what routes they take or refreshing routing tables.
My preference is to let my routers do the routing.
Comment