On Thu, Apr 15, 2021 at 1:41 PM Mark Michelson <[email protected]> wrote:
>
> 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.
>

Hi Kumar,

The "reside-on-redirect-chassis" is required if your private logical
switches have localnet ports
i.e they are also provider networks (vlan or flat).

Is this your use case ?

I agree with Mark. The diagram is confusing and it is not giving a
clear picture.  Maybe you can
share the output of "ovn-nbctl show" or share your OVN Northbound
database to better understand
your use case.

Thanks
Numan



> >
> > 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
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to