[j-nsp] MX VRRP on VXLAN enviroment

[Cristian Cardoso]

Hi
Thanks for the tip, I'll set it up here.

Em seg., 19 de jul. de 2021 às 14:36, Nitzan Tzelniker via juniper-nsp
<juniper-nsp at puck.nether.net> escreveu:
>
> 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
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp