Re: [vpp-dev] MPLS Tunnel Interface on Provider Router

[sreejithsurendrannair2]

Hi Neale,

Sure, thanks a lot.

Thanks & Regards,
Sreejith

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20865): https://lists.fd.io/g/vpp-dev/message/20865
Mute This Topic: https://lists.fd.io/mt/88418846/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS Tunnel Interface on Provider Router

[Neale Ranns]

Hi Sreejith,

There is no CLI for that. Contributions welcome.

/neale

From: vpp-dev@lists.fd.io  on behalf of 
sreejithsurendrannair2 via lists.fd.io 

Date: Friday, 11 February 2022 at 14:37
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MPLS Tunnel Interface on Provider Router
Hi All,

I have a query regarding the IP and MPLS FIB counters. Is it possible to clear 
the fib counters for the individual FEC or local label  value.

In the below output if we want to clear the counter for 37.37.37.37/32, is 
there any CLI option to clear the same. I could not find any option to clear ip 
fib counter.

Logs:

IP FIB :
37.37.37.37/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:24 buckets:1 uRPF:19 to:[10:840]]
[0] [@11]: mpls-label[@1]:[36000:64:0:eos]
[@1]: mpls via 9.1.1.2 GigabitEthernet0/6/0.17512: mtu:1500 next:2 
525400b16c865254005b8a8681098847

Also in the code I saw the counter is reset during the "load_balance_alloc_i" I 
did not observe it reset in another place.
vlib_zero_combined_counter(&(load_balance_main.lbm_to_counters),
   load_balance_get_index(lb));

Can you please suggest if I missed anything is there any CLI or API option to 
reset the IP FIB and MPLS FIB counters.

Thanks & Regards,
Sreejith

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20862): https://lists.fd.io/g/vpp-dev/message/20862
Mute This Topic: https://lists.fd.io/mt/88418846/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS Tunnel Interface on Provider Router

[sreejithsurendrannair2]

Hi All,

I have a query regarding the IP and MPLS FIB counters. Is it possible to clear 
the fib counters for the individual FEC or local label  value.

In the below output if we want to clear the counter for 37.37.37.37/32, is 
there any CLI option to clear the same. I could not find any option to clear ip 
fib counter.

Logs:

IP FIB :
37.37.37.37/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:24 buckets:1 uRPF:19 to:[10:840]]
[0] [@11]: mpls-label[@1]:[36000:64:0:eos]
[@1]: mpls via 9.1.1.2 GigabitEthernet0/6/0.17512: mtu:1500 next:2 
525400b16c865254005b8a8681098847

Also in the code I saw the counter is reset during the "load_balance_alloc_i" I 
did not observe it reset in another place.

vlib_zero_combined_counter(&(load_balance_main.lbm_to_counters),
load_balance_get_index(lb));

Can you please suggest if I missed anything is there any CLI or API option to 
reset the IP FIB and MPLS FIB counters.

Thanks & Regards,
Sreejith

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20860): https://lists.fd.io/g/vpp-dev/message/20860
Mute This Topic: https://lists.fd.io/mt/88418846/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS Tunnel Interface on Provider Router

[Amit Mehra]

Thanks Neale for the clarification!!

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20750): https://lists.fd.io/g/vpp-dev/message/20750
Mute This Topic: https://lists.fd.io/mt/88418846/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS Tunnel Interface on Provider Router

[Neale Ranns]

From: vpp-dev@lists.fd.io  on behalf of Amit Mehra via 
lists.fd.io 
Date: Monday, 17 January 2022 at 09:30
To: vpp-dev@lists.fd.io 
Subject: Re: [vpp-dev] MPLS Tunnel Interface on Provider Router
Thanks Neale for the response.

We are trying to simulate L3VPN usecase and want to maintain counters per 
FEC(on both PE and P nodes).
Yes, we can achieve label swap/pop without tunnel interface too but that way we 
are not maintaining per FEC counters. As per my understanding, with tunnels, we 
can have counters per FEC.

VPP keeps counters for each entry in the MPLS table. Each entry represents a 
local label and so a FEC.


 forwarding:   mpls-neos-chain

  [@0]: dpo-load-balance: [proto:mpls index:21 buckets:1 uRPF:21 to:[0:0]]   
<<< Here at the end.

You can also get them from the stats segment.


I have few follow-up questions based on your responses

  1.  Are tunnel interfaces meant only for having statistics per FEC or are 
there any other usecase for creating mpls tunnel? In other words, we can 
achieve label encapsulation, label swap/pop operations without tunnel too then 
what's the need of having a tunnel?

