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> on behalf of Gulakh <holoogul...@gmail.com>
Date: Wednesday, 20 June 2018 at 22:32
To: "vpp-dev@lists.fd.io" <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 (#9663): https://lists.fd.io/g/vpp-dev/message/9663
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]
-=-=-=-=-=-=-=-=-=-=-=-
