[j-nsp] MX VRRP on VXLAN enviroment

[Nitzan Tzelniker]

Take a look on this KB
https://kb.juniper.net/InfoCenter/index?page=content&id=KB35676&cat=EX9208&actp=LIST

The default duplicate-mac-detection settings are far to high

Nitzan

On Mon, Jul 19, 2021 at 4:50 PM Cathal Mooney via juniper-nsp <
juniper-nsp at puck.nether.net> wrote:

> 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
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>