Hello! Let me know if this answers all your questions, don't hesitate to ask if not. Wikinetwork codfw side: AS65002 cr1-codfw IP: 208.80.153.186 cr2-codfw IP: 208.80.153.187 Will import (accept) prefixes: - 185.15.57.0/24 - 172.16.128.0/21 (can be adjusted as you wish) Will export a default route WMCS codfw side: AS64711 cloudnetX IP: cloudnetY IP: BFD if availlable: 3*300ms The transition from static to BGP is impact-less and can be done anytime (with a small notice to prepare the config). Steps are: 1/ configure BGP and verify it's behaving as expected At this point the static routes will still have the priority 2/ Remove the static routes and VRRP/VIP config Need BGP (and optionally BFD) ports open and listening to the routers IPs. Cheers On Tue, Feb 18, 2020 at 12:38 PM Arturo Borrero Gonzalez < aborrero(a)wikimedia.org&gt; wrote: -- Arzhel

On 2/20/20 7:18 PM, Arturo Borrero Gonzalez wrote: My assumptions were wrong. Apparently neutron ignores the software defined transport network and uses the physical network for doing the BGP stuff. This is the neutron BGP agent trying to contact the core router: 11:05:18.615101 IP 10.192.20.10.34716 > 208.80.153.185.179: Flags [S], seq 2498112052, win 29200, options [mss 1460,sackOK,TS val 1130299297 ecr 0,nop,wscale 9], length 0 For tests, I configured the BGP peer to contact 208.80.153.185 which is vrrp-gw-2120.wikimedia.org (i.e, the core router VIP in the cloud transport network). Note how the source address is 10.192.20.10 (cloudnet2002-dev.codfw.wmnet). So I'm discarding my approach and creating the BGP session using the physical network. You should allow BGP from the following addresses: * cloudnet2002-dev.codfw.wmnet: 10.192.20.10 * cloudnet2003-dev.codfw.wmnet: 10.192.20.12 And I will contact: * cr1-codfw IP: 208.80.153.186 * cr2-codfw IP: 208.80.153.187 as you originally suggested. regards. -- Arturo Borrero Gonzalez SRE / Wikimedia Cloud Services Wikimedia Foundation