[j-nsp] SNMP monitoring of BGP sessions
Richard A Steenbergen
ras at e-gerbil.net
Mon Jul 30 14:38:14 EDT 2007
On Mon, Jul 30, 2007 at 10:49:12AM +0100, Ras wrote:
> Hi all,
>
> I'm currently running some hand-written (ie possibly buggy) BGP
> monitoring code, using SNMP.
>
> My understanding (and experience from my Ciscos) is that if
> bgpPeerState is anything but 'established' (6) and bgpPeerAdminStatus
> is in 'start' (2) then there is a problem, ie the device thinks the
> peering should be up but it isn't.
>
> In general, it seems that if bgpPeerAdminStatus is in 'stop' (1) then
> the peer has been configured admin down and can be safely ignored.
>
> Unfortunately, on the Junipers when bgpPeerState drops into 'idle' (1)
> the bgpPeerAdminStatus drops into 'stop' (1). This seems to me to
> indicate that there is no way to tell the difference between a peering
> that is down but should be up, and a peering that is admin down.
>
> Has anyone else seen this / can give me some advice on how to
> distinguish between failed sessions and hard down sessions?
Juniper lacks an admin down setting for BGP neighbors (please for the love
of god why can't someone fix this, the entire Juniper-using population has
only been begging for it since the beginning :P). The only way to disable
a neighbor is to "deactivate" the neighbor statement, which removes it at
the configuration parser level as though the statement didn't exist at
all. This obviously prevents you from seeing it in SNMP, show bgp, etc.
I'm not familiar with the way Juniper changes snmp adminstatus, but if I
had to guess I would say it probably does this when it's going to be
staying in idle forever due to a problem at a lower layer (as opposed to
being temporarily idle as part of the BGP finite state machine). For
example, if you have an eBGP non-multihop neighbor configured to a remote
address which is on a directly connected interface and you remove or
disable that interface, there is no possible way for the BGP session to
ever come up, so it will stay idle and not even try going through
active/connect state.
--
Richard A Steenbergen <ras at e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
More information about the juniper-nsp
mailing list