The question is the following i have 2 DC:
Site1 - Principal
Site2 - Secondary
The thing is my principal internet connection will be on Site1 and i have a network with multisite (192.168.120.0/24) and a server 1 on site 1 (.10) and a Server 2 on site 2(.20).
So the thing is that the server1 and server 2 need to get to the internet from Site 1 and only and in case of a faliure on site 1 the internet conection on site 2 should be use.
i all ready have ping from Server1 to Server2 and it works, so the question is.
Is this posible or not?
Gerardo Andree Mejia
Based on your description, I would expect the Border Leaf Switch (Leaf Switch where local Firewall connects to) on each fabric (site) to advertise a BGP EVPN type 5 default route (0.0.0.0/0).
Based on regular BGP path attributes, each Leaf Switch (aka VTEP) would compare the 0.0.0.0/0 its local Border Leaf advertises vs the 0.0.0.0/0 received from the Border Gateway (BGW) Switch (Switch that interconnects with the other sites in Multisite configurations).
You Border Leaf and Border Gateway happen to be the same device based on your topology.
The winner on each site would be the local 0.0.0.0/0 based on just Local_Preference BGP path attribute.
This logic is based on the fact that iBGP EVPN sessions are configured within the site and eBGP EVPN session is used to advertise the IPs and MACs across different sites.
Perhaps you can try increasing the Local_Preference on the BGW on site 2 for the 0.0.0.0/0 route site 1 is advertising so it can be preferred over its local 0.0.0.0/0 route.
NOTE: I have not tested this myself.
Actually i have that done that before and the best path default route for the second site is al ready the default route of the first site but the thing is, trafic still doesnt go through the first site.
From the pc on the Second site i can ping the ip of the Border leaf that connects to the InterTenant firewall but when i try to ping the Firewall the reponse never comes.
Any idea why and is it posible to do this to use the primary site to get the trafic from site to to get out?
and thanks for the @Hector Gustavo Serrano Gutierrez .
I think this should work since this is just VXLAN routing between sites in VXLAN BGP EVPN Multisite environment.
If traffic generated from PC in Site 2 does not hit the Firewall located in Site 1, I would suggest to start with looking at the VRF routing table on Leaf Switches, Border Leaf Switches and Border Gateways to ensure that the default route is properly installed for that specific Tenant (VRF).
If routes are in place, a common mistake I've seen in the configuration of VXLAN BGP EVPN Multisite greenfield deployments is the use of sub-interfaces for the DCI links. You must ensure that a physical L3 interface is used to connect the DCI link on the Border Gateway (BGW).
I'd suggest also go thru the entire Configuration Guide document and ensure you have a complete and consisting configuration including L2VNIs, L3VNIs, SVIs, VRFs, RDs, RTs, etc.
I just got the configuration running, the thing was that i forgot to put on the Route-Map of the reditribution of the bgp to the OSPF that conects to the ASA to put:
route-map RM-TRAFICO_VXLAN_LANs permit 10
match ip address prefix-list TRAFICO_VXLAN_LANs
match route-type internal external
and that was it so just one extra question if you can help me with it.
Is this the best way to do the redundancy to the DC or is ther any recomendation?
Thanks for the help by the way again.
I am glad it is working OK now @vivarock12,
Just as a final comment, check properly your failure scenarios and preferably test tem so you can make sure that Routing will respond to failures as you expect.
Exit point from the fabric with multi-site is controlled by the eBGP AS path. Normally the local fabric exit is preferred due to the exit via the other fabric having a longer eBGP AS-PATH. You could do some AS_PATH prepending on the eBGP peer that is northbound from fabric 2 so that routes from it always have a longer AS-PATH than those learned from fabric 1 across your DCI.
Edit: Didnt see the previous replies that essentially said the same thing. Oops.