Re: [vpp-dev] Query regarding neos mpls fib entry for tunnel interface

2022-08-25 Thread sreejith n
Hi Neale,

Thanks a lot for the help.

Thanks & Regards,
Sreejith


On Fri, 26 Aug, 2022, 4:34 AM Neale Ranns,  wrote:

>
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of sreejith n
> via lists.fd.io 
> *Date: *Thursday, 25 August 2022 at 13:10
> *To: *vpp-dev@lists.fd.io 
> *Subject: *[vpp-dev] Query regarding neos mpls fib entry for tunnel
> interface
>
> Hi All,
>
>
>
> I have a query regarding neos mpls fib entry for tunnel interface. I have
> observed when we create mpls fib entry with neos bit set for tunnel label
> it always sets forwarding as drop ("dpo-drop mpls"). For the eos bit the
> issue is not seen the forwarding is set correctly.
>
>
>
> Is this expected to have neos mpls fib entry created as drop for mpls
> tunnel interface. Is this due to any reason. I am checking on a use case in
> which I have to set the tunnel label with both neos and eos fib bit entry
> for the lookup and forwarding .
>
>
>
> Logs:
>
>
>
> CLI:
>
> "mpls local-label add 51999 via l2-input-on mpls-tunnel0"
>
>
>
> You are adding the local-label entry to point to l2-input, that is, after
> popping the label consider what remains to be an ethernet frame and pretend
> that it arrived on mpls-tunnel0. That works when the label popped is
> end-of-stack, but not when it’s not end-of-stack. Hence the neos entry is a
> drop.
>
>
>
> /neale
>
>
>
>
>
> MPLS FIB:
>
> *51999:neos/21 fib:0 index:35 locks:2*
>
>   CLI refs:1 entry-flags:attached, src-flags:added,contributing,active,
>
> path-list:[30] locks:4 flags:shared, uPRF-list:27 len:0 itfs:[]
>
>   path:[34] pl-index:30 ethernet weight=1 pref=0 intf-rx:
> oper-flags:resolved, cfg-flags:interface-rx,
>
> [@0]: mpls-tunnel0-rx-dpo: ethernet
>
>
>
>  *forwarding:   mpls-neos-chain >>>> NEOS*
>
> *  [@0]: dpo-load-balance: [proto:mpls index:40 buckets:1 uRPF:27
> to:[0:0]]*
>
> *[0] [@0]: dpo-drop mpls** >>>> DROP*
>
> *51999:eos/21** fib:0 index:24 locks:2*
>
>   API refs:1 entry-flags:attached, src-flags:added,contributing,active,
>
> path-list:[30] locks:4 flags:shared, uPRF-list:27 len:0 itfs:[]
>
>   path:[34] pl-index:30 ethernet weight=1 pref=0 intf-rx:
> oper-flags:resolved, cfg-flags:interface-rx,
>
> [@0]: mpls-tunnel0-rx-dpo: ethernet
>
>
>
> * forwarding:   mpls-eos-chain >>>>>> EOS*
>
>   *[@0]: dpo-load-balance: [proto:mpls index:26 buckets:1 uRPF:27
> to:[34:1700]]*
>
> *[0] [@6]: mpls-tunnel0-rx-dpo: ethernet >>>> VALID*
>
>
>
> Thanks & Regards,
>
> Sreejith
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21827): https://lists.fd.io/g/vpp-dev/message/21827
Mute This Topic: https://lists.fd.io/mt/93241741/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[vpp-dev] Query regarding neos mpls fib entry for tunnel interface

2022-08-24 Thread sreejith n
Hi All,

I have a query regarding neos mpls fib entry for tunnel interface. I have
observed when we create mpls fib entry with neos bit set for tunnel label
it always sets forwarding as drop ("dpo-drop mpls"). For the eos bit the
issue is not seen the forwarding is set correctly.

Is this expected to have neos mpls fib entry created as drop for mpls
tunnel interface. Is this due to any reason. I am checking on a use case in
which I have to set the tunnel label with both neos and eos fib bit entry
for the lookup and forwarding .

Logs:

