Re: [ovs-discuss] IPsec error
Yes, probably I made that mistake because I remember using that command, probably because my first try didn’t worked. I used this tutorial (https://docs.openvswitch.org/en/latest/tutorials/ipsec/) I think it didn’t worked but I can try again... Then I tried doing something else, that was when I probably ran that command. Can I follow the steps in Fedora of that tutorial or if not can you please help me and tell me what and how is the right way to install OVS and IPSec in CentOS 8? Like a link with this information? Thank you, Mariana Cruz > On 15 Apr 2021, at 21:46, Ansis wrote: > > On Thu, Apr 15, 2021 at 3:29 PM Mariana Cruz > wrote: >> >> Hello, >> >> Thank you for your reply. Unfortunately my screen is cut but i managed >> to see what was on the other half of the error message (see attach). > > Have you mixed and matched pieces of OVS that were built with > ./configure --prefix=/usr/local and ./configure --prefix=/? > > This may have happened accidentally if you tried to build some bits > yourself and installed other from Centos repo. > > > >> >> Waiting for your reply. >> >> >> Thanks in advance, >> >> Mariana Cruz >> >>> On 15/04/21 20:10, Ansis wrote: >>> On Thu, Apr 15, 2021 at 1:37 PM Mariana Cruz >>> wrote: Hello, I am trying to install and start the openvswitch-ipsec.service in my CentOS 8, but it generates some errors (see attach file), so the IPsec tunnel doesn't work. Can you please help? >>> Can you post the full line of "No such file or directory: >>> '/usr/local"? It was truncated in your screenshot. Thanks a lot. Mariana Cruz ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] IPsec error
Hello, Thank you for your reply. Unfortunately my screen is cut but i managed to see what was on the other half of the error message (see attach). Waiting for your reply. Thanks in advance, Mariana Cruz On 15/04/21 20:10, Ansis wrote: On Thu, Apr 15, 2021 at 1:37 PM Mariana Cruz wrote: Hello, I am trying to install and start the openvswitch-ipsec.service in my CentOS 8, but it generates some errors (see attach file), so the IPsec tunnel doesn't work. Can you please help? Can you post the full line of "No such file or directory: '/usr/local"? It was truncated in your screenshot. Thanks a lot. Mariana Cruz ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovn] recommendation to gateway chassis
Any comments? Thanks! Tony > -Original Message- > From: discuss On Behalf Of Tony > Liu > Sent: Saturday, April 3, 2021 12:05 PM > To: ovs-discuss > Subject: [ovs-discuss] [ovn] recommendation to gateway chassis > > Hi, > > For now, I have a setup with DVR to route FIP traffic directly on > compute node and dedicated central GWs to handle SNAT traffic. > Then I realize that I can put GW chassis on compute node as well. > Is this recommended over dedicated GW chassis? > > If yes, is there any difference between 1) picking up a few compute > nodes as GW and 2) putting GW on all compute nodes (like 200 nodes), in > terms of the impact to OVN control plane and data plane, like DB sizing > and handling, performance, health check peering, etc.? > > Or the question is that, what's the comfortable scale of gateway chassis > in OVN. If it's a few hundreds, then having GW on all compute nodes > would be the best option. > > Any comment is appreciated. > > > Thanks! > Tony > > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Need assistance
On Thu, Apr 15, 2021 at 1:41 PM Mark Michelson 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 > > disc...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] IPsec error
On Thu, Apr 15, 2021 at 4:00 PM Mariana Cruz wrote: > > Yes, probably I made that mistake because I remember using that command, > probably because my first try didn’t worked. I used this tutorial > (https://docs.openvswitch.org/en/latest/tutorials/ipsec/) I think it didn’t > worked but I can try again... Then I tried doing something else, that was > when I probably ran that command. > Can I follow the steps in Fedora of that tutorial or if not can you please > help me and tell me what and how is the right way to install OVS and IPSec in > CentOS 8? Like a link with this information? > I would recommend to redo everything from scratch and make sure ./configure is invoked consistently. > Thank you, > Mariana Cruz > > On 15 Apr 2021, at 21:46, Ansis wrote: > > On Thu, Apr 15, 2021 at 3:29 PM Mariana Cruz > wrote: > > > Hello, > > > Thank you for your reply. Unfortunately my screen is cut but i managed > > to see what was on the other half of the error message (see attach). > > > Have you mixed and matched pieces of OVS that were built with > ./configure --prefix=/usr/local and ./configure --prefix=/? > > This may have happened accidentally if you tried to build some bits > yourself and installed other from Centos repo. > > > > > Waiting for your reply. > > > > Thanks in advance, > > > Mariana Cruz > > > On 15/04/21 20:10, Ansis wrote: > > On Thu, Apr 15, 2021 at 1:37 PM Mariana Cruz > > wrote: > > Hello, > > > I am trying to install and start the openvswitch-ipsec.service in my > > CentOS 8, but it generates some errors (see attach file), so the IPsec > > tunnel doesn't work. > > > Can you please help? > > Can you post the full line of "No such file or directory: > > '/usr/local"? It was truncated in your screenshot. > > Thanks a lot. > > > Mariana Cruz > > > ___ > > discuss mailing list > > disc...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] IPsec error
On Thu, Apr 15, 2021 at 3:29 PM Mariana Cruz wrote: > > Hello, > > Thank you for your reply. Unfortunately my screen is cut but i managed > to see what was on the other half of the error message (see attach). Have you mixed and matched pieces of OVS that were built with ./configure --prefix=/usr/local and ./configure --prefix=/? This may have happened accidentally if you tried to build some bits yourself and installed other from Centos repo. > > Waiting for your reply. > > > Thanks in advance, > > Mariana Cruz > > On 15/04/21 20:10, Ansis wrote: > > On Thu, Apr 15, 2021 at 1:37 PM Mariana Cruz > > wrote: > >> Hello, > >> > >> I am trying to install and start the openvswitch-ipsec.service in my > >> CentOS 8, but it generates some errors (see attach file), so the IPsec > >> tunnel doesn't work. > >> > >> Can you please help? > > Can you post the full line of "No such file or directory: > > '/usr/local"? It was truncated in your screenshot. > >> Thanks a lot. > >> > >> Mariana Cruz > >> > >> ___ > >> discuss mailing list > >> disc...@openvswitch.org > >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] IPsec error
On Thu, Apr 15, 2021 at 1:37 PM Mariana Cruz wrote: > > Hello, > > I am trying to install and start the openvswitch-ipsec.service in my > CentOS 8, but it generates some errors (see attach file), so the IPsec > tunnel doesn't work. > > Can you please help? Can you post the full line of "No such file or directory: '/usr/local"? It was truncated in your screenshot. > > Thanks a lot. > > Mariana Cruz > > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Need assistance
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 disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Need assistance
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 ? Thanks Kumar OVN-diagram.docx Description: MS-Word 2007 document ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] incoming packets truncated on I225 interface in OVS-DPDK
Hi all,
I noticed something weird when using an I225 interface in OVS-DPDK:
outgoing packets are processed normally, while incoming packets get
truncated. In particular, starting from a certain IP packet length, the
last 4 Bytes are always truncated.
For instance here are an ICMP and a UDP packet that got truncated:
08:36:06.482278 IP truncated-ip - 4 bytes missing! (tos 0x0, ttl 64, id
28665, offset 0, flags [DF], proto ICMP (1), length 84)
10.88.1.12 > 10.88.1.22: ICMP echo request, id 8967, seq 10, length 64
15:02:14.512439 IP truncated-ip - 4 bytes missing! (tos 0x0, ttl 64, id
36650, offset 0, flags [DF], proto UDP (17), length 75)
1.1.1.2.37599 > 1.1.1.1.9000: UDP, length 47
If I play a bit with the IP packet size, I see that:
- IP packets of up to 42 bytes are not altered,
- 43-byte packets have their last byte truncated,
- 44-byte packets their last 2 bytes
- 45-bytes their last 3 bytes,
- starting from 46 bytes it's always the last 4 bytes that get truncated.
My setup is all on the same device, it includes 2 Debian VMs with a virtio
interface, exposing a TAP interface on the host (just for simplicity in
this particular test, in order to run tcpdump on the host) and two physical
interfaces, connected one to another with an ethernet cable:
[ Debian VM1, virtio] -- [tap, OVS switch, eth1] === cable=== [eth2 in
DPDK, OVS switch, tap] -- [virtio, Debian VM1]
eth2 is I225, the NIC corresponding to eth1 is not relevant, it might as
well be I225 in non-dpdk mode or any other NIC.
I run a ping to VM2 from VM1 and if I compare the same packet on the two
VMs it is clear that the bytes that get dropped are at the end of the IP
packet:
At the source:
08:36:06.479357 IP (tos 0x0, ttl 64, id 28665, offset 0, flags [DF], proto
ICMP (1), length 84)
10.88.1.12 > 10.88.1.22: ICMP echo request, id 8967, seq 10, length 64
0x: 4500 0054 6ff9 4000 4001 b3de 0a58 010c E..To.@.@X..
0x0010: 0a58 0116 0800 cac1 2307 000a 76a9 7660 .X..#...v.v`
0x0020: 5750 0700 1011 1213 WP..
0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .!"#
0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123
0x0050: 3435 3637
At the destination:
08:36:06.482278 IP truncated-ip - 4 bytes missing! (tos 0x0, ttl 64, id
28665, offset 0, flags [DF], proto ICMP (1), length 84)
10.88.1.12 > 10.88.1.22: ICMP echo request, id 8967, seq 10, length 64
0x: 4500 0054 6ff9 4000 4001 b3de 0a58 010c E..To.@.@X..
0x0010: 0a58 0116 0800 cac1 2307 000a 76a9 7660 .X..#...v.v`
0x0020: 5750 0700 1011 1213 WP..
0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 .!"#
0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123
The MTU of the I225 physical interface in OVS-DPDK is 1600. Decreasing it
to 1500 won't fix this issue.
Here are all the values configured on this interface:
root@OVP:~# ovs-vsctl list interface 1.myswitch
_uuid : b475c7c3-aec5-44ec-9cef-869079f8badf
admin_state : up
bfd : {}
bfd_status : {}
cfm_fault : []
cfm_fault_status: []
cfm_flap_count : []
cfm_health : []
cfm_mpid: []
cfm_remote_mpids: []
cfm_remote_opstate : []
duplex : []
error : []
external_ids: {}
ifindex : 11962937
ingress_policing_burst: 0
ingress_policing_rate: 0
lacp_current: []
link_resets : 1
link_speed : []
link_state : up
lldp: {}
mac : []
mac_in_use : "00:08:a2:12:15:e6"
mtu : 1600
mtu_request : 1600
name: "1.myswitch"
ofport : 1
ofport_request : []
options : {dpdk-devargs=":04:00.0"}
other_config: {}
statistics : {ovs_rx_qos_drops=0, ovs_tx_failure_drops=0,
ovs_tx_invalid_hwol_drops=0, ovs_tx_mtu_exceeded_drops=0,
ovs_tx_qos_drops=0, rx_128_to_255_packets=0, rx_1_to_64_packets=0,
rx_256_to_511_packets=0, rx_512_to_1023_packets=0, rx_65_to_127_packets=0,
rx_align_errors=0, rx_broadcast_packets=0, rx_bytes=0, rx_crc_errors=0,
rx_dropped=0, rx_errors=0, rx_fragment_errors=0, rx_jabber_errors=0,
rx_length_errors=0, rx_management_dropped=0, rx_management_packets=0,
rx_mbuf_allocation_errors=0, rx_missed_errors=0, rx_oversize_errors=0,
rx_packets=0, rx_q0_errors=0, rx_undersize_errors=0,
tx_128_to_255_packets=0, tx_1_to_64_packets=0, tx_256_to_511_packets=0,
tx_512_to_1023_packets=0, tx_65_to_127_packets=0, tx_broadcast_packets=0,
tx_bytes=0, tx_dropped=0, tx_errors=0, tx_management_packets=0,
tx_multicast_packets=0, tx_packets=0}
status : {driver_name=net_igc, if_descr="DPDK 20.11.0
net_igc", if_type="6", link_speed="2.5Gbps", max_hash_mac_addrs="0",
max_mac_addrs="16", max_rx_pktlen="1618", max_rx_queues="4",
max_tx_queues="4", max_vfs="0",