Two reason of the top of my head;
1 – to change the topology of the network. For example the tunnel could be a 
link visible to the IGP
2 – to send a packet whose addresses are not understood by the network, i.e. v4 
packet over a v6 network.

2) As per the sample configuration of L3VPN given in 
https://wiki.fd.io/view/VPP/MPLS_FIB, tunnel interface is not considered. Any 
reason why tunnel interface is not considered for realizing L3VPN ? Does it 
have any other implication (if considered for L3VPN) or we can configure L3VPN 
even with tunnel interface (on both PE and P devices) too and it would be 
another alternative way?

Tunnels don’t scale. You can’t create as many tunnels as one might have routes 
in an L3VPN.

There are lots of good free resources on L3VPN architecture that can explain 
more than I will ever know 😉

/neale

Regards
Amit

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20743): https://lists.fd.io/g/vpp-dev/message/20743
Mute This Topic: https://lists.fd.io/mt/88418846/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS Tunnel Interface on Provider Router

[Amit Mehra]

Thanks Neale for the response.

We are trying to simulate L3VPN usecase and want to maintain counters per 
FEC(on both PE and P nodes).

Yes, we can achieve label swap/pop without tunnel interface too but that way we 
are not maintaining per FEC counters. As per my understanding, with tunnels, we 
can have counters per FEC.

I have few follow-up questions based on your responses
1) Are tunnel interfaces meant only for having statistics per FEC or are there 
any other usecase for creating mpls tunnel? In other words, we can achieve 
label encapsulation, label swap/pop operations without tunnel too then what's 
the need of having a tunnel?

2) As per the sample configuration of L3VPN given in 
https://wiki.fd.io/view/VPP/MPLS_FIB, tunnel interface is not considered. Any 
reason why tunnel interface is not considered for realizing L3VPN ? Does it 
have any other implication (if considered for L3VPN) or we can configure L3VPN 
even with tunnel interface (on both PE and P devices) too and it would be 
another alternative way?

Regards
Amit

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20730): https://lists.fd.io/g/vpp-dev/message/20730
Mute This Topic: https://lists.fd.io/mt/88418846/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] MPLS Tunnel Interface on Provider Router

[Neale Ranns]

Hi Amit,

From: vpp-dev@lists.fd.io  on behalf of Amit Mehra via 
lists.fd.io 
Date: Friday, 14 January 2022 at 12:50
To: vpp-dev@lists.fd.io 
Subject: [vpp-dev] MPLS Tunnel Interface on Provider Router

Hi,



I was doing a PoC to simulate label swap operation on Service Provider 
Router(non PE Routers) by creating a mpls tunnel interface and using that 
tunnel interface as a target in mpls route entry.



Reference:https://wiki.fd.io/view/VPP/MPLS_FIB



Please find below the set of configs that I tried and the corresponding 
observation with VPP 21.01



Config 1: Configured MPLS FIB entry without eos bit set.

mpls table add 0

set interface mpls GigabitEthernet0/6/0 enable--->Incoming 
Interface is GigabitEthernet0/6/0

set interface mpls GigabitEthernet0/7/0 enable--->Outgoing 
Interface is GigabitEthernet0/7/0

mpls tunnel add via 10.10.10.10 GigabitEthernet0/7/0 out-labels 44

set interface state mpls-tunnel0 up

mpls local-label add 33 via mpls-tunnel0



non-eos is the default when programming local-labels. In order to forward 
non-eos traffic the egress path must have output labels. This is so that the 
next label in the stack is not exposed, accidently, to the next/intermediate 
devices. If the next label in the stack is meant for the next downstream 
device, i.e. it is directly connected, then you must specify and out-label of 
implicit-null. i.e:

  mpls local-label add 33 non-eos via 0.0.0.0 mpls-tunnel0 out-labels 
implicit-null



Expectation:- On receiving an MPLS encapsulated label with in-label as 33 and 
without "eos" bit set, it should swap the label 33 with label 44 and send to 
it's neighbor i.e. 10.10.10.10 via GigabitEthernet0/7/0 interface.

Observation:- I am seeing the forwarding action as dpo-drop in mpls fib table. 
Please find the output of mplf-fib tables below

33:neos/21 fib:0 index:18 locks:2

  CLI refs:1 entry-flags:attached, src-flags:added,contributing,active,

path-list:[25] locks:2 flags:shared, uPRF-list:21 len:1 itfs:[96, ]

  path:[27] pl-index:25 mpls weight=1 pref=0 attached-nexthop:  
oper-flags:resolved, cfg-flags:attached,

