Your configs look fine--if you're load sharing, then both links, and both BGP sessions, are working fine. When you have one link failed, do new sessions work? Do the routing tables look right with one link failed?
It could be that when you fail one link, a given session (HTML browasing session?) happened to be going across that link, and the browser may not like the lenght of time it's taking for the network to converge on the single link, or TCP may be resetting, or something along those lines. Could you describe what you mean when you say a browser gets "stuck"?
Have you coordinated this configuration with both ISPs to ensure that they're accepting all the prefixes you're announcing? If some sites work via ISP-B but most don't, this could indicate that ISP-B isn't announcing your prefixes to all of its neighbors for some reason.
I'd suggest initiating a failover to ISP-B and then running some tests to get a better idea of what is happening. Tracerouting to various destinations might be helpful to determine where the problems are occuring. (Are the traceroutes stopping at your router or somewhere in ISP-B's network?) Getting ISP-B involved in the troubleshooting may also be helpful. They'll be able to check their routers to see if your routes are propagating correctly.
what does the network look like when the link to your primary ISP is failed ? Do you still have the full BGP routing table, is the next hop address correct ? If you log onto an internet route-server does your prefix appear in the routing table ?
1. Your upstream ISP may have problem because you advertise your network as /24 (maybe one of them aggregating it for you, the other did not). Try aggregating them in your core router. Add the following lines in your BGP configuration
2. I see that you have eBGP multihop, does the connection problem surface only when you left with your eBGP connection with ISP2AS. eBGP Multihop peering if successful will receive all BGP route but will not be able to reach the destination if the routers between you and the ISP2AS does not have Internal routing protocol to reach those destinations. I have experience this in both Lab and Production.
One thing you can do is to check one of the looking glasses to see how your routes look when the first ISP goes down. In fact, I would check the looking glass and see what it looks like normally, then check it in failure mode, to see what the difference is.
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 ...