CLI:
"mpls local-label add 51999 via l2-input-on mpls-tunnel0"

MPLS FIB:

*51999:neos/21 fib:0 index:35 locks:2*

  CLI refs:1 entry-flags:attached, src-flags:added,contributing,active,

path-list:[30] locks:4 flags:shared, uPRF-list:27 len:0 itfs:[]

  path:[34] pl-index:30 ethernet weight=1 pref=0 intf-rx:
oper-flags:resolved, cfg-flags:interface-rx,

[@0]: mpls-tunnel0-rx-dpo: ethernet



 *forwarding:   mpls-neos-chain  NEOS*

*  [@0]: dpo-load-balance: [proto:mpls index:40 buckets:1 uRPF:27 to:[0:0]]*

*[0] [@0]: dpo-drop mpls  DROP*

*51999:eos/21 fib:0 index:24 locks:2*

  API refs:1 entry-flags:attached, src-flags:added,contributing,active,

path-list:[30] locks:4 flags:shared, uPRF-list:27 len:0 itfs:[]

  path:[34] pl-index:30 ethernet weight=1 pref=0 intf-rx:
oper-flags:resolved, cfg-flags:interface-rx,

[@0]: mpls-tunnel0-rx-dpo: ethernet



* forwarding:   mpls-eos-chain >> EOS*

  *[@0]: dpo-load-balance: [proto:mpls index:26 buckets:1 uRPF:27
to:[34:1700]]*

*[0] [@6]: mpls-tunnel0-rx-dpo: ethernet  VALID*


Thanks & Regards,

Sreejith

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21821): https://lists.fd.io/g/vpp-dev/message/21821
Mute This Topic: https://lists.fd.io/mt/93241741/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [vpp-dev] Query regarding MPLS Tunnel

2022-05-26 Thread sreejith n
Hi Neale,

Sure, thanks a lot.

Thanks & Regards,
Sreejith

On Fri, May 27, 2022 at 4:56 AM Neale Ranns  wrote:

>
>
> Hi Sreejith,
>
>
>
> No good reason. Please provide a patch to add that capability.
>
>
>
> /neale
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of sreejith n
> via lists.fd.io 
> *Date: *Friday, 27 May 2022 at 00:34
> *To: *vpp-dev@lists.fd.io 
> *Subject: *[vpp-dev] Query regarding MPLS Tunnel
>
> Hi All,
>
> I have a query regarding Mpls Tunnel delete option.
>
> I have observed we can delete the mpls tunnel created using the CLI by
> only passing the tunnel index.
>
> *CLI (To delete mpls tunnel):*
>
>
>
> *mpls tunnel del mpls-tunnel0*
>
>
>
> But in API option I have observed we cannot delete the mpls tunnel by
> passing tunnel index alone we need to pass rpath details (mandatory) .
>
>
>
> *API:*
>
> *vl_api_mpls_tunnel_add_del_t_handler*
>
>
>
>  *if (!vnet_mpls_tunnel_path_remove (tunnel_sw_if_index, rpaths))*
>* vnet_mpls_tunnel_del (tunnel_sw_if_index);*
>
>
>
> I wanted to ask is there any specific reason to pass the rpath details in
> the API option, can we delete the tunnel directly using the tunnel index
> similar to CLI.
>
>
>
> In the CLI API, I have observed it is handled as below, the tunnel is
> deleted directly using tunnel index if rpath is NULL:
>
>
>
> *CLI API:*
>
> *vnet_create_mpls_tunnel_command_fn *
>
>
>
>
>
>
>
>
>
>
> *if (NULL == rpaths) { vnet_mpls_tunnel_del(sw_if_index);  }
> else if (!vnet_mpls_tunnel_path_remove(sw_if_index, rpaths)) {
>  vnet_mpls_tunnel_del(sw_if_index); }*
>
>
>
> Can we consider a similar handling for API option in
> "vl_api_mpls_tunnel_add_del_t_handler".
>
>
>
> Thanks & Regards,
>
> Sreejith
>
>
>
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21476): https://lists.fd.io/g/vpp-dev/message/21476
Mute This Topic: https://lists.fd.io/mt/91355659/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-