2100::200:0:0:0 mpls-tunnel0 (p2p)

  [@0]: mpls via 0.0.0.0 mpls-tunnel0: mtu:9000 next:2

 stacked-on:

   [@2]: dpo-load-balance: [proto:mpls index:20 buckets:1 uRPF:-1 
to:[0:0]]

 [0] [@6]: mpls-label[@0]:[44:64:0:neos]

 [@1]: arp-mpls: via 10.10.10.10 GigabitEthernet0/7/0

 forwarding:   mpls-neos-chain

  [@0]: dpo-load-balance: [proto:mpls index:21 buckets:1 uRPF:21 to:[0:0]]

[0] [@0]: dpo-drop mpls



On receiving an MPLS packet, it is getting dropped in mpls-lookup node. Please 
find the vpp trace output below.



..snip…



Config 2:- Configured MPLS FIB entry with eos bit set.

mpls table add 0

set interface mpls GigabitEthernet0/6/0 enable--->Incoming 
Interface is GigabitEthernet0/6/0

set interface mpls GigabitEthernet0/7/0 enable--->Outgoing 
Interface is GigabitEthernet0/7/0

mpls tunnel add via 10.10.10.10 GigabitEthernet0/7/0 out-labels 44

set interface state mpls-tunnel0 up

mpls local-label add 33 eos via mpls-tunnel0



when programming eos routes, it is necessary for VPP to know what type of 
traffic is exposed when the label is popped. When programming via the API 
you’ll see that this is an input parameter. However, the CLI takes a shortcut 
and attempts to derive it from the next-hop address path. Your path though is 
attached (it doesn’t specify a next-hop) so this doesn’t work and the wheels 
fall off. If you change the CLI command to:

  mpls local-label add 33 eos via 0.0.0.0 mpls-tunnel0

it will work. Clearly that assumes IPv4 is being carried.





Expectation:- On receiving an MPLS encapsulated label with in-label as 33 and 
with "eos" bit set, it should swap the label 33 with label 44 and send to it's 
neighbor i.e. 10.10.10.10 via GigabitEthernet0/7/0 interface.

Observation:- Observing a crash in vpp on issuing the CLI "mpls local-label add 
33 eos via mpls-tunnel0". Is this some known issue?

The following is the stack trace



…snip…



The only difference between config 1 and config 2 was that of "eos" bit i.e. 
bit was set in the latter.



Config 3:- Also, I tried configuring PE Router by creating tunnel interface and 
used that interface as a target in IP Route.

Following is the config used.

mpls table add 0

set interface mpls GigabitEthernet0/6/0 enable--->Incoming 
Interface is GigabitEthernet0/6/0

set interface mpls GigabitEthernet0/7/0 enable--->Outgoing 
Interface is GigabitEthernet0/7/0

mpls tunnel add via 20.20.20.20 GigabitEthernet0/7/0 out-labels 44

set interface state mpls-tunnel0 up

ip route add 10.10.10.10/32 via mpls-tunnel0-->It seems to be 
working as expected



Expectation:- On receiving IP packet, it should be able t

[vpp-dev] MPLS Tunnel Interface on Provider Router

[Amit Mehra]

Hi,

I was doing a PoC to simulate label swap operation on Service Provider 
Router(non PE Routers) by creating a mpls tunnel interface and using that 
tunnel interface as a target in mpls route entry.

Reference:https://wiki.fd.io/view/VPP/MPLS_FIB

Please find below the set of configs that I tried and the corresponding 
observation with VPP 21.01

*Config 1:* Configured MPLS FIB entry without eos bit set.

mpls table add 0

set interface mpls GigabitEthernet0/6/0 enable--->Incoming 
Interface is GigabitEthernet0/6/0

set interface mpls GigabitEthernet0/7/0 enable--->Outgoing 
Interface is GigabitEthernet0/7/0

mpls tunnel add via 10.10.10.10 GigabitEthernet0/7/0 out-labels 44

set interface state *mpls-tunnel0* up

*mpls local-label add 33 via mpls-tunnel0*

*Expectation:-* On receiving an MPLS encapsulated label with in-label as 33 and 
without "eos" bit set, it should swap the label 33 with label 44 and send to 
it's neighbor i.e. 10.10.10.10 via GigabitEthernet0/7/0 interface.

*Observation:-* I am seeing the forwarding action as dpo-drop in mpls fib 
table. Please find the output of mplf-fib tables below

33:neos/21 fib:0 index:18 locks:2

CLI refs:1 entry-flags:attached, src-flags:added,contributing,active,

path-list:[25] locks:2 flags:shared, uPRF-list:21 len:1 itfs:[96, ]

