could be transport connection-mode passive will help, for one side of the peering.
router bgp 45000 neighbor 192.168.1.2 remote-as 40000 neighbor 192.168.1.2 activate neighbor 192.168.1.2 transport connection-mode passive Jon Harald Bøvre > On (2011-09-06 12:03 +0400), Nikolay Shopik wrote: > >> I understand this because it actually changes state from down to >> active(trying to establish tcp session) and after timeout goes down >> again thus sending trap again. >> >> Is this behavior by design? I don't actually expect receive another >> trap until it change state from what I define(down or up). > > Unfortunately this is by design, people who designed BGP traps were > dreadfully > confused what people need. Now you must save previous BGP state in your > NMS, so > you are able to determine what happened. > > However some platforms, like IOS, extend standard BGP traps and include > 'previous state' field, this will allow you to react only on > establihes->down > and X->established events, without saving states in NNS. Some other > platforms, > like JunOS unfortunately do not provide you with this luxory. > > -- > ++ytti > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- Jon Harald Bøvre _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
