Hello,
We experienced one issue with ARP cache propagation to the mac_binding
table.
Roughly, we have the following structure:
A logical router having a port that is detected as a gateway port.
It is attached to the logical switch that has one vtep port and several
logcial
ports. Also, the same router's port has a HA group assigned to it.
Finally, we have a logical router port, recognized as a gateway port and
it has
the cr-* counterpart that is the chassisredirect.
Then we try to announce ARP pair to cache starting from one of the logical
switch ports residing on the same switch as vtep port is.
We see the following behavior:
1. If we announce ARP with Reply command all is ok.
2. If we use ARP Request command it depends on the fact an issuing port
resides
on active HA group member. If it is not, mac_binding table is not updated.
Investigation shows that the reason of such behavior is in following lflows
generated for conditions described abouve:
table=1 (lr_in_lookup_neighbor), priority=100, match=(arp.op == 2),
action=(reg9[2] = lookup_arp(inport, arp.spa, arp.sha); next;)
table=1 (lr_in_lookup_neighbor), priority=100, match=(inport == "down1"
&& arp.spa == 192.168.0.0/24 && arp.op == 1
&& is_chassis_resident("cr-down1")),
action=(reg9[2] = lookup_arp(inport, arp.spa, arp.sha); next;)
You can see that ARP replies are always allowed while arp requesta only
pass thru (and later comes to the mac_binding table update) only if a
request
comes from a valid port/network AND controller is resident on the active HA
group member.
So, we have two questions arised:
1. What is a reason lflow restricts ARP requests by resident chassis only?
Is this a bug or desired behavior? If this is a bug how can I fix it
properly?
2. Why are all ARP replies allowed? In terms of ARP cache annonce
both ways (use request / reply) are equivalent.
Thank you,
Alexander
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
