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] On Behalf Of Miguel Angel Muñoz Gonzalez Sent: Friday, January 27, 2017 11:34 AM To: nsh_sfc-...@lists.fd.io; 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
