[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