[j-nsp] MX VRRP on VXLAN enviroment

[Cathal Mooney]

In theory when the VRRP falls over, the promoted MX80 should send a 
frame with the VRRP virtual MAC as source, causing it to be learnt on a 
different switch.  That switch should then send an EVPN type-2 UPDATE 
for the MAC and the remaining switches will update their local MAC 
tables with VXLAN-encap next-hop.  Can you verify any of that?  Like 
does the MAC get learnt from the other MX80 properly?  Does the EVPN 
update get generated?


On 19/07/2021 13:56, Cristian Cardoso via juniper-nsp wrote:
> I had several problems using the virtual gateway via EVPN on the
> switches, even the function of being switches and not routers. In my
> scenario it is important to have a minimal firewall on the interfaces,
> and in the models I have here, this is not possible.
> My idea of using VRRP on the routers above the VXLAN switches, is just
> to let the switches do only the VXLAN and thus remove the functions of
> the layer 3 gateway from the qfx.
> Using a more "simple" Layer 3 scenario for routing.
>
> Em seg., 19 de jul. de 2021 às 09:41, Nathan Ward
> <juniper-nsp at daork.net> escreveu:
>> Hi,
>>
>>> On 20/07/2021, at 12:23 AM, Cristian Cardoso via juniper-nsp <juniper-nsp at puck.nether.net> wrote:
>>>
>>> I have a scenario here where I use EVPN-VXLAN with qfx5120 switches
>>> and until then I was using the gateways on the switches, but as the
>>> switch does not have the possibility to use any kind of firewall on
>>> the irb interfaces, I had the idea to migrate the networks to two
>>> routers MX80.
>>> But I caught a problem with these routers, when using VRRP over VXLAN.
>>> I configured the two MX80 routers with VRRP in IPv4 and IPv6,
>>> sometimes IPv4 dies and the virtual IP stops responding, generating
>>> timeout in network accesses.
>>> Apparently it seems that the mac address of the virtual IP and the
>>> table of mac's of the VXLAN are lost, causing the problem.
>>> Does anyone happen to have a scenario like this and faced this problem?
>> I’m not sure exactly what is causing your problem, though there are certainly a lot of curly edge cases in EVPN where this sort of thing can happen.
>> Do you have a specific need to run VRRP?
>>
>> One of the benefits of EVPN is “virtual-gateway-address” which advertises the gateway address from all IRBs with that configured - and they are all “active” rather than VRRP’s active/standby.
>> If you don’t have a need for VRRP specifically, this might be a better solution for you.
>>
>> Incidentally, by default it uses the VRRP group 1 MAC, but it is not running VRRP at all. You can configure it to use a different MAC, if required (i.e. if you have other devices on that broadcast domain running VRRP group 1 perhaps).
>>
>> --
>> Nathan Ward
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp