Implicit Withdrawal - BGP Update Message

Hi Ado,

On 11/10/15 18:21, Ado Maja wrote:
> It was by mistake that I send an example where BGP messages are not
> coming from the same peer. All four messages in the example were
> supposed to have same peer, and announced IP address while different
> AS-PATH attribute.
> In that case I would have three implicit withdrawals, right?

Yes, if all four messages were the same prefix and same peer, then you
would have three (or four) implicit withdrawals.

> Are you suggesting that if I look at five-days worth of BGP update
> messages and trying to count how many implicit withdrawals during that
> time I have that I need to check first appearance of every announced IP
> address and check if it is ‘truly’ new announcement or possibly an
> implicit withdrawal that happened prior to the time frame I am looking at?

Yes exactly, if you want to be accurate in your count.

That is what the RIB dumps (the bview) files help you with. They give
you a snapshot at a time, for you to base your update analysis on.
Otherwise you'd need to search through previous update files looking for
either an earlier update message for the same {peer,prefix}, or a peer
session reset.

> Also, I was completely ignoring the state change messages. Are you
> referring to the messages below? I am not sure what to make out of those.

Yes those are the state change messages. They indicate a transition in
the BGP Finite State Machine for a BGP speaker (see RFC4271, section 8)

For the most part, you can ignore all of them except for transitions
to/from state 6 (Established). If a peer session goes in or out of state
6, then a new session has been established or torn down, and any data
you were considering about that peer should be reset too.

If the session resets, whenever it comes back up, it is likely that the
peer will re-announce the prefixes it had in its RIB before the reset.
This is the initial startup phase. So when the peer sends you an
announce for a prefix after a state change, the first announcement is
*not* an implicit withdrawal. But any further messages after that (with
the same {peer,prefix}) are implicit withdrawals. Until the next time
the state changes.

Hope this makes sense.

Cheers
Colin

-- 
Colin Petrie
Systems Engineer
RIPE NCC