Hello Cristian
I once faced a similar issue and I came across this PR mentioned in this
KB. I think it’s worth checking.
https://supportportal.juniper.net/s/article/Junos-18-4R3-3-18-4R3-S1-3-18-4R3-S2-19-1R2-8-19-1R2-S1-1-19-2R2-is-not-recommended-to-be-deployed-on-MX-Series-platform-with-Trio-MP
Hi Cristian,
I tried to reproduce the issue by reverting the configuration, but it
didn't occur. It's still unclear to me why only v4 was affected and v6
was not. Furthermore, in stable state (which it was in my case) vrrp
backup is silent so no mac move events can happen and I confirmed it
w
Hi Andrey
In my case, what you said happened, as I modified the arp suppression
configuration of evpn-vxlan, since this was silently dropping mac's and
dropping VRRPv4 only, in IPv6 this did not happen.
set protocols evpn duplicate-mac-detection detection-threshold 20
set protocols evpn duplicate
Hi Andrey
My idea was to keep only with VRRP to be something simpler for the
team to manage.
I set the config that Nitzan Tzelniker suggested and so far I haven't
seen more occurrences of arp suppression problems in VXLAN.
Of course, the last time this happened it took about 2 weeks to end up
happ
Cristian Cardoso via juniper-nsp писал 2021-07-19 14:15:
Hi
Thanks for the tip, I'll set it up here.
Are you trying to setup MX80 as end-host, without including it in EVPN?
If so, then you can extend EVPN to MX80 and run virtual-gateway from it.
No need for VRRP in this case.
Kind regards,
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
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 t
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@puck.nether.net> wrote:
> In theory when th
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-
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 abov
Hi,
> On 20/07/2021, at 12:23 AM, Cristian Cardoso via juniper-nsp
> 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 i
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
11 matches
Mail list logo
