Re: [vpp-dev] vxlan setup guidance
I had manually set flags=0x8 to get scapy + vpp to work correctly also. Might be something to fix in Scapy and upstream? Ray K On 09/12/2016 19:34, Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco) wrote: My understanding is, if is VXLAN then UDP destination port is 4789 and must have set I bit to 1. If is frame encapsulated into VXLAN GPE then UDP destination port is 4790 and must have set I and P bits (probably some others too). The RFCs also defines that if is received wrong bit set it should be ignored. ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] vxlan setup guidance
https://jira.fd.io/browse/VPP-553
From: Dave Barach (dbarach)
Sent: 9. decembra 2016 15:09
To: Matej Klotton -X (mklotton - PANTHEON TECHNOLOGIES at Cisco)
<mklot...@cisco.com>
Subject: RE: [vpp-dev] vxlan setup guidance
Please do; assign it to John Lo...
Thanks... Dave
From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Matej Klotton -X (mklotton -
PANTHEON TECHNOLOGIES at Cisco)
Sent: Friday, December 9, 2016 9:03 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] vxlan setup guidance
Hi,
I've noticed, new scapy uses different flag value than older, it uses 0xc
instead 0x8 which is required by VPP.
#define VXLAN_FLAGS_I 0x08
if (PREDICT_FALSE (vxlan0->flags != VXLAN_FLAGS_I))
{
error0 = VXLAN_ERROR_BAD_FLAGS;
next0 = VXLAN_INPUT_NEXT_DROP;
goto trace0;
}
However RFC https://tools.ietf.org/html/rfc7348#section-5 says that received
reserved bits must be ignored.
Should I open a Jira ticket for this issue?
Regards,
Matej
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] vxlan setup guidance
Hi,
I've noticed, new scapy uses different flag value than older, it uses 0xc
instead 0x8 which is required by VPP.
#define VXLAN_FLAGS_I 0x08
if (PREDICT_FALSE (vxlan0->flags != VXLAN_FLAGS_I))
{
error0 = VXLAN_ERROR_BAD_FLAGS;
next0 = VXLAN_INPUT_NEXT_DROP;
goto trace0;
}
However RFC https://tools.ietf.org/html/rfc7348#section-5 says that received
reserved bits must be ignored.
Should I open a Jira ticket for this issue?
Regards,
Matej
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] vxlan setup guidance
VPP is complaining that a tunnel for vni 42 does not exist, when clearly it does. I would have thought my simple set up below, would allow packets to find their way through the tunnel to 192.168.1.3. I am definitely doing something wrong. Ray K Packet 2 00:00:19:676348: af-packet-input af_packet: hw_if_index 1 next-index 3 tpacket2_hdr: status 0x2001 len 84 snaplen 84 mac 66 net 80 sec 0x58418737 nsec 0x37c99699 vlan 0 00:00:19:679815: ethernet-input IP4: 00:17:3e:37:19:89 -> 02:fe:16:35:df:49 00:00:19:679851: ip4-input UDP: 172.16.1.2 -> 172.16.1.3 tos 0x00, ttl 64, length 70, checksum 0x2081 fragment id 0x0001 UDP: 1337 -> 4789 length 50, checksum 0xd6ca 00:00:19:679886: ip4-lookup fib 0 dpo-idx 5 flow hash: 0x UDP: 172.16.1.2 -> 172.16.1.3 tos 0x00, ttl 64, length 70, checksum 0x2081 fragment id 0x0001 UDP: 1337 -> 4789 length 50, checksum 0xd6ca 00:00:19:679938: ip4-local UDP: 172.16.1.2 -> 172.16.1.3 tos 0x00, ttl 64, length 70, checksum 0x2081 fragment id 0x0001 UDP: 1337 -> 4789 length 50, checksum 0xd6ca 00:00:19:679975: ip4-udp-lookup UDP: src-port 1337 dst-port 4789 00:00:19:679996: vxlan4-input VXLAN decap error - tunnel for vni 42 does not exist 00:00:19:680008: error-drop vxlan4-input: packets with bad flags field in vxlan header DBGvpp# show vxlan tunnel [0] src 172.16.1.3 dst 172.16.1.2 vni 42 encap_fib_index 1 sw_if_index 3 fib_entry_index 20 - setup - create host-interface name veth_link1 set interface ip address host-veth_link1 172.16.1.3/24 set interface state host-veth_link1 up create loopback interface set interface ip table loop0 7 set interface ip address loop0 192.168.1.3/24 create vxlan tunnel src 172.16.1.3 dst 172.16.1.2 vni 42 encap-vrf-id 7 decap-next l2 set interface state vxlan_tunnel0 up set interface state loop0 up trace add af-packet-input 50 --- >-Original Message- >From: Neale Ranns (nranns) [mailto:nra...@cisco.com] >Sent: Thursday, December 1, 2016 7:11 PM >To: Kinsella, Ray <ray.kinse...@intel.com>; John Lo (loj) <l...@cisco.com>; >Keith >Burns (krb) <k...@cisco.com>; Dave Barach (dbarach) <dbar...@cisco.com> >Cc: vpp-dev@lists.fd.io >Subject: Re: [vpp-dev] vxlan setup guidance > > >Hi Ray, > >An observation inline... > > > >On 01/12/2016, 18:23, "vpp-dev-boun...@lists.fd.io on behalf of Kinsella, Ray" ><vpp-dev-boun...@lists.fd.io on behalf of ray.kinse...@intel.com> wrote: > >>Guys, >> >>I am struggling with VXLan setup with VPP. >>On Linux it's no problem ... >> >>Container 1 >> sudo ip addr add 172.16.1.2/24 dev veth_link1 >> sudo ip link set dev veth_link1 up >> sudo ip link add vxlan0 type vxlan id 42 remote 172.16.1.3 dev >> veth_link1 >> sudo ip addr add 192.168.1.2 dev vxlan0 >> sudo ip link set dev vxlan0 up >> >>Container 2 >> sudo ip addr add 172.16.1.3/24 dev veth_link1 >> sudo ip link set dev veth_link1 up >> sudo ip link add vxlan0 type vxlan id 42 remote 172.16.1.2 dev >> veth_link1 >> sudo ip addr add 192.168.1.3 dev vxlan0 >> sudo ip link set dev vxlan0 up >> >>Container 1 and 2 are connected on the host with a VPP l2 bridge. >>All works fine I can ping from between 172.16.1.2 and 172.16.1.3, 192.168.1.2 >and 192.168.1.3. >> >>However when I reconfigure Container 2 to use VPP, as follows. >>(delete vxlan0, ip assignments to Linux before I start). >> >> create host-interface name veth_link1 >> set interface ip address host-veth_link1 172.16.1.3/24 >> set interface state host-veth_link1 up >> >>At this point, I can ping between 172.16.1.2 and 172.16.1.3. >>Still all works fine ... I then create the vxlan tunnel and then bridge >> >> create vxlan tunnel src 172.16.1.3 dst 172.16.1.2 vni 42 >> set interface l2 bridge host-veth_link1 100 > >Here you added the underlay link into the VxLAN overlay bridge-domain, so the >underlay IP traffic is bridged. Remove this and I expect it will work. > > >/neale > > >> set interface l2 bridge vxlan_tunnel0 100 >> >>However when after I create the vxlan tunnel and add it to the a bridge. >>Pings in 172.16.1.0/24 stop and I get the following >> >>vagrant@ctwo:~$ sudo tcpdump -i veth_link1 -n >>tcpdump: WARNING: veth_link1: no IPv4 address assigned >>tcpdump: verbose output suppressed, use -v or -vv for full protocol >>decode listening on veth_link1, link-type EN10MB (Ethernet), capture >>size 65535 bytes >>18:14:31
[vpp-dev] vxlan setup guidance
Guys, I am struggling with VXLan setup with VPP. On Linux it's no problem ... Container 1 sudo ip addr add 172.16.1.2/24 dev veth_link1 sudo ip link set dev veth_link1 up sudo ip link add vxlan0 type vxlan id 42 remote 172.16.1.3 dev veth_link1 sudo ip addr add 192.168.1.2 dev vxlan0 sudo ip link set dev vxlan0 up Container 2 sudo ip addr add 172.16.1.3/24 dev veth_link1 sudo ip link set dev veth_link1 up sudo ip link add vxlan0 type vxlan id 42 remote 172.16.1.2 dev veth_link1 sudo ip addr add 192.168.1.3 dev vxlan0 sudo ip link set dev vxlan0 up Container 1 and 2 are connected on the host with a VPP l2 bridge. All works fine I can ping from between 172.16.1.2 and 172.16.1.3, 192.168.1.2 and 192.168.1.3. However when I reconfigure Container 2 to use VPP, as follows. (delete vxlan0, ip assignments to Linux before I start). create host-interface name veth_link1 set interface ip address host-veth_link1 172.16.1.3/24 set interface state host-veth_link1 up At this point, I can ping between 172.16.1.2 and 172.16.1.3. Still all works fine ... I then create the vxlan tunnel and then bridge create vxlan tunnel src 172.16.1.3 dst 172.16.1.2 vni 42 set interface l2 bridge host-veth_link1 100 set interface l2 bridge vxlan_tunnel0 100 However when after I create the vxlan tunnel and add it to the a bridge. Pings in 172.16.1.0/24 stop and I get the following vagrant@ctwo:~$ sudo tcpdump -i veth_link1 -n tcpdump: WARNING: veth_link1: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on veth_link1, link-type EN10MB (Ethernet), capture size 65535 bytes 18:14:31.942718 ARP, Request who-has 172.16.1.3 tell 172.16.1.2, length 28 18:14:31.943169 IP 172.16.1.3.28173 > 172.16.1.2.4789: VXLAN, flags [I] (0x08), vni 42 ARP, Request who-has 172.16.1.3 tell 172.16.1.2, length 28 18:14:32.940710 ARP, Request who-has 172.16.1.3 tell 172.16.1.2, length 28 18:14:32.941011 IP 172.16.1.3.28173 > 172.16.1.2.4789: VXLAN, flags [I] (0x08), vni 42 ARP, Request who-has 172.16.1.3 tell 172.16.1.2, length 28 Container 2's ICMP requests for who has 172.16.1.2, are getting encapsulated as VXLAN. So Container 1 never responds as owning 172.16.1.2. 172.16.1.2 and 172.16.1.3 should be my VTEPs. I should be able to ping back and forth between them without encapsulation. Suspect I am making a simple mistake in my setup, can someone provide guidance. Ray K ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
