Alex, If you detect gateway which is next hop failure you switch to other path anyway directly from compute nodes. BFD code is inrepo but I think still not integrated with the rest of contrail code.
Moreover your suggestion works only with global vxlan id for L2. Once vxlan id will be local or once someone is using l3 with gre to the gateways vpn label will be different from each gateway hence it may rather not work. Best, R. On Thursday, June 25, 2015, Alex Walker <[email protected]> wrote: > 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] > <javascript:_e(%7B%7D,'cvml','[email protected]');>] *On > Behalf Of *Dan Houtz > *Sent:* 25 June 2015 05:31 > *To:* [email protected] > <javascript:_e(%7B%7D,'cvml','[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 { > > 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 > > * Self 100 I > > 2:10.10.20.70:2::4::f8:c0:01:19:b1:88::10.10.10.146/304 > > * Self 100 I > > 3:10.10.20.70:2::4::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
