On 4/15/21 11:47 AM, Gk Gk wrote:
Hi,
I had a discussion with Michelson on the IRC regarding my questions on
the OVN man page. On page 8, under the Distributed gateway ports
section, the page discusses the physical mtu issues while sending the
traffic through the tunnel.
They man page suggests two options. One is to set the
reside-on-redirect-chassis option. If we set that option they said this,
"/The first solution is the reside−on−redirect−chassis option for
logical router ports. Setting this option on a LRP from (e.g.) LS1 to
LR1 disables forwarding from LS1 to LR1 except on the gateway chassis.
On chas- sis other than the gateway chassis, this single change means
that packets that would otherwise have been forwarded to LR1 are instead
forwarded to LN1. The instance of LN1 on the gateway chassis then
receives the packet and forwards it to LR1. The packet traverses the LR1
logical router pipeline, possibly undergoes NAT, and eventually ends up
at LSlocal’s localnet port. The packet never traverses a tunnel,
avoiding the MTU issue./
/This option has the further consequence of centralizing ‘‘distributed’’
logical router LR1, since no packets are forwarded from LS1 to LR1 on
any chassis other than the gateway chassis. Therefore, east-west traffic
passes through the gateway chassis, not just north-south. (The naive
‘‘fix’’ of allowing east-west traffic to flow directly between chassis
over LN1 does not work because routing sets the Ethernet source address
to LR1’s source address. Seeing this single Ethernet source address
originate from all of the chassis will con- fuse the physical switch.)/"
I have few questions on the above excerpt from the man page. I have
attached a diagram for the reference. If you see the diagram attached ,
if we set the reside-on-redirect-chassis option, then the east-west
traffic from VM1 goes thru LN1 port on LS1 to the gateway chassis where
the LR router is. This east-west traffic from VM1 will never go through
the LR1 on HV1 due to this setting. In this scenario, can you explain me
how it will change the ethernet source address of the east-west traffic
to the LR1 source address, and how will the traffic emerge from all
chassis with the same ethernet source address ?
I'll be honest, I'm not 100% sure about why the manpage claims that
east-west traffic will have the MAC flapping issue. I can understand for
N-S though.
The diagram is a bit hard to parse since it's hard to see how the GW-LR
is connected to the other logical datapaths. But I have to assume that
there is some sort of switch that connects LR1 and LR2 to GW-LR. We can
call this LS-pub
Consider an alternate network setup where VM1 and VM2 are both connected
to LR1 instead. Let's consider the situation where VM1 sends traffic
that needs to go out the GW-LR to the public. In that case, the traffic
starts on HV1 and goes VM1 -> LS1 -> LR1 -> LS-pub. Then for the egress
pipeline of LS-pub, the traffic will go out of LS-pub's localnet port to
the gateway chassis. The source MAC on the packet will be LR1's MAC, and
the TOR switch received the packet from HV1.
Now what aboue when VM2 needs to send traffic to GW-LR. The traffic
starts on HV2 and goes VM2 -> LS2 -> LR1 -> LS-pub. Then for the egress
pipeline of LS-pub the traffic will go out of LS-pub's localnet port to
the gateway chassis. The source MAC on the packet will be LR1's MAC, but
this time the TOR switch is receiving the packet from HV2.
This is the situation I understand. I'm not 100% sure why the east-west
situation would cause an issue though.
Thanks
Kumar
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
