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