path:[27] pl-index:25 mpls weight=1 pref=0 attached-nexthop:  
oper-flags:resolved, cfg-flags:attached,

2100::200:0:0:0 mpls-tunnel0 (p2p)

[@0]: mpls via 0.0.0.0 mpls-tunnel0: mtu:9000 next:2

stacked-on:

[@2]: dpo-load-balance: [proto:mpls index:20 buckets:1 uRPF:-1 to:[0:0]]

[0] [@6]: mpls-label[@0]:[44:64:0:neos]

[@1]: arp-mpls: via 10.10.10.10 GigabitEthernet0/7/0

forwarding:   mpls-neos-chain

[@0]: dpo-load-balance: [proto:mpls index:21 buckets:1 uRPF:21 to:[0:0]]

[0] [@0]: dpo-drop mpls

On receiving an MPLS packet, it is getting dropped in mpls-lookup node. Please 
find the vpp trace output below.

00:13:33:711978: *dpdk-input*

GigabitEthernet0/6/0 rx queue 0

buffer 0x5e3cc: current data 0, length 60, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x100

ext-hdr-valid

l4-cksum-computed l4-cksum-correct

PKT MBUF: port 0, nb_segs 1, pkt_len 60

buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr 0xbd8f380

packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0

rss 0x0 fdir.hi 0x0 fdir.lo 0x0

MPLS: 52:54:00:06:61:da -> 52:54:00:00:00:1a

label 33 exp 0, s 0, ttl 64

00:13:33:712035: *ethernet-input*

frame: flags 0x1, hw-if-index 1, sw-if-index 1

MPLS: 52:54:00:06:61:da -> 52:54:00:00:00:1a

00:13:33:712089: *mpls-input*

MPLS: next mpls-lookup[1]  label 33 ttl 64 exp 0

00:13:33:712100: *mpls-lookup*

MPLS: next [0], lookup fib index 0, LB index 21 hash 0 label 33 eos 0

00:13:33:712103: *mpls-drop*

drop

00:13:33:712105: *error-drop*

rx:GigabitEthernet0/6/0

00:13:33:712106: drop

mpls-input: MPLS DROP DPO

*Config 2:-* Configured MPLS FIB entry with eos bit set.

mpls table add 0

set interface mpls GigabitEthernet0/6/0 enable--->Incoming 
Interface is GigabitEthernet0/6/0

set interface mpls GigabitEthernet0/7/0 enable--->Outgoing 
Interface is GigabitEthernet0/7/0

mpls tunnel add via 10.10.10.10 GigabitEthernet0/7/0 out-labels 44

set interface state mpls-tunnel0 up

mpls local-label add 33 *eos* via mpls-tunnel0

*Expectation:-* On receiving an MPLS encapsulated label with in-label as 33 and 
with "eos" bit set, it should swap the label 33 with label 44 and send to it's 
neighbor i.e. 10.10.10.10 via GigabitEthernet0/7/0 interface.

*Observation:* - Observing a crash in vpp on issuing the CLI "mpls local-label 
add 33 eos via mpls-tunnel0". Is this some known issue?

The following is the stack trace

#0  __GI_raise (sig=sig@entry=6) at 
/usr/src/debug/glibc/2.31+gitAUTOINC+f84949f1c4-r0/git/sysdeps/unix/sysv/linux/raise.c:50

#1  0x0038bb625528 in __GI_abort () at 
/usr/src/debug/glibc/2.31+gitAUTOINC+f84949f1c4-r0/git/stdlib/abort.c:79

#2  0x0040857a in os_exit () at 
/usr/src/debug/vpp/21.01+gitAUTOINC+18aaa0b698-r0/git/src/vpp/vnet/main.c:433

#3  0x7f05d7fa6540 in unix_signal_handler (signum=11, si=, 
uc=)

at 
/usr/src/debug/vpp/21.01+gitAUTOINC+18aaa0b698-r0/git/src/vlib/unix/main.c:187

#4  

#5  0x7f05d8e813f0 in dpo_get_next_node 
(parent_dpo=parent_dpo@entry=0x7f05952468e8, child_proto=, 
child_proto@entry=16,

child_type=, child_type@entry=DPO_IP_NULL) at 
/usr/src/debug/vpp/21.01+gitAUTOINC+18aaa0b698-r0/git/src/vnet/dpo/dpo.c:441

#6  dpo_stack (child_type=child_type@entry=DPO_MPLS_DISPOSITION_PIPE, 
child_proto=child_proto@entry=DPO_PROTO_MPLS, dpo=dpo@entry=0x7f059861dbc0,

