That is exactly what we have going on.
INTERNAL INTERNAL -----Original Message----- From: Ilya Maximets <i.maxim...@ovn.org> Sent: Wednesday, November 6, 2024 8:34 AM To: Heim, Dennis <dennis.h...@wwt.com>; ovs-discuss@openvswitch.org Cc: i.maxim...@ovn.org Subject: [EXTERNAL] Re: [ovs-discuss] ERSPAN Termination. On 11/3/24 04:22, Heim, Dennis via discuss wrote: > I am trying to use a pair of OVS for an ERSPAN link. On the first OVS, > I configure ERSPAN per the following: > > ovs-vsctl add-port data at_erspan0 -- set int at_erspan0 type=erspan > options:key=1 options:remote_ip=192.168.1.30 options:erspan_ver=1 > options:erspan_idx=1 > > > > The traffic is sent ERSPAN encapsulated to 192.168.1.30. However, when > it comes to decapsulating, that is where my problem is. If I create an > erspan interface, with the remote ip of the first OVS, then the > problem I get is that essentially the traffic appears to be a loop. If > I do not create the ERSPAN interface on the 2^nd OVS, then I am unable > to decapsulate the traffic. > > > > Is there a setting to prevent this loop or to drop the traffic so we > do not get a loop, but I am able to decapsulate the traffic? > > *Dennis Heim | Technical Solutions Architect* Hi, Dennis. You're likely creating a loop in your topology. IIUC, you have only one bridge, right? So, you have something like this: bridge data (ip 192.168.1.10) port eth0 (physical port) <other ports> port at_erspan0 (options:remote_ip=192.168.1.30) And a similar setup with opposite IP addresses on the other side: bridge data (ip 192.168.1.30) port eth0 (physical port) <other ports> port at_erspan0 (options:remote_ip=192.168.1.10) I'm also assuming that you're not using specific OpenFlow rules and fully replying on the mac learning from the default actions=NORMAL. Is that correct? In this topology you have two separate links that connect two nodes. One is a physical connection over eth0 and the other is a tunnel. So, when a packet from the host A sends a packet from ip 192.168.1.10 to 192.168.1.30, the packet will enter the bridge, then it will be first broadcasted to both eth0 and at_erspan0, since the MAC is not learned yet. The same will happen on the other side for both copies of the packet, one received from the eth0 and one from the tunnel and both will be broadcasted again multiplying the traffic. You either need to write specific OpenFlow rules that will send packets to only one link, or you need to change the topology. The most common way of setting up an OVS with tunnels is by utilizing two bridges, like this: bridge br-ext (ip 192.168.1.10) port eth0 bridge br-int <other ports> port at_erspan0 (options:remote_ip=192.168.1.30) And the same on the other side. This way, when your hosts want to send traffic to each other, they will talk over br-ext with no tunnels involved and no traffic duplication. But if some ports from br-int will want to talk to other ports from br-int but ont he other node, the traffic will go to a tunnel, then kernel will route the encapsulated packet to br-ext, so it will be sent over eth0. On the other side the encapsulated packet will arrive on eth0, go to br-ext port, kernel will decapsulate it and inject into br-int, where it can proceed to the destination port. HTH. Best regards, Ilya Maximets. CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
