VPP does not support receiving of VXLAN packets from an unknown VTEP. Thus,
any packet received in a BD from a VXLAN multicast tunnel must have its source
IP match of the remote VTEP of an existing VXLAN unicast tunnel in the same BD.
If no such unicast tunnel is found, packets are dropped. If it is found and
MAC learning is enabled, the MAC will be learned with its output associated
with the matching unicast VXLAN tunnel. VPP does not learn unknown remote
VTEPs and create a unicast tunnel automatically for better security.
Regards,
John
-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Xuekun
Sent: Monday, November 05, 2018 8:07 AM
To: Eyal Bari (ebari) <eb...@cisco.com>; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Problem on VxLAN multicast mode
Hi, Eyal
If need to create a unicast tunnel also, it means need to know the remote vtep
address first. However the purpose of using mcast tunnel is to build tunnels
across multiple vtep addresses which don't be known in advance. For example,
if there is a third server (server3: 192.168.1.3) in my env, what should I do?
Still add a unicast tunnel ("create vxlan tunnel src 172.168.1.1 dst
172.168.1.3 vni 100"), if so, just to setup the point-to-point vxlan tunnel and
put all the tunnels in the same BD, then all servers are connected, and don't
need to create the mcast tunnel.
Is my understanding about mcast tunnel not correct?
Thanks.
Thx, Xuekun
-----Original Message-----
From: Eyal Bari (ebari) <eb...@cisco.com>
Sent: Monday, November 05, 2018 7:58 PM
To: Hu, Xuekun <xuekun...@intel.com>; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Problem on VxLAN multicast mode
Just to clarify, the mcast tunnel does not need to be under the bridge for
receiving traffic, however for sending flooded traffic through the mcast tunnel
it needs to be under the bridge...
eyal
On 05/11/2018, 13:47, "vpp-dev@lists.fd.io on behalf of eyal bari via
Lists.Fd.Io" <vpp-dev@lists.fd.io on behalf of ebari=cisco....@lists.fd.io>
wrote:
Hi, Xuekun,
Packets are only received on unicast tunnels.
So in your case you would need to create one and put it under the
bridge-domain (the multicast tunnel does not need to be under the
bridge-domain):
create vxlan tunnel src 172.168.1.1 dst 172.168.1.2 vni 100
set interface l2 bridge vxlan_tunnel0 1000
create vxlan tunnel src 172.168.1.1 group 239.1.1.1
TenGigabitEthernet3d/0/1 vni 100
....
eyal
On 05/11/2018, 9:18, "vpp-dev@lists.fd.io on behalf of Xuekun"
<vpp-dev@lists.fd.io on behalf of xuekun...@intel.com> wrote:
Hi, All
I'm configuring VPP as VxLAN multicast mode over multiple servers. To
simplify the topology, I only used two servers: server1 as VPP; server2 using
vxlan kernel mode.
Server1:
set interface state TenGigabitEthernet3d/0/1 up
set interface ip address TenGigabitEthernet3d/0/1 172.168.1.1/24
create bridge-domain 1000 learn 1 forward 1 uu-flood 1 flood 1 arp-term 0
create vxlan tunnel src 172.168.1.1 group 239.1.1.1
TenGigabitEthernet3d/0/1 vni 100
set interface l2 bridge vxlan_tunnel0 1000
loopback create
set interface l2 bridge loop0 1000 bvi
set interface state loop0 up
set interface ip address loop0 192.168.1.1/24
Server2:
ifconfig enp11s0f1 172.168.1.2/24 up
ip link add vxlan0 type vxlan id 100 dstport 4789 group 239.1.1.1 dev
enp11s0f1
ifconfig vxlan0 192.168.1.2/24 up
Now, server1 and server2 are connected with VxLAN VNI 100 through
multicast group 239.1.1.1.
However, 192.168.1.1 and 192.168.1.2 could NOT be pingable each other.
Trace log:
Packet 1
00:01:02:563831: dpdk-input
TenGigabitEthernet3d/0/1 rx queue 0
buffer 0x4b93: current data 14, length 78, free-list 0, clone-count
0, totlen-nifb 0, trace 0x0
ext-hdr-valid
l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
PKT MBUF: port 0, nb_segs 1, pkt_len 92
buf_len 2176, data_len 92, ol_flags 0x180, data_off 128, phys_addr
0x4012e540
packet_type 0x291 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or
without extension headers
RTE_PTYPE_L4_UDP (0x0200) UDP packet
IP4: 00:1e:67:34:31:6c -> 01:00:5e:01:01:01
UDP: 172.168.1.2 -> 239.1.1.1
tos 0x00, ttl 1, length 78, checksum 0xe04b
fragment id 0x3ba7
UDP: 54420 -> 4789
length 58, checksum 0x0000
00:01:02:563834: ip4-input-no-checksum
UDP: 172.168.1.2 -> 239.1.1.1
tos 0x00, ttl 1, length 78, checksum 0xe04b
fragment id 0x3ba7
UDP: 54420 -> 4789
length 58, checksum 0x0000
00:01:02:563839: ip4-mfib-forward-lookup
fib 0 entry 6
00:01:02:563842: ip4-mfib-forward-rpf
entry 6 itf 1 flags Accept,
00:01:02:563842: ip4-replicate
replicate: 4 via [@1]: dpo-receive
00:01:02:563843: ip4-local
UDP: 172.168.1.2 -> 239.1.1.1
tos 0x00, ttl 1, length 78, checksum 0xe04b
fragment id 0x3ba7
UDP: 54420 -> 4789
length 58, checksum 0x0000
00:01:02:563846: ip4-udp-lookup
UDP: src-port 54420 dst-port 4789
00:01:02:563847: vxlan4-input
VXLAN decap error - tunnel for vni 100 does not exist
00:01:02:563847: error-drop
vxlan4-input: no such tunnel packets
Why it said "tunnel for vni 100 does not exist"?
Any help is appreciated.
Thx, Xuekun
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11104): https://lists.fd.io/g/vpp-dev/message/11104
Mute This Topic: https://lists.fd.io/mt/27856725/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
