The last sentence of my last reply is not correct: >If you want to setup loop0 as default gateway for vrf 1, it should be set as >"ip route add table 1 0.0.0.0/0 via 10.0.0.1".
We cannot use IP address of the local BVI (or any local interfaces) as the default gateway. The default gateway should have an IP address in one of the neighbor subnets. So, if the default gateway is reachable in the BD via the its BVI loop0, you need to use the default gateway IP which is likely the IP address (in the 10.10.0.0/24 subnet) of a remote BVI in a remote BD. This kind of config for default gateway is pretty unusual. There will usually be a particular remote BVI which can reach a particular subnet. Regards, John -----Original Message----- From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of John Lo (loj) Sent: Thursday, November 03, 2016 3:10 PM To: Ivan Kelly Cc: vpp-dev Subject: Re: [vpp-dev] ip4-lookup to vxlan and vice versa Hi Ivan, The current behavior as shown in your trace is not correct due to the route configuration which is not a valid one and loop0 does not even have an IP address assigned. It results in an adjacency without a rewrite string unless you specified one. Thus packets got into the BD without any L2 header where the IP header is being interpreted as MAC header and the packet was flooded to all ports in the BD including VXLAN tunnel. I am pretty sure this kind of config will not be accepted with the new FIB where config validity check is more strict. The correct config is to set loop0 to ip table1 "set interface ip table loop0 1"and assign a proper IP address/mask, like "set interface ip address loop0 10.0.0.1/24". Then packets with DIP of 10.0.0.x will be forwarded into the BD properly with ARP to resolve the MAC and then proper L2 header rewrite. If you want to setup loop0 as default gateway for vrf 1, it should be set as "ip route add table 1 0.0.0.0/0 via 10.0.0.1". Regards, John -----Original Message----- From: Ivan Kelly [mailto:i...@midokura.com] Sent: Thursday, November 03, 2016 2:30 PM To: John Lo (loj) Cc: vpp-dev Subject: Re: [vpp-dev] ip4-lookup to vxlan and vice versa Hi John, > VXLAN tunnel is usually associated with a BD (bridge domain) and always send > ethernet packets as payload. So ethernet header should exist on packets > received at the remote VXLAN tunnel end point. It is confusing why you stated > remote side OVS does not see any L2 header. I guess it doesn't see it, because it's not there. The route is configured as "ip route add table 1 0.0.0.0/0 via loop0", so there is no rewrite data, and the buffer has been advanced past the ethernet header before going to ip lookup, so when the VxLan is added, along with it's L3 & L2, it's added where the encapsulated L2 would have been. > On VPP side, as packet with DIP of 10.0.0.x is sent from vrf 1 via BVI into > BD 13, an ARP request will be sent within BD 13 to request resolution for the > IP 10.0.0.x. Once MAC is resolved (say MAC-D), then the packets as sent in BD > 13 over VXLAN tunnel should have an Ethernet header with DMAC as MAC-D and > SMAC as that of the BVI MAC. I don't see this ARP occurring. Rather the packet drops straight down through the BVI into vxlan and gets sent out. I've attached a trace, and the command listing I used to set up the example (vpp-vxlan.sh sets up the namespaces, then vpp.txt sets up vpp. ping 192.168.0.1 from netns ip4). > The most common way to tunnel IP4 payload into straight ip4-lookup is to use > GRE tunnel. VXLAN is designed for L2 bridging, to send Ethernet packets to > remote hosts with BDs in the same VXLAN segment. Regarding using VXLAN tunnel > to send IP payload straight into ip4-lookup, you can look into VXLAN-GPE > tunnel where there is mechanism to specify the VXLAN payload type via a > protocol field in the VXLAN-GPE header to be ethernet, IP4, IP6, ... etc. The thing is, I need the encapsulated L2 also, so VXLAN-GPE isn't what I want. I have a working solution, by manually adding rewrite data to the adjacency. It'd just be nice to have something a little more symmetrical. -Ivan _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
