Hi Amit, From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Amit Mehra via lists.fd.io <amito2in=gmail....@lists.fd.io> Date: Friday, 14 January 2022 at 12:50 To: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> Subject: [vpp-dev] MPLS Tunnel Interface on Provider Router
Hi, I was doing a PoC to simulate label swap operation on Service Provider Router(non PE Routers) by creating a mpls tunnel interface and using that tunnel interface as a target in mpls route entry. Reference:https://wiki.fd.io/view/VPP/MPLS_FIB Please find below the set of configs that I tried and the corresponding observation with VPP 21.01 Config 1: Configured MPLS FIB entry without eos bit set. mpls table add 0 set interface mpls GigabitEthernet0/6/0 enable--------------->Incoming Interface is GigabitEthernet0/6/0 set interface mpls GigabitEthernet0/7/0 enable--------------->Outgoing Interface is GigabitEthernet0/7/0 mpls tunnel add via 10.10.10.10 GigabitEthernet0/7/0 out-labels 44 set interface state mpls-tunnel0 up mpls local-label add 33 via mpls-tunnel0 non-eos is the default when programming local-labels. In order to forward non-eos traffic the egress path must have output labels. This is so that the next label in the stack is not exposed, accidently, to the next/intermediate devices. If the next label in the stack is meant for the next downstream device, i.e. it is directly connected, then you must specify and out-label of implicit-null. i.e: mpls local-label add 33 non-eos via 0.0.0.0 mpls-tunnel0 out-labels implicit-null Expectation:- On receiving an MPLS encapsulated label with in-label as 33 and without "eos" bit set, it should swap the label 33 with label 44 and send to it's neighbor i.e. 10.10.10.10 via GigabitEthernet0/7/0 interface. Observation:- I am seeing the forwarding action as dpo-drop in mpls fib table. Please find the output of mplf-fib tables below 33:neos/21 fib:0 index:18 locks:2 CLI refs:1 entry-flags:attached, src-flags:added,contributing,active, path-list:[25] locks:2 flags:shared, uPRF-list:21 len:1 itfs:[96, ] path:[27] pl-index:25 mpls weight=1 pref=0 attached-nexthop: oper-flags:resolved, cfg-flags:attached, 2100::200:0:0:0 mpls-tunnel0 (p2p) [@0]: mpls via 0.0.0.0 mpls-tunnel0: mtu:9000 next:2 stacked-on: [@2]: dpo-load-balance: [proto:mpls index:20 buckets:1 uRPF:-1 to:[0:0]] [0] [@6]: mpls-label[@0]:[44:64:0:neos] [@1]: arp-mpls: via 10.10.10.10 GigabitEthernet0/7/0 forwarding: mpls-neos-chain [@0]: dpo-load-balance: [proto:mpls index:21 buckets:1 uRPF:21 to:[0:0]] [0] [@0]: dpo-drop mpls On receiving an MPLS packet, it is getting dropped in mpls-lookup node. Please find the vpp trace output below. ..snip… Config 2:- Configured MPLS FIB entry with eos bit set. mpls table add 0 set interface mpls GigabitEthernet0/6/0 enable--------------->Incoming Interface is GigabitEthernet0/6/0 set interface mpls GigabitEthernet0/7/0 enable--------------->Outgoing Interface is GigabitEthernet0/7/0 mpls tunnel add via 10.10.10.10 GigabitEthernet0/7/0 out-labels 44 set interface state mpls-tunnel0 up mpls local-label add 33 eos via mpls-tunnel0 when programming eos routes, it is necessary for VPP to know what type of traffic is exposed when the label is popped. When programming via the API you’ll see that this is an input parameter. However, the CLI takes a shortcut and attempts to derive it from the next-hop address path. Your path though is attached (it doesn’t specify a next-hop) so this doesn’t work and the wheels fall off. If you change the CLI command to: mpls local-label add 33 eos via 0.0.0.0 mpls-tunnel0 it will work. Clearly that assumes IPv4 is being carried. Expectation:- On receiving an MPLS encapsulated label with in-label as 33 and with "eos" bit set, it should swap the label 33 with label 44 and send to it's neighbor i.e. 10.10.10.10 via GigabitEthernet0/7/0 interface. Observation:- Observing a crash in vpp on issuing the CLI "mpls local-label add 33 eos via mpls-tunnel0". Is this some known issue? The following is the stack trace …snip… The only difference between config 1 and config 2 was that of "eos" bit i.e. bit was set in the latter. Config 3:- Also, I tried configuring PE Router by creating tunnel interface and used that interface as a target in IP Route. Following is the config used. mpls table add 0 set interface mpls GigabitEthernet0/6/0 enable--------------->Incoming Interface is GigabitEthernet0/6/0 set interface mpls GigabitEthernet0/7/0 enable--------------->Outgoing Interface is GigabitEthernet0/7/0 mpls tunnel add via 20.20.20.20 GigabitEthernet0/7/0 out-labels 44 set interface state mpls-tunnel0 up ip route add 10.10.10.10/32 via mpls-tunnel0------------------>It seems to be working as expected Expectation:- On receiving IP packet, it should be able to encapsulate an MPLS header with label 44 and send the packet out via GigabitEthernet0/7/0 Observation:- It was able to encapsulate an MPLS header with label 44 and sent the packet out via GigabitEthernet0/7/0. The stats corresponding to mpls-tunnel0 interface were also incremented in vpp “show int“ CLI command Based on the above observations, I have the following set of queries around vpp tunnel interface usage:- - Are mpls tunnel interface creation meant only for PE(Provider Edge Routers)? No distinctions are made on the role of the device. - Can we create and use tunnel interface as a target in mpls routes on Provider Routers for achieving label swap operation i.e. label pop followed by label push i.e. something like this “mpls local-label add 33 [eos] via mpls-tunnel0”? Yes. But you don’t have to use a tunnel to achieve a swap. This works fine too mpls local-label 33 via 10.10.10.10 GigabitEthernet0/7/0 out-labels 44 - Usage of mpls tunnel interface? Any documentation? See test/test_mpls.py. documentation you have already found. /neale Regards Amit
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20723): https://lists.fd.io/g/vpp-dev/message/20723 Mute This Topic: https://lists.fd.io/mt/88418846/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