parent=parent@entry=0x7f05952468e8) at 
/usr/src/debug/vpp/21.01+gitAUTOINC+18aaa0b698-r0/git/src/vnet/dpo/dpo.c:526

#7  0x7f05d8ea0019 in mpls_disp_dpo_create 
(payload_proto=payload_proto@entry=DPO_PROTO_MPLS, 
rpf_id=rpf_id@entry=4294967295,

mode=mode@entry=FIB_MPLS_LSP_MODE_PIPE, parent=parent@entry=0x7

Re: [vpp-dev] mpls tunnel

[Neale Ranns via Lists.Fd.Io]

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 
Date: Thursday, 21 June 2018 at 17:26
To: "Neale Ranns (nranns)" , "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) 
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: mailto:vpp-dev@lists.fd.io>> on behalf of Gulakh 
mailto:holoogul...@gmail.com>>
Date: Wednesday, 20 June

Re: [vpp-dev] mpls tunnel

[Gulakh]

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/0Extensions: 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) 
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: * on behalf of Gulakh 
> *Date: *Wednesday, 20 June 2018 at 22:32
> *To: *"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*
>
&g

Re: [vpp-dev] mpls tunnel

[Neale Ranns via Lists.Fd.Io]

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:  on behalf of Gulakh 
Date: Wednesday, 20 June 2018 at 22:32
To: "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]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] mpls tunnel

[Gulakh]

Hi,
My topology is:

  *R1 (192.168.1.1/24 )*
<-->* R2 (192.168.1.2/24 )*

and *R1 loopback interface* has IP address of *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
*
*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  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
*
*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/0Extensions: 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 (#9656): https://lists.fd.io/g/vpp-dev/message/9656
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]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] mpls-tunnel

[Mehran Memarnejad]

Hi,
How can I create mpls-tunnel with arbitrary name?

thanks

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9588): https://lists.fd.io/g/vpp-dev/message/9588
Mute This Topic: https://lists.fd.io/mt/21999692/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] mpls tunnel in l2 mode del error

[薛欣颖]

Hi Neale，

After remove the tunnel from the bridge domain, the problem solved. 

Thanks,
Xyxue
From: Neale Ranns (nranns)
Date: 2017-12-13 17:33
To: 薛欣颖; vpp-dev
Subject: Re: [vpp-dev] mpls tunnel in l2 mode del error
Hi Xyxue,
 
Did you remove the tunnel from the bridge before it was deleted?
 
/neale
 
From:  on behalf of 薛欣颖 
Date: Wednesday, 13 December 2017 at 04:14
To: vpp-dev 
Subject: [vpp-dev] mpls tunnel in l2 mode del error
 
 
Hi guys,

I'm testing L2VPN. After I del the mpls tunnel ,there is a 'signal SIGABRT'. My 
configuration and more info is shown below:

configuration:
create host-interface name eth2 mac 00:0c:29:0f:e2:a8 
create host-interface name eth5 mac 00:0c:29:0f:e2:c6 
set interface state host-eth2 up 
set interface state host-eth5 up 
mpls table add 0 
set interface mpls host-eth2 enable 
set interface ip address host-eth2 14.1.1.2/24 
mpls local-label add non-eos 33 mpls-lookup-in-table 0 
create bridge-domain 1 
set interface l2 bridge host-eth5 1 
create mpls tunnel out-label 1023 out-label 1053 via 14.1.1.1 host-eth2 l2-only 
set interface l2 bridge mpls-tunnel0 1 
mpls local-label add eos 53 l2-input-on mpls-tunnel0 
set interface state mpls-tunnel0 up


