Hi Benoit,

Sorry to poke in the middle
   > - VLANs arrive on different sub-interfaces
   > - each sub-interface is in a different VRF
   > - each VRF has its own tunnel with a default route going through it

We would need something of this sort, can you provide example for the same
in vpp ?

Thanks,
Regards,
Venu

On Wed, 7 Apr 2021 at 23:12, Benoit Ganne (bganne) via lists.fd.io <bganne=
[email protected]> wrote:

> Hi Manoj,
>
> We support 2 main modes:
>  - tunnel protection mode:
> https://wiki.fd.io/view/VPP/IPSec#Protection_Model
>  - policy mode: https://wiki.fd.io/view/VPP/IPSec#Policy_Mode
>
> In tunnel protection mode, the packet classification is done via routing,
> I suspect this is what you need, eg.
>  - VLANs arrive on different sub-interfaces
>  - each sub-interface is in a different VRF
>  - each VRF has its own tunnel with a default route going through it
>
> Of course you can build more complex topologies, eg. having multiple
> tunnels per VRF with different routes, etc.
>
> Best
> ben
>
> > -----Original Message-----
> > From: [email protected] <[email protected]> On Behalf Of Manoj Kumar
> > (manojku5) via lists.fd.io
> > Sent: mercredi 7 avril 2021 19:19
> > To: [email protected]
> > Cc: Dharmarajan Subramanian (dharsubr) <[email protected]>; Srinivas
> > Davuluri (srinud) <[email protected]>; Prashant Anand (prasanan)
> > <[email protected]>
> > Subject: [vpp-dev] IPSec - Clear packet's classification for SA lookup in
> > VPP
> >
> > Hi Team,
> >
> >
> >
> > We have some basic queries on the IPSEC support in VPP. Could someone
> > please take a look?
> >
> >
> >
> > How does the clear packet classification and SA lookup happens in VPP for
> > the packet? I mean, what all fields of the IP packet are considered for
> > the SA lookup – can it support some L2/VLAN fields as well for this
> > lookup?
> >
> > *     Please share some code pointers towards this if possible.
> >
> >
> >
> > I came across esp4_encrypt_handoff() in ipsec_handoff.c file but could
> not
> > find the caller for the same. Which code leg calls this?
> >
> > *     This further points to esp4_encrypt_node() and to
> > esp_encrypt_inline().
> > *     Inside esp_encrypt_inline(), I can see the code to access the SA
> for
> > the packet. But looks like that is pre-populated in the packet/frame. Is
> > that understanding correct? If yes, can you please point us to the code
> > pointers where this is set – is it in the previous graph node before
> > “esp4_encrypt_handoff”?
> >
> > 636       if (is_tun)
> >
> > 637     {
> >
> > 638       /* we are on a ipsec tunnel's feature arc */
> >
> > 639       vnet_buffer (b[0])->ipsec.sad_index =
> >
> > 640         sa_index0 = ipsec_tun_protect_get_sa_out
> >
> > 641         (vnet_buffer (b[0])->ip.adj_index[VLIB_TX]);
> >
> > 642     }
> >
> > 643       else
> >
> > 644     sa_index0 = vnet_buffer (b[0])->ipsec.sad_index;
> >
> > 645
> >
> >
> >
> > At a high level, we want to be able to support IPSEC for multiple VRFs
> and
> > we would like to use an L2 encapsulation so that we can classify / find
> > the SA for the clear text packet using the IP Header and the L2 fields.
> Is
> > that supported?
> >
> > If yes, what is the control plane programming requirements for that and
> > where is this classification done in the VPP code?
> >
> >
> >
> >
> >
> > Thanks & Regards
> >
> > --Manoj
> >
> >
>
>
> 
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19130): https://lists.fd.io/g/vpp-dev/message/19130
Mute This Topic: https://lists.fd.io/mt/81921820/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to