From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Sastry Sista via
lists.fd.io <sastry.sista=gmail....@lists.fd.io>
Date: Wednesday, 8 December 2021 at 03:35
To: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] MPLS: fib table 1 display issue #mpls
Hi Neale,
Thank you for the help. We are trying to exercise vpp mpls
vpn and we are preferring label per prefix only. Anyway I am fine even with per
VRF label but adding more local labels which seems fine while adding.
I am trying to evaluate VRF with non-default ip fib tables.
While I tried default VRF, I always see mpls out-label and dpo rules as below:
Example: Case 1, with default VRF
=============================
vppctl ip route add 1.1.1.1/32 via 107.243.21.116 VirtualFuncEthernet0/9/0.1800
out-labels 18
this is a non-recursive route, that is you have specified both the next-hop and
the interface. Forwarding state can thus be built directly from the adjacency
with that {nh,interface} key.
for this, I see sh ip fib
1.1.1.1/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:134 buckets:1 uRPF:160 to:[0:0]]
[0] [@16]: mpls-label[@1]:[18:64:0:eos]
[@1]: mpls via 107.243.21.116 VirtualFuncEthernet0/9/0.1800: mtu:9000
next:2 fa163e9c9c94fa163ebe37d3810007088847
This is indicating use mpls proto and out label as 18.
Case2: Non default VRF i.e table 2:
=============================
ip route add table 2 1.1.1.1/32 via 107.243.21.116 next-hop-table 0 out-labels
18
this is a recursive route, you have only passed the next-hop. Forwarding state
is built by recursing through/stacking on the forwarding state built for the
next-hop (which we sometimes refer to as the via-fib in this scenario). If the
recursive route has outgoing labels, the it must stack on the non-eos chain/DPO
of the via-fib (you can include the ‘details’ keyword in the show command to
see all of an entry’s chains). If the via FIB does not have a non-eos chain
then the recursive route must drop. A via-fib will not have a non-eos chain if
it does not have out-going labels of its own.
The reason for this is that the device that is advertising the label for the
recursive route might not be directly connected (maybe it’s an iBGP peer).
Therefore if we were to forward packets from the device with only that label,
then that label would be seen by an intermediate device for whom the label
value means something different and would thus result in mis-forwarding, which
must not happen.
If the peer advertising the recursive route is directly connected (an eBGP
peer) and so the via-fib is an adj-fib (i.e. it matches an ARP entry) then you
need to add an implicit-null label as an out-label. This is how the control
plane explicitly states that it is safe to forward with only the label of the
recursive route.
/neale
VRF is table 2 and outer VRF for L2 is table 0.
sh ip fib table 2
1.1.1.1/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:129 buckets:1 uRPF:160 to:[0:0]]
[0] [@0]: dpo-drop ip4
No out-label or mpls dpo rule. Rather its a drop.
Could you please let me know if I have to use always 2 out-labels for non
default VRF cases?
As per your doc: non default VRF:
ip route add 10.0.0.1/32 via 192.168.1.2 Eth0 out-labels 33
VRF at table 2
ip route add table 2 10.10.10.0/24 via 10.0.0.1 next-hop-table 0 out-label 121
With Regards
Sastry
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20600): https://lists.fd.io/g/vpp-dev/message/20600
Mute This Topic: https://lists.fd.io/mt/87373182/21656
Mute #mpls:https://lists.fd.io/g/vpp-dev/mutehashtag/mpls
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