Program received signal SIGABRT, Aborted. 
0x2b871bf02c37 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56 
56 ../nptl/sysdeps/unix/sysv/linux/raise.c:  
(gdb) bt 
#0 0x2b871bf02c37 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56 
#1 0x2b871bf06028 in __GI_abort () at abort.c:89 
#2 0x00406e8b in os_panic () at 
/home/VPP/build-data/../src/vpp/vnet/main.c:294 
#3 0x2b871b820b88 in debugger () at 
/home/VPP/build-data/../src/vppinfra/error.c:84 
#4 0x2b871b820f8f in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x2b871b462138 "%s:%d (%s) assertion `%s' fails") 
at /home/VPP/build-data/../src/vppinfra/error.c:143 
#5 0x2b871b14c2b0 in mpls_tunnel_tx (vm=0x2b871adab7e0 , 
node=0x2b871d024200, frame=0x2b871d8a7240) 
at /home/VPP/build-data/../src/vnet/mpls/mpls_tunnel.c:490 
#6 0x2b871ab2d178 in dispatch_node (vm=0x2b871adab7e0 , 
node=0x2b871d024200, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING, 
frame=0x2b871d8a7240, last_time_stamp=60292005734565) at 
/home/VPP/build-data/../src/vlib/main.c:1010 
#7 0x2b871ab2d75b in dispatch_pending_node (vm=0x2b871adab7e0 
, pending_frame_index=6, last_time_stamp=60292005734565) 
at /home/VPP/build-data/../src/vlib/main.c:1160 
#8 0x2b871ab2f90b in vlib_main_or_worker_loop (vm=0x2b871adab7e0 
, is_main=1) at /home/VPP/build-data/../src/vlib/main.c:1629 
#9 0x2b871ab2f9ba in vlib_main_loop (vm=0x2b871adab7e0 ) 
at /home/VPP/build-data/../src/vlib/main.c:1648 
#10 0x2b871ab30103 in vlib_main (vm=0x2b871adab7e0 , 
input=0x2b871ce96fb0) at /home/VPP/build-data/../src/vlib/main.c:1806 
#11 0x2b871ab72680 in thread0 (arg=47859271120864) at 
/home/VPP/build-data/../src/vlib/unix/main.c:617 
#12 0x2b871b835560 in clib_calljmp () at 
/home/VPP/build-data/../src/vppinfra/longjmp.S:128 
#13 0x7fffe00f3af0 in ?? () 
#14 0x2b871ab72b2a in vlib_unix_main (argc=4, argv=0x7fffe00f4d88) at 
/home/VPP/build-data/../src/vlib/unix/main.c:681 
#15 0x00406b67 in main (argc=4, argv=0x7fffe00f4d88) at 
/home/VPP/build-data/../src/vpp/vnet/main.c:233 
(gdb) 

Thanks,
Xyxue


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] mpls tunnel in l2 mode del error

[Neale Ranns (nranns)]

Hi Xyxue,

Did you remove the tunnel from the bridge before it was deleted?

/neale

From:  on behalf of 薛欣颖 
Date: Wednesday, 13 December 2017 at 04:14
To: vpp-dev 
Subject: [vpp-dev] mpls tunnel in l2 mode del error


Hi guys,

I'm testing L2VPN. After I del the mpls tunnel ,there is a 'signal SIGABRT'. My 
configuration and more info is shown below:

configuration:
create host-interface name eth2 mac 00:0c:29:0f:e2:a8
create host-interface name eth5 mac 00:0c:29:0f:e2:c6
set interface state host-eth2 up
set interface state host-eth5 up
mpls table add 0
set interface mpls host-eth2 enable
set interface ip address host-eth2 14.1.1.2/24
mpls local-label add non-eos 33 mpls-lookup-in-table 0
create bridge-domain 1
set interface l2 bridge host-eth5 1
create mpls tunnel out-label 1023 out-label 1053 via 14.1.1.1 host-eth2 l2-only
set interface l2 bridge mpls-tunnel0 1
mpls local-label add eos 53 l2-input-on mpls-tunnel0
set interface state mpls-tunnel0 up


Program received signal SIGABRT, Aborted.
0x2b871bf02c37 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c:
(gdb) bt
#0 0x2b871bf02c37 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x2b871bf06028 in __GI_abort () at abort.c:89
#2 0x00406e8b in os_panic () at 
/home/VPP/build-data/../src/vpp/vnet/main.c:294
#3 0x2b871b820b88 in debugger () at 
/home/VPP/build-data/../src/vppinfra/error.c:84
#4 0x2b871b820f8f in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x2b871b462138 "%s:%d (%s) assertion `%s' fails")
at /home/VPP/build-data/../src/vppinfra/error.c:143
#5 0x2b871b14c2b0 in mpls_tunnel_tx (vm=0x2b871adab7e0 , 
node=0x2b871d024200, frame=0x2b871d8a7240)
at /home/VPP/build-data/../src/vnet/mpls/mpls_tunnel.c:490
#6 0x2b871ab2d178 in dispatch_node (vm=0x2b871adab7e0 , 
node=0x2b871d024200, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING,
frame=0x2b871d8a7240, last_time_stamp=60292005734565) at 
/home/VPP/build-data/../src/vlib/main.c:1010
#7 0x2b871ab2d75b in dispatch_pending_node (vm=0x2b871adab7e0 
, pending_frame_index=6, last_time_stamp=60292005734565)
at /home/VPP/build-data/../src/vlib/main.c:1160
#8 0x2b871ab2f90b in vlib_main_or_worker_loop (vm=0x2b871adab7e0 
, is_main=1) at /home/VPP/build-data/../src/vlib/main.c:1629
#9 0x2b871ab2f9ba in vlib_main_loop (vm=0x2b871adab7e0 ) 
at /home/VPP/build-data/../src/vlib/main.c:1648
#10 0x2b871ab30103 in vlib_main (vm=0x2b871adab7e0 , 
input=0x2b871ce96fb0) at /home/VPP/build-data/../src/vlib/main.c:1806
#11 0x2b871ab72680 in thread0 (arg=47859271120864) at 
/home/VPP/build-data/../src/vlib/unix/main.c:617
#12 0x2b871b835560 in clib_calljmp () at 
/home/VPP/build-data/../src/vppinfra/longjmp.S:128
#13 0x7fffe00f3af0 in ?? ()
#14 0x2b871ab72b2a in vlib_unix_main (argc=4, argv=0x7fffe00f4d88) at 
/home/VPP/build-data/../src/vlib/unix/main.c:681
#15 0x00406b67 in main (argc=4, argv=0x7fffe00f4d88) at 
/home/VPP/build-data/../src/vpp/vnet/main.c:233
(gdb)

