Thanks all for clarification, now I understand the mechanism.
So, I will leave the work to a central controller to setup the unicast tunnel
between the vtep pairs.
-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of John Lo (loj) via
Lists.Fd.Io
Sent: Tuesday, November 06, 2018 12:24 AM
To: Neale Ranns (nranns) <nra...@cisco.com>; Hu, Xuekun <xuekun...@intel.com>;
Eyal Bari (ebari) <eb...@cisco.com>; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Problem on VxLAN multicast mode
To answer another question from Xuekun about usage of VXLAN mcast tunnel, the
advantage is that flooding to remote VTEPs only needs to send one packet into
the mcast tunnel. If there is no mcast tunnel, VPP will need to send a packet
per unicast VXLAN tunnel to flood all remote VTEPs. -John
-----Original Message-----
From: Neale Ranns (nranns)
Sent: Monday, November 05, 2018 11:00 AM
To: John Lo (loj) <l...@cisco.com>; Xuekun <xuekun...@intel.com>; Eyal Bari
(ebari) <eb...@cisco.com>; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Problem on VxLAN multicast mode
Hi Eyal, John,
I missed the fact that the tunnel classification is based only on the senders
IP. Now it makes sense.
Thanks,
Neale
-----Message d'origine-----
De : <vpp-dev@lists.fd.io> au nom de "John Lo (loj) via Lists.Fd.Io"
<loj=cisco....@lists.fd.io> Répondre à : "John Lo (loj)" <l...@cisco.com> Date
: lundi 5 novembre 2018 à 16:17 À : Xuekun <xuekun...@intel.com>, "Eyal Bari
(ebari)" <eb...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Cc :
"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Objet : Re: [vpp-dev] Problem on
VxLAN multicast mode
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 (#11115): https://lists.fd.io/g/vpp-dev/message/11115
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]
-=-=-=-=-=-=-=-=-=-=-=-
