Between sites (confederations) we currently have those 3 options:
- Export full views (no export filters, used between eqiad/codfw)
- BGP_Wikimedia_no_dfz Export Wikimedia private/public prefixes learned via BGP (eg. used on eqiad->ulsfo, codfw->ulsfo, ulsfo->eqsin)
- BGP_Wikimedia_own_space Export public prefixes (same as to DFZ) + customers prefixes (if any) (eg. used on eqiad->esams, esams->eqiad, ulsfo->eqiad)
My proposal here is to add the customers term to BGP_Wikimedia_no_dfz and replace all export BGP_Wikimedia_own_space with export BGP_Wikimedia_no_dfz.
This has the following advantages:
- Standardized and less complex (one less) routing policies
- Anycast VIPs (in the private space) will be routed across all sites (eg. if esams rec-dns servers are down, esams clients will route to eqiad)
I can't see any downsides, but I also don't have the historical reasons on why it has been configured that way.
Changes are:
all routers
[edit policy-options policy-statement BGP_Wikimedia_no_dfz]
term public6 { ... }
+ term customers {
+ from community PEER_CUSTOMER;
+ then accept;
+ }
- term reject_other {
- then reject;
- }
[edit policy-options policy-statement BGP_Wikimedia_no_dfz]
+ then reject;
[edit policy-options]
- policy-statement BGP_Wikimedia_own_space {
- term local4 {
- from policy BGP_outfilter;
- then accept;
- }
- term local6 {
- from policy BGP6_outfilter;
- then accept;
- }
- then reject;
- }(this also moves the reject from a term to a default)
router specific (eg. eqiad)
[edit protocols bgp group Confed_esams] - export BGP_Wikimedia_own_space; + export BGP_Wikimedia_no_dfz;
To be deployed progressively site by site.