Thanks,
Xyxue

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] mpls tunnel in l2 mode del error

[薛欣颖]

Hi guys,

I'm testing L2VPN. After I del the mpls tunnel ,there is a 'signal SIGABRT'. My 
configuration and more info is shown below:

configuration:
create host-interface name eth2 mac 00:0c:29:0f:e2:a8 
create host-interface name eth5 mac 00:0c:29:0f:e2:c6 
set interface state host-eth2 up 
set interface state host-eth5 up 
mpls table add 0 
set interface mpls host-eth2 enable 
set interface ip address host-eth2 14.1.1.2/24 
mpls local-label add non-eos 33 mpls-lookup-in-table 0 
create bridge-domain 1 
set interface l2 bridge host-eth5 1 
create mpls tunnel out-label 1023 out-label 1053 via 14.1.1.1 host-eth2 l2-only 
set interface l2 bridge mpls-tunnel0 1 
mpls local-label add eos 53 l2-input-on mpls-tunnel0 
set interface state mpls-tunnel0 up


Program received signal SIGABRT, Aborted. 
0x2b871bf02c37 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56 
56 ../nptl/sysdeps/unix/sysv/linux/raise.c:  
(gdb) bt 
#0 0x2b871bf02c37 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56 
#1 0x2b871bf06028 in __GI_abort () at abort.c:89 
#2 0x00406e8b in os_panic () at 
/home/VPP/build-data/../src/vpp/vnet/main.c:294 
#3 0x2b871b820b88 in debugger () at 
/home/VPP/build-data/../src/vppinfra/error.c:84 
#4 0x2b871b820f8f in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x2b871b462138 "%s:%d (%s) assertion `%s' fails") 
at /home/VPP/build-data/../src/vppinfra/error.c:143 
#5 0x2b871b14c2b0 in mpls_tunnel_tx (vm=0x2b871adab7e0 , 
node=0x2b871d024200, frame=0x2b871d8a7240) 
at /home/VPP/build-data/../src/vnet/mpls/mpls_tunnel.c:490 
#6 0x2b871ab2d178 in dispatch_node (vm=0x2b871adab7e0 , 
node=0x2b871d024200, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING, 
frame=0x2b871d8a7240, last_time_stamp=60292005734565) at 
/home/VPP/build-data/../src/vlib/main.c:1010 
#7 0x2b871ab2d75b in dispatch_pending_node (vm=0x2b871adab7e0 
, pending_frame_index=6, last_time_stamp=60292005734565) 
at /home/VPP/build-data/../src/vlib/main.c:1160 
#8 0x2b871ab2f90b in vlib_main_or_worker_loop (vm=0x2b871adab7e0 
, is_main=1) at /home/VPP/build-data/../src/vlib/main.c:1629 
#9 0x2b871ab2f9ba in vlib_main_loop (vm=0x2b871adab7e0 ) 
at /home/VPP/build-data/../src/vlib/main.c:1648 
#10 0x2b871ab30103 in vlib_main (vm=0x2b871adab7e0 , 
input=0x2b871ce96fb0) at /home/VPP/build-data/../src/vlib/main.c:1806 
#11 0x2b871ab72680 in thread0 (arg=47859271120864) at 
/home/VPP/build-data/../src/vlib/unix/main.c:617 
#12 0x2b871b835560 in clib_calljmp () at 
/home/VPP/build-data/../src/vppinfra/longjmp.S:128 
#13 0x7fffe00f3af0 in ?? () 
#14 0x2b871ab72b2a in vlib_unix_main (argc=4, argv=0x7fffe00f4d88) at 
/home/VPP/build-data/../src/vlib/unix/main.c:681 
#15 0x00406b67 in main (argc=4, argv=0x7fffe00f4d88) at 
/home/VPP/build-data/../src/vpp/vnet/main.c:233 
(gdb) 

