[j-nsp] QFX3500 and... multicast forward (VRRP related)

[Thomas Bellman]

On 2021-09-13 13:56, Xavier Beaudouin wrote:

> I have a strange clue with an QFX3500-48S4Q, and with "simple" VRRP
> setup.
> 
> On port xe-0/0/6.0 I have a infrastructure (cisco switches) with a
> VLAN 3016 who want to be VRRP with an MX204 on et-0/1/0.0.
> 
> Current config of the switch :
> 
> [...]
> 
> Pretty "simple" configuration.
> 
> When I monitor traffic interface et-0/1/0.0 match vrrp I see the VRRP
> comming MX204 and on xe-0/0/6.0 I see also VRRP comming TO the QFX...
> Is there any reason why VRRP on the VLAN is not forwarded between
> et-0/1/0.0 and xe-0/0/6.0 ?
> 
> Did I missed something ?

The 'monitor traffic' command will only show packets that actually go
to or from the routing engine ("supervisor" in Cisco speak).  Traffic
that is just forwarded by the packet forwarding engine (the line cards
on an MX, or the ASIC on the QFX3500) don't show up.  Traffic that is
generated by or handled by the PFE itself, e.g. BFD on some platforms,
*also* are not visible to 'monitor traffic'.  (Also worth noting, is
that incoming traffic that *is* destined for the routing engine, but
is discarded by a firewall rule executing on the PFE, also won't be
seen by 'monitor traffic'.)

The fact that you see VRRP packets from both the Cisco and the MX,
is probably because it is multicast, so it is forwarded both to the
other port, *and* to the routing-engine.  But since the QFX3500 is
not itself doing any VRRP, you won't see any outgoing VRRP packets.

The interresting question is if the MX and the Cisco see each other's
VRRP packets.  Do they both think they are master?  (It seems like the
command to use is 'show vrrp' both in Junos and IOS.)  If both sides
believe they are master, then you have a real forwarding problem, but
if one side think they are backup, and says the other is master, then
the VRRP packets are forwarded as they should.

This is what it looks like on a Juniper:

  bellman at ...> show vrrp 
  Interface  State  Group  VR state  VR Mode  Timer    Type  Address
  irb.13     up         1  backup    Active   D 2.949  lcl  192.168.13.18
                                                       vip  192.168.13.19
                                                       mas  192.168.13.20

This says that my router's own IP address ("lcl") is 192.168.13.18,
the virtual address the routers are battling for ("vip") is
192.168.13.19, and the current master ("mas") is 192.168.13.20.
(I don't have a Cisco at hand to check what the output looks like
there.)

Note though, that if you run 'show vrrp' on the VRRP master, you
won't see any information about which nodes are backups.  That's
because in the VRRP protocol, only the master, or those that want
to take over the master role, sends any packets; those that are
backup and happy with being so, are silent.  (This is unlike
Cisco's older HSRP protocol, where both master and backup where
sending, allowing you to see all participating nodes by running
'show hsrp' on any of the nodes.)

If you run the 'monitor traffic' command on the MX, you should be
able to see the VRRP traffic it receives and/or sends.  (I don't
know if there is any equivalent on command on Cisco's operating
systems.)


	/Bellman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20210915/94eae316/attachment-0001.sig>