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) <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> 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 (#9664): https://lists.fd.io/g/vpp-dev/message/9664 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] -=-=-=-=-=-=-=-=-=-=-=-