BGP problem 'lost middleman'
Dunno if this has happened to others before, but in case not: I have a setup where 3 routers (ciscos, running 9.1.x if that's important) are running IBGP. A---------B-----------C | ext-net Router-A peers with 'B' & 'C', Router-B peers with B & C and C with B&A (a full IBGP mesh). Router A is an exit/border router. In addition to BGP, the routers run IGRP. The BGP routes are kept separate from the IGRP routes. For whatever reason (not a configuration error), the BGP session between A-B died but not between A-C, B-C. The result was that C 'knew' via the BGP session with A, that to get to external network 'ext-net', it should send traffic to A. It does the IGRP lookup to get to A, and sends the traffic to 'B'. However, since B did not have a BGP session with A, it did not know how to get to the ext-net (in the real case, B was sending traffic back to C since the default route was via C). A potential disaster!! I realize that the problem was the unexpected 'lost' BGP session between A-B, but are we sure that in a more complicated topology, something similar cannot happen ? What really make me worried is that there doesn't seem to be way to detect this kind of a problem easily.. how do others monitor their BGP sessions ? -vikas vikas@jvnc.net
Vikas, We monitor our peer sessions via the BGP3 MIB where we can. But we can't on our Ciscos because they haven't implemented the BGP3 MIB (or any BGP MIB). Daniel ~~~~~~ --------
Dunno if this has happened to others before, but in case not:
I have a setup where 3 routers (ciscos, running 9.1.x if that's important) are running IBGP.
A---------B-----------C | ext-net
Router-A peers with 'B' & 'C', Router-B peers with B & C and C with B&A (a full IBGP mesh). Router A is an exit/border router. In addition to BGP, the routers run IGRP. The BGP routes are kept separate from the IGRP routes.
For whatever reason (not a configuration error), the BGP session between A-B died but not between A-C, B-C.
The result was that C 'knew' via the BGP session with A, that to get to external network 'ext-net', it should send traffic to A. It does the IGRP lookup to get to A, and sends the traffic to 'B'. However, since B did not have a BGP session with A, it did not know how to get to the ext-net (in the real case, B was sending traffic back to C since the default route was via C).
A potential disaster!! I realize that the problem was the unexpected 'lost' BGP session between A-B, but are we sure that in a more complicated topology, something similar cannot happen ?
What really make me worried is that there doesn't seem to be way to detect this kind of a problem easily.. how do others monitor their BGP sessions ?
-vikas vikas@jvnc.net
Vikas, The result was that C 'knew' via the BGP session with A, that to get to external network 'ext-net', it should send traffic to A. It does the IGRP lookup to get to A, and sends the traffic to 'B'. However, since B did not have a BGP session with A, it did not know how to get to the ext-net (in the real case, B was sending traffic back to C since the default route was via C). This is a documented limitation running with "no synchronization". What really make me worried is that there doesn't seem to be way to detect this kind of a problem easily.. how do others monitor their BGP sessions ? "show ip bgp summary". And a little bird tells me that there is MIB in the works... Tony
What really make me worried is that there doesn't seem to be way to detect this kind of a problem easily.. how do others monitor their BGP sessions ?
"show ip bgp summary".
And a little bird tells me that there is MIB in the works...
Tony
Any timeframes you can give out ? Meanwhile, I will try and add an automated script for nocol monitoring,, thanks -vikas
Any timeframes you can give out ? Meanwhile, I will try and add an automated script for nocol monitoring,, thanks You might look for it in the BGP4 image. Tony
participants (4)
-
aggarwal＠nisc.jvnc.net -
aggarwal＠r2d2.jvnc.net -
Daniel W. McRobb -
Tony Li