116
edits
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. | ||
== | == Pre-flight checks == | ||
These checks are to be done on the ''' | 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: | ||
edits