3

In a capture I've made between a Cisco 6500 (with two SUP2T card) and another Firewall I can see that the Cisco Router is sending a "Forwarding State" Flag equal to 0.

Since this is in the initialization and since in the RFC we can read :

https://tools.ietf.org/html/rfc4724

If one wants to apply graceful restart only when the restart is planned (as opposed to both planned and unplanned restart), then one way to accomplish this would be to set the Forwarding State bit to 1 after a planned restart, and to 0 in all other cases. Other approaches to accomplish this are outside the scope of this document.

Does-this mean that the Cisco is only capable to supporting Planned Graceful-restart (ie. Card SwitchOver) and not unplanned (ie. Sudden problem with the SUP2T card).

Is there any reason for the Cisco to not send a "Forwarding State" Flag equal to 1 in the initialization ?

Thanks for any help,

1

Does-this mean that the Cisco is only capable to supporting Planned Graceful-restart (ie. Card SwitchOver) and not unplanned (ie. Sudden problem with the SUP2T card)?

No, it just means that BGP hasn't restarted yet.

Quoting from RFC 4724 Graceful Restart Mechanism for BGP, pg 5:

  Flags for Address Family:

     This field contains bit flags relating to routes that were
     advertised with the given AFI and SAFI.

         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |F|   Reserved  |
        +-+-+-+-+-+-+-+-+

     The most significant bit is defined as the Forwarding State (F)
     bit, which can be used to indicate whether the forwarding state
     for routes that were advertised with the given AFI and SAFI has
     indeed been preserved during the previous BGP restart.  When
     set (value 1), the bit indicates that the forwarding state has
     been preserved.

The RFC is pretty specific, when Forwarding State is set, then the routes were preserved during the "previous BGP restart".

Also refer to Section 4.1:

To re-establish the session with its peer, the Restarting Speaker
 MUST set the "Restart State" bit in the Graceful Restart Capability
 of the OPEN message.  Unless allowed via configuration, the
 "Forwarding State" bit for an address family in the capability can be
 set only if the forwarding state has indeed been preserved for that
 address family during the restart.

Again we see that (aside from static configuration), one should set the Forwarding State bit "only if the forwarding state has indeed been preserved for that address family during the restart".

  • But here I think it's different, because there is no restart yet, this is only the session initialization. – ClearShell Jan 14 '15 at 11:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.