Re: [ovs-discuss] Problem openvswitch, openwrt e dhcp
On 07/23/2018 04:45 PM, Thomas William wrote: controller ---> normal switch --> ap with openvswitch and openwrt -->server1 When I configure the eth0.2 interface on the openvswitch I lose the ip assigned by the external dhcp, and I can not recover, I've already tried to assign static but did not work for the controller accessing it remotely. I am not familiar with openwrt config, and if you installed ovs as an add-on, there is an interaction which may not work with out some custom changes with hostapd (the wireless side of things). I have wireless working with the changes discussed at: http://blog.raymond.burkholder.net/index.php?/archives/762-Using-Quilt-to-Patch-a-Debian-Package.html Your mileage may vary with your situation. I do not know how to configure in openwrt for the eth0.2 interface to work on both openvswitch and remote access. -- Raymond Burkholder r...@oneunified.net https://blog.raymond.burkholder.net ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Problem openvswitch, openwrt e dhcp
I searched all over the internet, but I can not solve the problem. My settings are below: controller ---> normal switch --> ap with openvswitch and openwrt -->server1 normal switch --> dhcp When I configure the eth0.2 interface on the openvswitch I lose the ip assigned by the external dhcp, and I can not recover, I've already tried to assign static but did not work for the controller accessing it remotely. I do not know how to configure in openwrt for the eth0.2 interface to work on both openvswitch and remote access. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] bugs in script which is not creating openvswitch-switch
A 'make install' does not install the startup script. You can copy it over manually. E.g : cp debian/openvswitch-switch.init /etc/init.d/openvswitch-switch On 23 July 2018 at 01:23, Vikas Kumar wrote: > hi Team, > i was trying to restart the openvswitch daemon using the below script: > /etc/init.d/openvswitch-switch, i have download 2.9.0 version of ovs > source code. after building the source code using below commads: > ./boot.sh > ./configure > make > make install > > but, i got an error, saying no such script /etc/init.d/openvswitch-switch > found. could any one tell what is the problem? > > Thanks > Vikash > > ___ > 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] bugs in script which is not creating openvswitch-switch
hi Team, i was trying to restart the openvswitch daemon using the below script: /etc/init.d/openvswitch-switch, i have download 2.9.0 version of ovs source code. after building the source code using below commads: ./boot.sh ./configure make make install but, i got an error, saying no such script /etc/init.d/openvswitch-switch found. could any one tell what is the problem? Thanks Vikash ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN - VLAN packet duplicate processing on egress pipeline
On Mon, Jul 23, 2018 at 6:30 PM, Mark Michelson wrote: > On 07/23/2018 08:03 AM, Anil Venkata wrote: > >> Packets destined for VLAN remote logical ports are sent out through >> physical table 65 rather than physical table 32 (Geneve remote logical >> ports are sent through table 32). I found below description in ovn >> architecture documentation. >> >> http://www.openvswitch.org//support/dist-docs/ovn-architecture.7.html >> >> A special case is that when a localnet port exists on the >> datapath, remote port is connected by switching to the local‐ >> net port. In this case, instead of adding a flow in table 32 >> to reach the remote port, a flow is added in table 33 to >> switch the logical outport to the localnet port, and resubmit >> to table 33 as if it were unicasted to a logical port on the >> local hypervisor. >> >> >> Any reason for this decision. Because of this, packet is redundantly >> processed in logical switch's egress pipeline on both local and remote >> hypervisors. >> > > Keep in mind that from OVN's perspective, a localnet port represents a > local exit from the logical switch. It doesn't know if the packet will end > up back in br-int again on another hypervisor. It would be equally valid > for the packet to be modified by a separate OVS switch and sent out of the > underlay network entirely once it has gone out the localnet port. Thanks Mark. Agree, tunnelled packet can only be decapsulated by br-int on remote hypervisor. But in case of VLAN packet any one can process it. But I don't see stages (and tables) in egress pipeline checking against this localnet port (but I can see checks for other localports). If the remote port is not a ovs br-int port on other chassis, then why do we need to apply ACL? Thus if it does not go through the egress pipeline of the local hypervisor, > there is the chance that it will not go through the egress pipeline of the > logical switch at all. > > There are potential ways that we could get around this redundant > processing. However, before suggesting anything concrete or actually > proposing that anything actually should be done, I'll echo Russell's > question about whether this is actually causing a noticeable problem. > > Miguel found the issue 1) described in [1] while reviewing the patch [2]. As a solution we wanted to have gateway MAC address as reply packet source MAC address when the packet is travelling from gateway node to compute node so that external physical switches can update their FDB. To implement this solution 1) Router pipeline in gateway node will set packet MAC address to gateway MAC address and then submit to VLAN switch pipeline. 2) VLAN switch pipeline should replace this with router internal port MAC address before delivering to VM. I want to add below flow in physical table 33 local VM ports for replacing MAC address table=33, priority= metadata=,dl_dst= actions=mod_dl_dst:,resubmit(,33) But VLAN switch pipeline can process the above generic flow for remote port, thus packet while leaving the gateway node will have router internal port MAC address. As a work around I can add a new flow which checks MAC address for each port i.e (but I prefer the above generic flow in table 33) table=33, priority= metadata=,dl_dst=,*outport=* actions=mod_dl_dst:,resubmit(,33) Before that I wanted to understand why we are differentiating VLAN networks( i.e processing differently in table 32 and 33) ? [1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/349803.html [2] https://patchwork.ozlabs.org/patch/934524/ > >> Thanks >> Anil >> >> >> >> >> ___ >> 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 - VLAN packet duplicate processing on egress pipeline
On 07/23/2018 08:03 AM, Anil Venkata wrote: Packets destined for VLAN remote logical ports are sent out through physical table 65 rather than physical table 32 (Geneve remote logical ports are sent through table 32). I found below description in ovn architecture documentation. http://www.openvswitch.org//support/dist-docs/ovn-architecture.7.html A special case is that when a localnet port exists on the datapath, remote port is connected by switching to the local‐ net port. In this case, instead of adding a flow in table 32 to reach the remote port, a flow is added in table 33 to switch the logical outport to the localnet port, and resubmit to table 33 as if it were unicasted to a logical port on the local hypervisor. Any reason for this decision. Because of this, packet is redundantly processed in logical switch's egress pipeline on both local and remote hypervisors. Keep in mind that from OVN's perspective, a localnet port represents a local exit from the logical switch. It doesn't know if the packet will end up back in br-int again on another hypervisor. It would be equally valid for the packet to be modified by a separate OVS switch and sent out of the underlay network entirely once it has gone out the localnet port. Thus if it does not go through the egress pipeline of the local hypervisor, there is the chance that it will not go through the egress pipeline of the logical switch at all. There are potential ways that we could get around this redundant processing. However, before suggesting anything concrete or actually proposing that anything actually should be done, I'll echo Russell's question about whether this is actually causing a noticeable problem. Thanks Anil ___ 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 - VLAN packet duplicate processing on egress pipeline
On Mon, Jul 23, 2018 at 8:06 AM Anil Venkata wrote: > > Packets destined for VLAN remote logical ports are sent out through physical > table 65 rather than physical table 32 (Geneve remote logical ports are sent > through table 32). I found below description in ovn architecture > documentation. > > http://www.openvswitch.org//support/dist-docs/ovn-architecture.7.html > > A special case is that when a localnet port exists on the > datapath, remote port is connected by switching to the local‐ > net port. In this case, instead of adding a flow in table 32 > to reach the remote port, a flow is added in table 33 to > switch the logical outport to the localnet port, and resubmit > to table 33 as if it were unicasted to a logical port on the > local hypervisor. > > > Any reason for this decision. Because of this, packet is redundantly > processed in logical switch's egress pipeline on both local and remote > hypervisors. Have you identified a problem caused by this behavior? Thanks, Russell Bryant ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] OVN - VLAN packet duplicate processing on egress pipeline
Packets destined for VLAN remote logical ports are sent out through physical table 65 rather than physical table 32 (Geneve remote logical ports are sent through table 32). I found below description in ovn architecture documentation. http://www.openvswitch.org//support/dist-docs/ovn-architecture.7.html A special case is that when a localnet port exists on the datapath, remote port is connected by switching to the local‐ net port. In this case, instead of adding a flow in table 32 to reach the remote port, a flow is added in table 33 to switch the logical outport to the localnet port, and resubmit to table 33 as if it were unicasted to a logical port on the local hypervisor. Any reason for this decision. Because of this, packet is redundantly processed in logical switch's egress pipeline on both local and remote hypervisors. Thanks Anil ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] VXLAN connectivity problem
Hey all,
i built following environment:
both hosts:
Operating System: CentOS Linux 7 (Core)
Kernel: Linux 3.10.0-862.6.3.el7.x86_64
Architecture: x86-64
ovs-host 1 with the local ip of 10.1.247.123
2 physical ports: eth0 and eth1
-eth0 is connected to an ip-network (network is in a vlan) with connectivity to
the internet (isp)
-eth1 is connected to a switch and on this switch there is a device (centos7)
machine
i installed ovs version 2.9.2 on the host to use vxlan tunneling over the
isp-network
host1 interfaces:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP
group default qlen 1000
link/ether 70:71:bc:62:d6:38 brd ff:ff:ff:ff:ff:ff
inet 10.1.247.117/24 brd 10.1.247.255 scope global dynamic eth0
valid_lft 1192219sec preferred_lft 1192219sec
inet6 fe80::7271:bcff:fe62:d638/64 scope link
valid_lft forever preferred_lft forever
3: eth1: mtu 1500 qdisc mq master ovs-system
state UP group
default qlen 1000
link/ether 00:10:18:2b:a7:90 brd ff:ff:ff:ff:ff:ff
inet6 fe80::210:18ff:fe2b:a790/64 scope link
valid_lft forever preferred_lft forever
4: ovs-system: mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether ea:ec:ff:79:00:8f brd ff:ff:ff:ff:ff:ff
5: bridge1: mtu 1500 qdisc noqueue state
UNKNOWN group default
qlen 1000
link/ether 00:10:18:2b:a7:90 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.35/24 brd 192.168.0.255 scope global bridge1
valid_lft forever preferred_lft forever
inet6 fe80::210:18ff:fe2b:a790/64 scope link
valid_lft forever preferred_lft forever
6: vxlan_sys_4789: mtu 65000 qdisc noqueue
master ovs-system
state UNKNOWN group default qlen 1000
link/ether 46:ce:7a:80:34:e9 brd ff:ff:ff:ff:ff:ff
inet6 fe80::44ce:7aff:fe80:34e9/64 scope link
valid_lft forever preferred_lft forever
host 1 ovs-output:
# ovs-vsctl show
15b312e1-50d3-4670-9783-2ff89dd7645e
Bridge "bridge1"
Port "eth1"
Interface "eth1"
Port "bridge1"
Interface "bridge1"
type: internal
Port "vxlan0"
Interface "vxlan0"
type: vxlan
options: {local_ip="10.1.247.117", remote_ip="10.1.247.123"}
ovs_version: "2.9.2"
this setup is mirrored to the other side of the isp-network
host2 interface:
# ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether 00:1a:64:20:5f:b5 brd ff:ff:ff:ff:ff:ff
inet 10.1.247.123/24 brd 10.1.247.255 scope global dynamic eth0
valid_lft 1191064sec preferred_lft 1191064sec
inet6 fe80::21a:64ff:fe20:5fb5/64 scope link
valid_lft forever preferred_lft forever
3: eth1: mtu 1500 qdisc mq master ovs-system
state UP group
default qlen 1000
link/ether 00:1a:64:20:5f:b6 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21a:64ff:fe20:5fb6/64 scope link
valid_lft forever preferred_lft forever
4: eth2: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 90:e2:ba:49:1c:cc brd ff:ff:ff:ff:ff:ff
5: eth3: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 90:e2:ba:49:1c:cd brd ff:ff:ff:ff:ff:ff
6: eth4: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 90:e2:ba:49:1c:ce brd ff:ff:ff:ff:ff:ff
7: eth5: mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether 90:e2:ba:49:1c:cf brd ff:ff:ff:ff:ff:ff
8: ovs-system: mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 12:ea:06:d9:3b:de brd ff:ff:ff:ff:ff:ff
9: bridge1: mtu 1500 qdisc noqueue state
UNKNOWN group default
qlen 1000
link/ether 00:1a:64:20:5f:b6 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global bridge1
valid_lft forever preferred_lft forever
inet6 fe80::21a:64ff:fe20:5fb6/64 scope link
valid_lft forever preferred_lft forever
11: vxlan_sys_4789: mtu 65000 qdisc noqueue
master ovs-system
state UNKNOWN group default qlen 1000
link/ether 5e:38:af:9a:f4:e2 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5c38:afff:fe9a:f4e2/64 scope link
valid_lft forever preferred_lft forever
host2 ovs output:
# ovs-vsctl show
da282d04-5f50-43c5-89c4-19a7db4e99f7
Bridge "bridge1"
Port "vxlan0"
Interface "vxlan0"
type: vxlan
options: {local_ip="10.1.247.123", remote_ip="10.1.247.117"}
Port "eth1"
Interface "eth1"
Port "bridge1"
Interface
