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:
*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) <[email protected]>
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: *<[email protected]> on behalf of Gulakh <[email protected]>
> *Date: *Wednesday, 20 June 2018 at 22:32
> *To: *"[email protected]" <[email protected]>
> *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 (#9664): https://lists.fd.io/g/vpp-dev/message/9664
Mute This Topic: https://lists.fd.io/mt/22449276/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
