If you want to resolve a recursive path that has outgoing labels, ie.
via 1.1.1.1 out-labels 33
then the resolving route in the FIB MUST also have out-labels. This is because
you are in effect layering LSPs (the tunnel is the upper/inner layer and the
route the lower/outer layer). The out-label for the tunnel, provided by the
tunnel egress device, is not necessarily directly connected to the tunnel
ingress device. Hence, if the route did not have an out label then a device in
between the two (that is in the lower layer) would see the label for the
tunnel/upper layer and mis-forward.
If your two devices are directly connected and so the problem above cannot
occur, you still need an out-label for the route, but one describes such
directly connectivity by giving the route an implicit-null out-label, i.e.
ip route 1.1.1.1/32 via 192.168.1.1 GigabitEthernet13/0/0 out-label imp-null
/neale
From: Holoo Gulakh <holoogul...@gmail.com>
Date: Thursday, 21 June 2018 at 17:26
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "vpp-dev@lists.fd.io"
<vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] mpls tunnel
Hi,
It is not a valid solution.(at least "show mpls tunnel" says that)
Here is the new configuration and result:
mpls tunnel l2-only via 1.1.1.1 out-labels 33
ip route add 1.1.1.1/32<http://1.1.1.1/32> via 192.168.1.1
GigabitEthernet13/0/0
result:
I expect to see something like the result of second scenario above:
=======================
[@0] mpls_tunnel0: sw_if_index:4 hw_if_index:4
flags:L2,
via:
path-list:[23] locks:1 flags:shared, uPRF-list:19 len:1 itfs:[2, ]
path:[23] pl-index:23 ip4 weight=1 pref=0 attached-nexthop:
oper-flags:resolved,
1.1.1.1 GigabitEthernet13/0/0
[@0]: arp-ipv4: via 1.1.1.1 GigabitEthernet13/0/0
Extensions:
path:23 mpls-flags:[no-ip-tll-decr] labels:[[33 pipe ttl:0 exp:0]]
forwarding: ethernet
[@1]: dpo-load-balance: [proto:ethernet index:23 buckets:1 uRPF:-1 to:[0:0]]
[0] [@2]: mpls-label[0]:[33:64:0:eos]
[@1]: arp-mpls: via 1.1.1.1 GigabitEthernet13/0/0
But the result is as follow:
=======================
[@0] mpls_tunnel0: sw_if_index:4 hw_if_index:4
flags:L2,
via:
path-list:[23] locks:1 flags:shared, uPRF-list:19 len:1 itfs:[2, ]
path:[23] pl-index:23 ip4 weight=1 pref=0 recursive:
via 1.1.1.1 in fib:0 via-fib:17 via-dpo:[dpo-load-balance:20]
Extensions:
path:23 mpls-flags:[no-ip-tll-decr] labels:[[33 pipe ttl:0 exp:0]]
forwarding: ethernet
[@1]: dpo-load-balance: [proto:ethernet index:23 buckets:1 uRPF:-1 to:[0:0]]
[0] [@0]: dpo-drop ethernet
If I use the following command for the route to 1.1.1.1<http://1.1.1.1>:
ip route add 1.1.1.1/32<http://1.1.1.1/32> via 192.168.1.1
GigabitEthernet13/0/0 out-labels 50
the result is:
=======================
[@0] mpls_tunnel0: sw_if_index:4 hw_if_index:4
flags:L2,
via:
path-list:[23] locks:1 flags:shared, uPRF-list:19 len:1 itfs:[2, ]
path:[23] pl-index:23 ip4 weight=1 pref=0 recursive: oper-flags:resolved,
via 1.1.1.1 in fib:0 via-fib:17 via-dpo:[dpo-load-balance:20]
Extensions:
path:23 mpls-flags:[no-ip-tll-decr] labels:[[33 pipe ttl:0 exp:0]]
forwarding: ethernet
[@1]: dpo-load-balance: [proto:ethernet index:23 buckets:1 uRPF:-1 to:[0:0]]
[0] [@2]: mpls-label[0]:[33:64:0:eos]
[@1]: dpo-load-balance: [proto:mpls index:21 buckets:1 uRPF:22 to:[0:0]
via:[1:64]]
[0] [@6]: mpls-label[1]:[50:64:0:neos]
[@2]: mpls via 192.168.1.1 GigabitEthernet13/0/0: mtu:9000
000c293a39d7000c29d693938847
Which is correct in my scenario.
How can I use the defined route for 1.1.1.1 in IP fib as the route for mpls
tunnel to get to 1.1.1.1 (in both case with mpls label--which I provided-- and
without mpls label)??
Thanks.
On Thu, Jun 21, 2018 at 4:46 AM, Neale Ranns (nranns)
<nra...@cisco.com<mailto:nra...@cisco.com>> wrote:
Hi,
This:
XXX via via 1.1.1.1 ip4-lookup-in-table 0 out-labels 33
is not a valid path.
If you want packets to follow the same path as for 1.1.1.1 (i.e. the path is
recursive via 1.1.1.1, and you’ll need a route in the fib for 1.1.1.1) and have
label 33 imposed, do:
XXX via via 1.1.1.1 out-labels 33
If the 1.1.1.1 you want to recurse via is not in the default table, then do:
XXX via via 1.1.1.1 next-hop-table Y out-labels 33
If (e.g. post a label pop) you want to use the exposed IP4 header to do a IP4
lookup then do:
XXX via via ip4-lookup-in-table 0
This:
XXX via 1.1.1.1 GigabitEthernet13/0/0 out-labels 33
Is not a recursive path. It will resolve via the adjacency for 1.1.1.1 on
GigE13/0/0 and thus will attempt to ARP for 1.1.1.1 out of that interface.
Since 1.1.1.1 is not an address on that interface’s configured subnet, this
won’t work, unless the peer is running proxy ARP, which we all know is evil.
/neale
From: <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> on behalf of Gulakh
<holoogul...@gmail.com<mailto:holoogul...@gmail.com>>
Date: Wednesday, 20 June 2018 at 22:32
To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>"
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] mpls tunnel
Hi,
My topology is:
R1 (192.168.1.1/24<http://192.168.1.1/24>)
<------------------> R2 (192.168.1.2/24<http://192.168.1.2/24>)
and R1 loopback interface has IP address of 1.1.1.1/32<http://1.1.1.1/32>
======================
I have configured VPP's mpls tunnel as follow:
set interface ip address GigabitEthernet13/0/0
192.168.1.2/24<http://192.168.1.2/24>
mpls tunnel l2-only via 1.1.1.1 ip4-lookup-in-table 0 out-labels 33
To make it possible to find 1.1.1.1, I inserted a route in ip fib as follow:
ip route add 1.1.1.1/32<http://1.1.1.1/32> via 192.168.1.1
GigabitEthernet13/0/0
What I see in "show mpls tunnel" is as follow:
[@0] mpls_tunnel0: sw_if_index:4 hw_if_index:4
flags:L2,
via:
path-list:[22] locks:1 flags:shared, uPRF-list:20 len:1 itfs:[2, ]
path:[22] pl-index:22 ip4 weight=1 pref=0 recursive:
via 192.168.1.1 in fib:0 via-fib:17 via-dpo:[dpo-load-balance:20]
Extensions:
path:22 mpls-flags:[no-ip-tll-decr] labels:[[33 pipe ttl:0 exp:0]]
forwarding: ethernet
[@1]: dpo-load-balance: [proto:ethernet index:22 buckets:1 uRPF:-1 to:[0:0]]
[0] [@0]: dpo-drop ethernet
======================
In another scenario, I have used following configurations:
set interface ip address GigabitEthernet13/0/0
192.168.1.2/24<http://192.168.1.2/24>
mpls tunnel l2-only via 1.1.1.1 GigabitEthernet13/0/0 out-labels 33
What I see in "show mpls tunnel" is as follow:
[@0] mpls_tunnel0: sw_if_index:4 hw_if_index:4
flags:L2,
via:
path-list:[23] locks:1 flags:shared, uPRF-list:19 len:1 itfs:[2, ]
path:[23] pl-index:23 ip4 weight=1 pref=0 attached-nexthop:
oper-flags:resolved,
1.1.1.1 GigabitEthernet13/0/0
[@0]: arp-ipv4: via 1.1.1.1 GigabitEthernet13/0/0
Extensions:
path:23 mpls-flags:[no-ip-tll-decr] labels:[[33 pipe ttl:0 exp:0]]
forwarding: ethernet
[@1]: dpo-load-balance: [proto:ethernet index:23 buckets:1 uRPF:-1 to:[0:0]]
[0] [@2]: mpls-label[0]:[33:64:0:eos]
[@1]: arp-mpls: via 1.1.1.1 GigabitEthernet13/0/0
======================
My Question:
Q: Why does not VPP resolve IP address of 1.1.1.1 in the first configuration
(As the "show mpls tunnel" in first scenario shows, It has not been resolved)??
I expect to do so since I have added a route for 1.1.1.1 in IP fib.
Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9675): https://lists.fd.io/g/vpp-dev/message/9675
Mute This Topic: https://lists.fd.io/mt/22449276/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
