Hi Dan, Had you considered not using VRRP, and configuring both of your MX IRBs to use the same IP address and MAC? You’ll need to think about it for your own situation, but this could achieve the redundancy you require?
Each MX will announce the same MAC via EVPN BGP. If either next-hop is used, either should forward traffic OK for you. Should one gateway fail, standard BGP path selection will then simply select the other gateway. You could probably even play with Local Preference to prefer one gateway over the other? Hope this helps – good luck with it! Alex. From: Users [mailto:[email protected]] On Behalf Of Dan Houtz Sent: 25 June 2015 05:31 To: [email protected] Subject: [Users] Redundant L3 gateways using MX80s Hi, I've been working hard to get BMS / TOR switch VXLAN overlays working and, with the gracious help of Praveen, I believe everything is mostly working as expected now. With that functionality in a working state I'm now looking at adding in L3 gateway support using a pair of MX80s. This seems pretty straight forward with one MX but I haven't quite got a redundant setup working properly. Are there any documented 'best practices' for this? In an attempt to add redundancy I am trying to configure VRRP (I'm not sure EVPN anycast gateways are viable in this setup. Hopefully someone can confirm). At present VRRP does converge across the overlay, my hosts can ping the physical IP addresses configured on each MX IRB, and my hosts succeed in getting ARP for the VRRP VIPs. They can not, however, complete a ping (I do have accept-data configured for VRRP so MX should reply to pings). After a bit of digging I believe this is because the virtual MAC address of the VIP is not being announced via BGP so my TOR switches never learn the MAC via OVSDB. root@gw1z0> show configuration interfaces irb.5 family inet { address 10.10.10.146/29<http://10.10.10.146/29> { vrrp-group 13 { virtual-address 10.10.10.145; priority 105; accept-data; } } } root@gw1z0> show route advertising-protocol bgp 10.10.10.139 Demo-NetworkA.evpn.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 2:10.10.20.70:2::4::f8:c0:01:19:b1:88/304 * Self 100 I 2:10.10.20.70:2::4::f8:c0:01:19:b1:88::10.10.10.145/304<http://10.10.10.145/304> * Self 100 I 2:10.10.20.70:2::4::f8:c0:01:19:b1:88::10.10.10.146/304<http://10.10.10.146/304> * Self 100 I 3:10.10.20.70:2::4::10.10.20.70/304<http://10.10.20.70/304> * Self 100 I __default_evpn__.evpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 1:10.10.20.70:0::050000ff840000000400::FFFF:FFFF/304 * Self 100 I As you can see in the advertised BGP routes above the MX is announcing .145 with the actual MAC of the IRB: root@gw1z0> show interfaces irb | grep hardware Current address: f8:c0:01:19:b1:88, Hardware address: f8:c0:01:19:b1:88 not the virtual MAC that has been assigned for VRRP: root@gw1z0> show vrrp extensive | grep mac Virtual Mac: 00:00:5e:00:01:0d I suspect that because the MX never announces an EVPN mac of 00:00:5e:00:01:0d, my TOR never learns where that MAC lives: oot@leaf1z0> show ovsdb mac Logical Switch Name: Contrail-12905c4b-60db-4d71-8fab-972051db1386 Mac IP Encapsulation Vtep Address Address Address ff:ff:ff:ff:ff:ff 0.0.0.0 Vxlan over Ipv4 10.10.20.65 d4:ae:52:c6:c9:e1 0.0.0.0 Vxlan over Ipv4 10.10.20.65 50:c5:8d:d4:af:f0 0.0.0.0 Vxlan over Ipv4 10.10.20.71 54:9f:35:05:fa:2e 0.0.0.0 Vxlan over Ipv4 10.10.20.66 f8:c0:01:19:b1:88 0.0.0.0 Vxlan over Ipv4 10.10.20.70 ff:ff:ff:ff:ff:ff 0.0.0.0 Vxlan over Ipv4 10.10.10.139 Is there perhaps a knob I'm missing? Is there something other then VRRP that is preferred for redundant gateways in Contrail? I have the same question out to a few other resources but figured someone on the mailing list might have some good pointers as well. Thanks! Dan
_______________________________________________ Users mailing list [email protected] http://lists.opencontrail.org/mailman/listinfo/users_lists.opencontrail.org
