[vpp-dev] vppctl doesn't report returned pings from rdma int
I noticed on a couple of servers that I have interconnected in packet.net that when using vppctl ping command, the rdma interface the ping command doesn't report returned packets. ping says 0 received, but the received packets show up in counts in show int though. --Tom -- *Thomas F Herbert* NFV and Fast Data Planes Networking Group Office of the CTO *Red Hat* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13118): https://lists.fd.io/g/vpp-dev/message/13118 Mute This Topic: https://lists.fd.io/mt/31723900/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] middlebox plugin
Hello, I have written a basic middlebox plugin some months ago and pushed it to vppsb. As the action on this repo is very low, I would like to make sure that someone saw it. I have found uses for it, so others might as well. If you are too busy, please ignore this message =) https://gerrit.fd.io/r/#/c/15474/ Cheers, Korian -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13117): https://lists.fd.io/g/vpp-dev/message/13117 Mute This Topic: https://lists.fd.io/mt/31723122/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] x86 ubuntu bionic gcc repointed from gcc-8 to gcc7
While debugging both a csit compilation problem and also some recent failures in bionic verify and merge jobs I have re-pointed gcc from gcc8 back down to gcc7 to see if that mitigates the problem. If it does not I will be rebuilding the X86 ubuntu image without gcc-8 (and its required packages) installed to see if that helps the issue. This is done after consulting with pmikus and dave wallace. Ed -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13116): https://lists.fd.io/g/vpp-dev/message/13116 Mute This Topic: https://lists.fd.io/mt/31722332/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] RFC: IPSec Tunnel remodel
Hi Neale, We (Netgate/TNSR) use strongswan for IKE with a module that connects to the VPP binary API to manage IPsec tunnel interfaces. The API changes mostly look fine from my perspective. It won't be that much different than what we do now. Currently we create an IPsec tunnel interface before any IKE negotiation has taken place and populate dummy values for SPIs and other fields that are not known yet. Then as the IKE daemon negotiates SAs, we create them in VPP and associate them to the tunnel interface. This means that for our purposes, there is not a change from making 1 API call to 4 calls. We currently make 5 calls in the process of getting a tunnel operational (create tunnel interface, create SA * 2, set SA on tunnel * 2). One addition to your patch that would be useful is support for setting a new SA on a tunnel interface in only one direction at a time. The IKE daemon executes callbacks to install the inbound and outbound SAs separately and it's easier to be able to handle each of them as their own atomic operation than it is to store the data for a new SA for some amount of time until you find that the SA for the other direction has been added and then propagate both of them into VPP at the same time. If it were possible to send a ipsec_tunnel_protect_update message where tunnel.sa_out ==~0 causes only the inbound SA to be updated or tunnel.n_sa_in == 0 causes only the outbound SAs to be updated, this would make transitioning to the new calls more straightforward. At least for me :) Thanks, -Matt On Mon, May 20, 2019 at 11:59 AM Neale Ranns via Lists.Fd.Io wrote: > > Hi VPP-IPSec-ers, > > I'd like to gauge comments on this article: > https://wiki.fd.io/view/VPP/IPSec > and the proposal for the IPSec tunnel re-model. > The associated patch is: > https://gerrit.fd.io/r/#/c/18956/ > > thanks, > Neale > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#13097): https://lists.fd.io/g/vpp-dev/message/13097 > Mute This Topic: https://lists.fd.io/mt/31687572/675725 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [mgsm...@netgate.com] > -=-=-=-=-=-=-=-=-=-=-=- > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13115): https://lists.fd.io/g/vpp-dev/message/13115 Mute This Topic: https://lists.fd.io/mt/31687572/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] RFC: IPSec Tunnel remodel
Hi Neale, > Thanks for taking the time to examine the proposal. Lots of comments inline > >> Answering as a non VPP-IPsec'er. More like an anti-IPsec'er if anything. ;-) > >> Eecutive summary: Not a fan. > >> This tastes too much of the dreams of the IPsec'ers of the past. Where IPsec >> was a general network layer solution that could protect any application, >> independently at the network layer. That vision as we know failed. > > [nr] there's no change to the IPSec vision here __ there are tunnels and > there are protecting SAs - no change to how they're used, no change to IPSec > use-cases - just how they are [re]presented.. Well, that's my point. The idea of applying IPsec SAs independently of application wasn't such a good idea. Tightly couple ipsec with the application. E.g. tunnel. Then you don't get into the equivalent of extension header insertion problems. How do you figure out MTU, how do you parse ICMP (which would have unknown headers). I don't mind too much how you do it in the end. But I do not want an extra lookup for every packet in an IPIP tunnel that isn't ipsec protected. And I would prefer ipsec as a plugin. Cheers, Ole > >> I think it is much clearer from a user interface pov, that you create an >> encrypted tunnel, as opposed to you create a tunnel end then apply a crypto >> policy on it. > > [nr] of the two real changes, this is one. How the user sees the tunnels and > the SAs. Why do you say it's 'cleaner' that there's a dedicated interface > type? Let me give two examples of why I consider the current approach not to > be 'clean' > 1) the tunnel is created in the same API call as the pair of SAs: > create ipsec tunnel local-ip 10.0.0.1 remote-ip 10.0.0.2 local-spi 100 > remote-spi 101 local-crypto-key A11E51E5B1E0 ... [more SA parameters] > now let's rekey this tunnel. The current model is to create the SAs > separately, then apply them to the tunnel > ipsec sa add 20 [SA parameters] > ipsec sa add 30 [SA parameters] > ipsec_tunnel_if_set_sa .(there's no > CLI for this so this is a representation of the API call) > now what happens to the old SAs that were created when the tunnel was > created? Who deletes them? It can't be the user since it does know the ID, so > it has to be VPP. But rekey again and who deletes the SAs this time? We could > solve this by separating the creation of the tunnel and the initial SAs, but > then you have: > create ipsec tunnel 10.0.0.1 remote-ip 10.0.0.2 > which is exactly the same information as the creation of an IPIP tunnel. But > say I was to create an IPSec tunnel this way, assign an IP address, point > routes through it, and bring it up. Do packets come out clear text? This > ambiguity means IMHO it's not clean. > 2) The tunnel creation example above always creates SAs for ESP. Does that > mean that the interface type should really be 'ipsec-esp'? If I want AH SAs > does that make it 'ipsec-ah'? what if I want both? If we're saying instead > that the interface type does not include the SA type, then why include the SA > at all? > >> Looking at the diffs for IPIP node.c it looks like an extra lookup is added, >> to check for a crypto policy. The current approach has the great benefit of >> not polluting ipsec everywhere. I want to be able to build images without >> ipsec baggage. > > [nr] this is to support the new functionality of double encap (using C-IP and > T-IP as described in the wiki article - which is the only way the ipsec-gre > interface currently works). There's a description of why it's done in > ipsec_protect.c. (copied below for your convenience) There are other ways I > could implement this with IPIP code offering tunnel lookup services to > external clients. > If you want IPSec as a plugin we can work on that, but let's keep that > requirement separate for now. > >> I am also worried about the IPIP code no longer knowing the size of the >> extra encap, and where it cannot calculate an inner MTU based on outgoing >> interface MTU. Fixing that would require some awkward signalling back to the >> IPIP "application". Similarly for PMTUD. And ICMP errors in general. Where >> the IPIP ICMP proxy would also have to be made aware of IPsec. > > [nr] agreed these are issue to overcome. But we need to do so for other > separate use-cases too. > 1) an Ethernet interface that has IPSec policy mode applied, has exactly the > same challenge > 2) an MPLS tunnel (whose encap size is determined by the size of the label > stack not by the tunnel type) > >> You want a crypto tunnel, you create a new tunnel type. > > [nr] this is the second real change. Why does VPP need to maintain n > interface types dedicated to crypto that act exactly like other existing > interfaces? Why does interface-type X + feature-type Y = interface-type Z? > Ipip + IPsec = ipsec > When you enable policy mode IPSec (via the SPD) on an ethernet interface, > it's still an ethernet interface,
Re: [vpp-dev] Packet classification based on range of values
No, you can’t do ranges in classifier. You can add multiple chained tables with different masks, but performance wise it most certainly be worse than simply create a mask with exact match for the port and adding 1112 entries for each of the ports you need to match. --a > On 22 May 2019, at 08:15, Satya Murthy wrote: > > Hi, > > From the documentation I have read so far and from the classifier code I have > gone through: > VPP classifier works on mask and match to classify the packets. > > But, I didnt see any logic in the classifier code that classifies packets > based on any rule like "range of values". > For example: is there any VPP construct that can work for a rule like "match > packets with TCP ports ranged between 122 to 1234" ? > > The same thing with ip-address with a prefix-length in the rule. > > Please share if you have some idea on this. > > -- > Thanks & Regards, > Murthy > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#13111): https://lists.fd.io/g/vpp-dev/message/13111 > Mute This Topic: https://lists.fd.io/mt/31717199/675608 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [ayour...@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13113): https://lists.fd.io/g/vpp-dev/message/13113 Mute This Topic: https://lists.fd.io/mt/31717199/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Packet classification based on range of values
Hi, >From the documentation I have read so far and from the classifier code I have >gone through: VPP classifier works on mask and match to classify the packets. But, I didnt see any logic in the classifier code that classifies packets based on any rule like "range of values". For example: is there any VPP construct that can work for a rule like "match packets with TCP ports ranged between 122 to 1234" ? The same thing with ip-address with a prefix-length in the rule. Please share if you have some idea on this. -- Thanks & Regards, Murthy -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13111): https://lists.fd.io/g/vpp-dev/message/13111 Mute This Topic: https://lists.fd.io/mt/31717199/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
