Hi, does it help to have a neighbor do Graceful Restart NSF through a Firewall. Also with regards to timers on BGP just want to confirm when using HSRP that the interface should become the Active HSRP prior to BGP forming a neighbor or attempting to form a neighbor. Currently the keepalive timer for HSRP is set to 3 and BGP is set to 2 but am not sure if this is optimal. Thx
graceful restart and non stop forwarding are thought for scenarios where a device with two route processors play a unique role in the network.
NSF aware neighbors of the NSF capable node can negotiate and can accept to hide a route processor switchover from external world by for example not dropping an OSPF or BGP session and by not withdrawing routes.
If no change happens during switchover it is totally hidden and traffic is sent towards the NSF capable node.
Now, you say that you have a firewall in between: it can still work if the firewall doesn't take part in BGP routing and doesn't sense an interface flap.
About timers: if HSRP plays a role for the BGP session it should be faster then BGP time to detect a failure: here BGP detects a failure in 7 seconds and HSRP peforms switchover in 10 seconds so it is not good in this way as you suspected.
Thanks for your reply. So just to confirm even though the firewall is in between (Its not participating in BGP routing and there is a default route configured to send traffic outbound) than if there is a RP switchover traffic will still be forwarded to the device that had the switchover and that device will in turn continue to forward traffic based on its cached information in the forwarding plane?
Also in order to negotiate graceful restart between the peers what timers would be recommended
1. For Graceful Restart
2. BGP Keepalive/Holdown
If you could provide some detail on how all these timers would interact that would be great as well. Thx for helping.
I think I have already answered; however here are my replies:
1) graceful restart and NSF are more a question of capabilities exchanged during BGP session setup rather then a question of timers
2) BGP timers can be aggressive but I think they need to be bigger then HSRP timers: in other words there is no use on dropping the BGP session but this should not happen during graceful restart where the NSF helping device hides the NSF capable switchover.
In any case if the other side has not declared a graceful restart BGP timers apply to the session.
3) HSRP swithover happens in 3 times the hello frequency and it should be faster then BGP holdtime.
Thanks for the reply. I was trying to get a relationship between the BGP graceful-restart restart-timer and the BGP neighbor holddown time and BGP graceful-restart stalepath-time and the BGP neighbor holdown time.
Per recommendations in cisco documents it seems that the BGP restart-time for Graceful Restart should be less than the BGP hold time. This does make sense as I assume that if there is a notification message sent to tear down the session and there is no open message sent as required by the Graceful Restart mechanism it would be useless. Could you please confirm if my understanding is correct on that?
Also currently I have configured a hello/hold time of 3 and 9 seconds respectively for the neighbor relationship across the firewall.
In addition also configured the BGP GR restart-time to be 6 seconds however the stalepath time is configured for 120 seconds.
This would mean that if there was a switchover on the control plane than there should be a OPEN message sent by the restarting peer within 6 seconds and if that does not happen than it will reset the neighbor relationship within 9 seconds.
If the open message is received within 6 seconds than it will continue to forward the traffic along the stalepath for a period of 120 seconds. Are these timers suitable or would they be too aggressive? Thx
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...