> -----Original Message----- > From: Neale Ranns (nranns) > Sent: Wednesday, October 12, 2016 10:26 AM > To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) > <matfa...@cisco.com>; Zdenko Olsovsky -X (zolsovsk - PANTHEON > TECHNOLOGIES at Cisco) <zolso...@cisco.com>; vpp-dev@lists.fd.io > Cc: csit-...@lists.fd.io > Subject: Re: [csit-dev] [vpp-dev] Cannot add route to ipsec0 interface > > > > On 12/10/16 09:16, Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at > Cisco) > wrote: > > > > > IPSec tunnel interface is associated with SA, it is similar to > > ipsec-gre interface. Functionality is equivalent to IPSec as in/out > > feature it encapsulate/decapsulate packet to ESP. But it doesn't use > > standard tx_function in VNET_DEVICE_CLASS, it has ipsec-if-output node > > and for input ESP protocol is registered with ipsec-if-input node. Node > > path: > > ipsec-if-input->esp-decrypt > > after decrypt where next? why not to ip4_input on the ipsec0 interface? >
esp-decrypt next is ip4-input or ip6-input (but IKEv2 can create only IPv4 tunnel currently), ipsec-if-input only set SA index to vnet_buffer features based on ESP header SPI, esp-decrypt is common for all IPSec/IKE stuff > >> > >> I expect that you can still do; set int ip addr ipsec0 10.0.0.1/30 > >> that is agnostic w.r.t. the interface type. > > > > This lead to segmentation fault currently. > > If I can be of assistance debugging that, please unicast me. > > thanks, > neale > > >> > >> regards, neale > >> > >> > >>> Regards, Matus > >>> > >>>> -----Original Message----- From: csit-dev-boun...@lists.fd.io > >>>> [mailto:csit-dev-boun...@lists.fd.io] On Behalf Of Neale Ranns > >>>> (nranns) Sent: Tuesday, October 11, 2016 4:14 PM To: Zdenko > >>>> Olsovsky -X (zolsovsk - PANTHEON TECHNOLOGIES at Cisco) > >>>> <zolso...@cisco.com>; vpp-dev@lists.fd.io Cc: csit-...@lists.fd.io > >>>> Subject: Re: [csit-dev] [vpp-dev] Cannot add route to ipsec0 > >>>> interface > >>>> > >>>> > >>>> Hi Zdenko, > >>>> > >>>> I'm surprised traffic was received on the interface given it does > >>>> not have an IP address. A couple of questions: - what is an IPSEC > >>>> interface? - how and why did we bypass the IP input features on > >>>> that > >> interface? > >>>> > >>>> some answers inline... > >>>> > >>>> On 11/10/16 13:53, Zdenko Olsovsky -X (zolsovsk - PANTHEON > >>>> TECHNOLOGIES at Cisco) wrote: > >>>>> Hi everyone, > >>>>> > >>>>> > >>>>> > >>>>> I made some tests for IKEv2 functionality which were working about > >>>>> a month > >>>> ago. > >>>>> Unfortunately, today I realized that these are no longer working. > >>>>> > >>>>> > >>>>> > >>>>> Running this command : exec ip route add 10.0.10.1/24 via ipsec0 > >>>>> -- worked fine before > >>>>> > >>>>> Will result in error: 'via ipsec0' parse error. > >>>>> > >>>>> > >>>>> I suppose there should be some IP in front of the interface name, > >>>> > >>>> yes there should. On multi-access interfaces (like Ethernet) one > >>>> must send the packet TO a peer on the link, not just put a packet > >>>> on the wire. The only reason that would otherwise work is proxy-arp > >>>> on the peer, but the less said about that the better. for > >>>> point-2-point interfaces it is possible to just emit the packet on > >>>> the wire without identifying the peer (since there can be only > >>>> one). I'll relax the condition in the CLI to accept only an > >>>> interface if it's point-2-point. > >>>> > >>>>> but I cannot directly set an ip to ipsec0 interface. > >>>> > >>>> this should work; set int ip addr ipsec0 10.0.0.1/30 > >>>> > >>>> then ip route add 10.0.10.1/24 via 10.0.0.2 ipsec0 > >>>> > >>>> regards, neale > >>>> > >>>> > >>>>> > >>>>> > >>>>> I can see from the packet that it arrived into ipsec interface and > >>>>> was decrypted and sent to loopback, but from that point it doesn't > >>>>> know how to forward it back and weird error is in the end of the > >>>>> packet > >> trace. > >>>>> > >>>>> > >>>>> > >>>>> Packet 3 > >>>>> > >>>>> > >>>>> > >>>>> 00:00:15:004763: dpdk-input > >>>>> > >>>>> GigabitEthernet0/a/0 rx queue 0 > >>>>> > >>>>> buffer 0x4db5: current data 0, length 102, free-list 0, > >>>>> totlen-nifb 0, trace 0x2 > >>>>> > >>>>> PKT MBUF: port 1, nb_segs 1, pkt_len 102 > >>>>> > >>>>> buf_len 2176, data_len 102, ol_flags 0x0, data_off 128, phys_addr > >>>>> 0x4e132c40 > >>>>> > >>>>> packet_type 0x0 > >>>>> > >>>>> IP4: 08:00:27:7e:6e:2e -> 08:00:27:9b:f1:65 > >>>>> > >>>>> IPSEC_ESP: 10.0.0.10 -> 10.0.0.5 > >>>>> > >>>>> tos 0x00, ttl 64, length 88, checksum 0x6665 > >>>>> > >>>>> fragment id 0x0001 > >>>>> > >>>>> 00:00:15:004790: ethernet-input > >>>>> > >>>>> IP4: 08:00:27:7e:6e:2e -> 08:00:27:9b:f1:65 > >>>>> > >>>>> 00:00:15:004794: ip4-input > >>>>> > >>>>> IPSEC_ESP: 10.0.0.10 -> 10.0.0.5 > >>>>> > >>>>> tos 0x00, ttl 64, length 88, checksum 0x6665 > >>>>> > >>>>> fragment id 0x0001 > >>>>> > >>>>> 00:00:15:004797: ip4-lookup > >>>>> > >>>>> fib 0 dpo-idx 6 flow hash: 0x00000000 > >>>>> > >>>>> IPSEC_ESP: 10.0.0.10 -> 10.0.0.5 > >>>>> > >>>>> tos 0x00, ttl 64, length 88, checksum 0x6665 > >>>>> > >>>>> fragment id 0x0001 > >>>>> > >>>>> 00:00:15:004800: ip4-local > >>>>> > >>>>> IPSEC_ESP: 10.0.0.10 -> 10.0.0.5 > >>>>> > >>>>> tos 0x00, ttl 64, length 88, checksum 0x6665 > >>>>> > >>>>> fragment id 0x0001 > >>>>> > >>>>> 00:00:15:004803: ipsec-if-input > >>>>> > >>>>> IPSec: spi 623421022 seq 1 > >>>>> > >>>>> 00:00:15:004804: esp-decrypt > >>>>> > >>>>> esp: crypto aes-cbc-192 integrity sha1-96 > >>>>> > >>>>> 00:00:15:004865: ip4-input > >>>>> > >>>>> ICMP: 10.0.10.1 -> 10.0.5.1 > >>>>> > >>>>> tos 0x00, ttl 64, length 28, checksum 0x57df > >>>>> > >>>>> fragment id 0x0001 > >>>>> > >>>>> ICMP echo_request checksum 0xf7ff > >>>>> > >>>>> 00:00:15:004866: ip4-lookup > >>>>> > >>>>> fib 0 dpo-idx 5 flow hash: 0x00000000 > >>>>> > >>>>> ICMP: 10.0.10.1 -> 10.0.5.1 > >>>>> > >>>>> tos 0x00, ttl 64, length 28, checksum 0x57df > >>>>> > >>>>> fragment id 0x0001 > >>>>> > >>>>> ICMP echo_request checksum 0xf7ff > >>>>> > >>>>> 00:00:15:004866: ip4-local > >>>>> > >>>>> ICMP: 10.0.10.1 -> 10.0.5.1 > >>>>> > >>>>> tos 0x00, ttl 64, length 28, checksum 0x57df > >>>>> > >>>>> fragment id 0x0001 > >>>>> > >>>>> ICMP echo_request checksum 0xf7ff > >>>>> > >>>>> 00:00:15:004867: ip4-icmp-input > >>>>> > >>>>> ICMP: 10.0.10.1 -> 10.0.5.1 > >>>>> > >>>>> tos 0x00, ttl 64, length 28, checksum 0x57df > >>>>> > >>>>> fragment id 0x0001 > >>>>> > >>>>> ICMP echo_request checksum 0xf7ff > >>>>> > >>>>> 00:00:15:004869: ip4-icmp-echo-request > >>>>> > >>>>> ICMP: 10.0.10.1 -> 10.0.5.1 > >>>>> > >>>>> tos 0x00, ttl 64, length 28, checksum 0x57df > >>>>> > >>>>> fragment id 0x0001 > >>>>> > >>>>> ICMP echo_request checksum 0xf7ff > >>>>> > >>>>> 00:00:15:004874: ip4-rewrite-local > >>>>> > >>>>> tx_sw_if_index 5 adj-idx 1 : loop0 index:1 flow hash: 0x00000000 > >>>>> > >>>>> > >>>>> > >>>>> 00:00:15:004876: ip4-arp > >>>>> > >>>>> IP6_HOP_BY_HOP_OPTIONS: 8.6.69.0 -> 0.28.127.62 > >>>>> > >>>>> version 15, header length 60 > >>>>> > >>>>> tos 0xff, ttl 0, length 65535, checksum 0x0000 (should be 0x1646) > >>>>> > >>>>> fragment id 0xffff offset 62824, flags MORE_FRAGMENTS > >>>>> > >>>>> 00:00:15:004878: error-drop > >>>>> > >>>>> ip4-arp: ARPs to non-ARP adjacencies > >>>>> > >>>>> > >>>>> > >>>>> VPP version : v16.12-rc0~173-gf56b77a~b1196 > >>>>> > >>>>> > >>>>> > >>>>> Is it better to adjust the ipsec implementation so the ipsec > >>>>> interface can be set an IP or is there other way I can accomplish > >>>>> this? > >>>>> > >>>>> Thanks, > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Zdeno > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ vpp-dev > mailing > >> list > >>>>> vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev > >>>>> > >>>> _______________________________________________ csit-dev mailing > >>>> list csit-...@lists.fd.io https://lists.fd.io/mailman/listinfo/csit-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
