Border reboot: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
Note: Throughout this guide <ipv4> and <ipv6> are to be replaced by the correct IP's. If you don't know, you can press the 'tab' key (twice) on your keyboard after typing 'neighbors' to get shown the options.
Note: Throughout this guide <ipv4> and <ipv6> are to be replaced by the correct IP's. If you don't know, you can press the 'tab' key (twice) on your keyboard after typing 'neighbors' to get shown the options.


== Preflight checks ==
== Pre-flight checks ==
These checks are to be done on the '''other''' border (So the border that will stay online), to ensure that when the border that's being rebooted is down the cluster won't lose network connectivity. The commands are to be invoked in `vtysh`.
These checks are to be done on the '''OTHER''' border (So the border that will stay online), to ensure that when the border that's being rebooted is down the cluster won't lose network connectivity. The commands are to be invoked in `vtysh`.
* Confirm our IPv4 block is announced over BGP with `show ip bgp neighbors <ipv4> advertised-routes`
* Confirm our IPv4 block is announced over BGP with `show ip bgp neighbors <ipv4> advertised-routes`
* Confirm our IPv6 block is announced over BGP with `show bgp neighbors <ipv6> advertised-routes`
* Confirm our IPv6 block is announced over BGP with `show bgp neighbors <ipv6> advertised-routes`
Line 11: Line 11:


== Disabling routing through a border ==
== Disabling routing through a border ==
First, perform the pre-flight checks on the '''OTHER''' border
On a border in `vtysh`, update the running configuration by invoking the following:
On a border in `vtysh`, update the running configuration by invoking the following:


116

edits

Navigation menu