Thanks Dave, this really helped me (I used the pcap tx trace before but your
suggestion offers much more information).
Below is the info I got. It shows that the nsh-input gets wrong values and it
matches what I see with wireshark. However the ovs-dpctl dump-flows in
CLASSIFIER1 shows completely different information, as shown in previous mail.
It looks like OVS is not encoding the message correctly.
Packet 45
00:27:47:102658: dpdk-input
GigabitEthernet0/9/0 rx queue 0
buffer 0x426f: current data 0, length 162, free-list 0, totlen-nifb 0, trace
0x2c
PKT MBUF: port 0, nb_segs 1, pkt_len 162
buf_len 2176, data_len 162, ol_flags 0x0, data_off 128, phys_addr 0x746cf2c0
packet_type 0x0
IP4: 08:00:27:4c:70:10 -> 08:00:27:4c:70:20
UDP: 192.168.70.10 -> 192.168.70.20
tos 0x00, ttl 64, length 148, checksum 0x85b5
fragment id 0xa734, flags DONT_FRAGMENT
UDP: 33124 -> 4790
length 128, checksum 0x0000
00:27:47:102748: ethernet-input
IP4: 08:00:27:4c:70:10 -> 08:00:27:4c:70:20
00:27:47:102760: ip4-input
UDP: 192.168.70.10 -> 192.168.70.20
tos 0x00, ttl 64, length 148, checksum 0x85b5
fragment id 0xa734, flags DONT_FRAGMENT
UDP: 33124 -> 4790
length 128, checksum 0x0000
00:27:47:102763: ip4-lookup
fib 0 adj-idx 4 : 192.168.70.20/24 flow hash: 0x00000000
UDP: 192.168.70.10 -> 192.168.70.20
tos 0x00, ttl 64, length 148, checksum 0x85b5
fragment id 0xa734, flags DONT_FRAGMENT
UDP: 33124 -> 4790
length 128, checksum 0x0000
00:27:47:102767: ip4-local
UDP: 192.168.70.10 -> 192.168.70.20
tos 0x00, ttl 64, length 148, checksum 0x85b5
fragment id 0xa734, flags DONT_FRAGMENT
UDP: 33124 -> 4790
length 128, checksum 0x0000
00:27:47:102770: ip4-udp-lookup
UDP: src-port 33124 dst-port 4790
00:27:47:102774: vxlan4-gpe-input
VXLAN-GPE: no tunnel next 4 error 1
00:27:47:102778: nsh-input
nsh ver 0 len 0 (0 bytes) md_type 0 next_protocol 0
service path 15763460 service index 54
c1 -1257065167 c2 100683657 c3 769 c4 -1463746792
00:27:47:102789: error-drop
nsh-input: no mapping for nsh key
Thank you very much,
Best Regards,
Miguel Ángel Muñoz.
From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: viernes, 27 de enero de 2017 18:21
To: Miguel Angel Muñoz Gonzalez <miguel.angel.munoz.gonza...@ericsson.com>;
nsh_sfc-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: RE: Can't map NSH entry in VPP
Please see if vpp packet tracer will show you why the packets aren't behaving
as required...
For example:
Vpp# trace add dpdk-input 50
<send traffic>
Vpp# show trace
HTH... Thanks... Dave
P.S. you might need to specify a node other than dpdk-input if e.g. you're
using tap, af_packet, etc. other sorts of interfaces.
From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Miguel Angel Muñoz Gonzalez
Sent: Friday, January 27, 2017 11:34 AM
To: nsh_sfc-...@lists.fd.io<mailto:nsh_sfc-...@lists.fd.io>;
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] Can't map NSH entry in VPP
Hi everyone,
I'm working on a setup with group based policy, sfc and vpp. I am starting with
this setup:
+-----------------+
| Host (ODL SFC) |
| 192.168.60.1 |
+-----------------+
/ | | \
/ | | \
/ | | \
+---------------+ +--------------+ +--------------+ +---------------+
| classifier1 | | sff1 | | sff2 | | classifier2 |
| 192.168.60.10 | |192.168.60.20 | |192.168.60.50 | | 192.168.60.60 |
+---------------+ +--------------+ +--------------+ +---------------+
| |
| |
+---------------+ +--------------+
| sf1(DPI-1) | | sf2(FW-1) |
|192.168.60.30 | |192.168.60.40 |
+---------------+ +--------------+
In the Classifiers I am running OVS and VPP in the SFFs. My intention is to
have 4 endpoints in Classifier1 and 4 endpoints in Classifier 2 (similar to
gbp-sfc demo).
I can send out a packet from CLASSIFIER1 towards SFF1. However when it gets to
the SFF1 it cannot apply correctly the NSH rules to route it to the next step
(SF1).
As you can see, there is a packet going out from CLASSIFIER1 (with OVS):
vagrant@classifier1:~$ sudo ovs-dpctl dump-flows
recirc_id(0),in_port(4),eth(src=00:00:00:00:35:02,dst=88:f0:31:b5:12:b5),eth_type(0x0800),ipv4(src=10.0.35.2,dst=10.0.36.5,proto=6,tos=0/0x3,ttl=64,frag=no),
tcp(dst=80), packets:0, bytes:0, used:never,
actions:set(tunnel(tun_id=0x3,dst=192.168.70.20,ttl=64,tp_dst=4790,vxlan(gpe(np=0x4,flags=0)),flags(df|key))),
set(eth(src=88:f0:31:b5:12:b5,dst=00:00:00:00:36:05)),set(ipv4(src=10.0.35.2,dst=10.0.36.5,tos=0/0x3,ttl=63)),
push_nsh(encap_eth_src=88:f0:31:b5:12:b5,encap_eth_dst=00:00:00:00:36:05,encap_eth_type=0x894f,
nsh_mdtype=1,nsh_np=3,nsp=44,nsi=255,nshc1=3232250940,nshc2=3,nshc3=0,nshc4=0),2
However VPP in SFF1 cannot forward the packet and actually increases the nsh
error counter:
vagrant@sff1:~$ sudo vppctl show error
Count Node Reason
573 nsh-input no mapping for nsh key
12 ip6-input ip6 source lookup miss
3 ip6-icmp-input neighbor solicitations for
unknown targets
18 ip6-icmp-input neighbor discovery not
configured
104 arp-input ARP replies sent
6 arp-input ARP replies received
And I cannot find the fault since the entries in nsh for VPP in SFF1 seem to be
correct:
vagrant@sff1:~$ sudo vppctl show nsh map
nsh entry nsp: 44 nsi: 255 maps to nsp: 44 nsi: 255 encapped by VXLAN GPE intf:
2
nsh entry nsp: 44 nsi: 254 maps to nsp: 44 nsi: 254 encapped by VXLAN GPE intf:
3
nsh entry nsp: 8388652 nsi: 254 maps to nsp: 8388652 nsi: 254 encapped by VXLAN
GPE intf: 2
nsh entry nsp: 8388652 nsi: 253 maps to nsp: 8388652 nsi: 253 encapped by VXLAN
GPE intf: 4
vagrant@sff1:~$ sudo vppctl show nsh entry
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
service path 44 service index 255
c1 0 c2 0 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
service path 44 service index 254
c1 0 c2 0 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
service path 8388652 service index 254
c1 0 c2 0 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
service path 8388652 service index 253
c1 1 c2 9 c3 3 c4 4
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
service path 45 service index 255
c1 -1062716356 c2 3 c3 0 c4 0
nsh ver 0 len 6 (24 bytes) md_type 1 next_protocol 3
service path 44 service index 250
c1 -1062716356 c2 3 c3 0 c4 0
vagrant@sff1:~$
The only reason I can think of is that c1,c2,c3 and c4 are not 0,0,0,0 (as
shown in the nsh entries). But these fields are not part of the nsh key that is
used to find the proper nsh rule, are they?
I would appreciate if someone could provide a hint about the problem.
Thank you very much,
Best Regards,
Miguel Ángel Muñoz.
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
