Hi Neale, IPSec interface is tunnel interface created by IKEv2 code when child SA is successfully established. You can't set IP on it because there is missing "ip4_sw_interface_enable_disable" when interface is created, I will fix it.
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