Thanks,
Xyxue


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] mpls tunnel configuration through JVPP

[Jozef Glončák]

After adding

mplsTunnelAddDel.mtSwIfIndex = 0;

still the same time out.


Jozef Glončák

Pantheon Technologies, s. r. o.



From: Neale Ranns (nranns) 
Sent: Friday, September 29, 2017 20:45
To: Jozef Glončák; vpp-dev@lists.fd.io
Subject: Re: mpls tunnel configuration through JVPP

Hi Jozef,

To what did you set: mt_sw_if_index ?  It should be ~0 on the creation of a new 
tunnel.

/neale

-Original Message-
From: Jozef Glončák 
Date: Friday, 29 September 2017 at 04:09
To: "vpp-dev@lists.fd.io" 
Cc: "Neale Ranns (nranns)" 
Subject: mpls tunnel configuration through JVPP

Hello Neale,

I need to do following configuration (VPP CLI)

>>>mpls tunnel add via 10.10.1.3 GigabitEthernet0/a/0 out-label 1003

through JVPP. I tried method

>>>FutureJVppCore.mplsTunnelAddDel()

with settings [1] but result was that request time outed with no error

[1]
mplsTunnelAddDel.mtIsAdd = 1;
mplsTunnelAddDel.mtNextHop = new byte[] {10,10,1,3};
mplsTunnelAddDel.mtNextHopNOutLabels = 1;
mplsTunnelAddDel.mtNextHopOutLabelStack = new int[] {1003};
mplsTunnelAddDel.mtNextHopProtoIsIp4 = 1;
mplsTunnelAddDel.mtNextHopSwIfIndex = 2; // index of 
GigabitEthernet0/a/0




 Jozef Glončák
 Pantheon Technologies, s. r. o.




___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] mpls tunnel configuration through JVPP

[Neale Ranns (nranns)]

Hi Jozef,

To what did you set: mt_sw_if_index ?  It should be ~0 on the creation of a new 
tunnel.

/neale

-Original Message-
From: Jozef Glončák 
Date: Friday, 29 September 2017 at 04:09
To: "vpp-dev@lists.fd.io" 
Cc: "Neale Ranns (nranns)" 
Subject: mpls tunnel configuration through JVPP

Hello Neale,

I need to do following configuration (VPP CLI)

>>>mpls tunnel add via 10.10.1.3 GigabitEthernet0/a/0 out-label 1003

through JVPP. I tried method 

>>>FutureJVppCore.mplsTunnelAddDel()

with settings [1] but result was that request time outed with no error

[1]
mplsTunnelAddDel.mtIsAdd = 1;
mplsTunnelAddDel.mtNextHop = new byte[] {10,10,1,3};
mplsTunnelAddDel.mtNextHopNOutLabels = 1;
mplsTunnelAddDel.mtNextHopOutLabelStack = new int[] {1003};
mplsTunnelAddDel.mtNextHopProtoIsIp4 = 1;
mplsTunnelAddDel.mtNextHopSwIfIndex = 2; // index of 
GigabitEthernet0/a/0



 
 Jozef Glončák
 Pantheon Technologies, s. r. o.
 
 
 

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] mpls tunnel configuration through JVPP

[Jozef Glončák]

Hello Neale,

I need to do following configuration (VPP CLI)

>>>mpls tunnel add via 10.10.1.3 GigabitEthernet0/a/0 out-label 1003

through JVPP. I tried method 

>>>FutureJVppCore.mplsTunnelAddDel()

with settings [1] but result was that request time outed with no error

[1]
mplsTunnelAddDel.mtIsAdd = 1;
mplsTunnelAddDel.mtNextHop = new byte[] {10,10,1,3};
mplsTunnelAddDel.mtNextHopNOutLabels = 1;
mplsTunnelAddDel.mtNextHopOutLabelStack = new int[] {1003};
mplsTunnelAddDel.mtNextHopProtoIsIp4 = 1;
mplsTunnelAddDel.mtNextHopSwIfIndex = 2; // index of 
GigabitEthernet0/a/0



 
 Jozef Glončák
 Pantheon Technologies, s. r. o.
 
 
 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev