Re: [vpp-dev] VXLAN Tunnel IF Names

[Neale Ranns (nranns)]

But all control planes need to know the sw_if_index provided by VPP as it is 
this value (and not the interface name) that one needs to subsequently 
configure the interface. So why the reliance of VPP’s given name? AFIAK VPP’s 
given name is only important when interpreting CLI output.
All control planes are free to choose whatever naming schemes they like, but 
they must maintain a control-plane-name to sw_if_index mapping. And to make VPP 
CLI output more useful, also maintain a control-plane-name to VPP-name mapping. 
In other words, X, is always the control-plane-name.

/neale


From: "John Lo (loj)" <l...@cisco.com>
Date: Wednesday, 7 February 2018 at 15:34
To: "Neale Ranns (nranns)" <nra...@cisco.com>, Jon Loeliger <j...@netgate.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] VXLAN Tunnel IF Names

I guess Jon’s point was the control plane need to know exactly what X would be 
and not rely on VPP to provide the sw_if_index or query VPP for the name after 
the VXLAN create request.  This makes the control plane CLI script/template 
support more straight forward.  In the case of mixed usage where a requested 
instance is not available, I wonder how control plane should handle the error 
condition if it does not check the result of the VXLAN create request…   -John

From: Neale Ranns (nranns)
Sent: Wednesday, February 07, 2018 5:55 AM
To: Jon Loeliger <j...@netgate.com>; John Lo (loj) <l...@cisco.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] VXLAN Tunnel IF Names

Hi Jon,

I feel I must ask ☺
“That  has to match a VPP interface by name.  But what name?”
why does it need to match a VPP interface name? shouldn’t  = MyVxlan23. Your 
control plane maintains mappings between MyVxlan23 and VPP’s sw_if_index.

/neale


From: <vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of Jon Loeliger <j...@netgate.com<mailto:j...@netgate.com>>
Date: Friday, 2 February 2018 at 22:08
To: "John Lo (loj)" <l...@cisco.com<mailto:l...@cisco.com>>
Cc: vpp-dev <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] VXLAN Tunnel IF Names

On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj) 
<l...@cisco.com<mailto:l...@cisco.com>> wrote:
Hi Jon,

Hi John,

Thanks for taking the time to get back to me on this!

All VPP tunnel creation uses the mechanism of returning a sw_if_index of the 
created tunnel.

I know.  I get that.  It works.

The name of the tunnel is then followed by a number being the instance or index 
to the tunnel struct vector. Thus, the first VXLAN tunnel created is called 
vxlan_tunnel0 followed by vxlan_tunnel1, etc. The number is incrementing unless 
tunnels are deleted and created again where a newly created tunnel will reuse 
the last deleted tunnel, hence its name. If all previously deleted tunnels are 
used up, then the tunnel name number will start incrementing again.

Right.

I am not sure if it is feasible to follow this behavior to “predict” tunnel 
name.

It is not.

The problem is not just "predict it", but the user has to be
able to know the associated SW IF name at the time that
the (vxlan tunnel) create API call happens.

The reason for that is because the very next thing the
API call user is going to want to do is configure that interface.
Short of interrogating the system, there is no way to know
the IF name.  (I understand that the name can be obtained
from the sw_if_index.  That's not what I mean.)

Consider this series of PEUDO API calls that are being
issued by some client front-end.  Think of this as a batch
of CLI commands:

vxlan MyVxlan23
source 1.2.3.4
destination 10.11.12.13
vni 19
exit

interface 
do stuff to interface like apply an ACL or whatever
exit

There is no way to batch-run those as there is a step
needed to determine what  is.  It could be "vxlan_tunnel..."
anything.

That  has to match a VPP interface by name.  But what name?
The entire transactional  history of VXLANs must be known in
order to guess the next name.

BTW, GRE tunnels are created and named the same way. You added TEB (transparent 
ethernet bridging) support to GRE. Have you not been using it and bothered by 
how to predict name of created GRE tunnels?

I've not touched GRE yet.  However, it is next on my list to fix!
My current plan is to submit essentially the same patch there too.

It is not a good idea to tie tunnel name to VNI as it is not a unique ID to 
identify VXLAN tunnels. It is quite common for existence of multiple VXLAN 
tunnels with the same VNI with different remote end point IP addresses. A 
bridge domain (BD) may have multiple VXLAN tunnels with the same VNI to several 
remote servers where the same overlay network exist. It is quite common to use 
the ID for BD or VLAN as the VNI for all its VXLAN tunnels to make it easie

Re: [vpp-dev] VXLAN Tunnel IF Names

[Neale Ranns (nranns)]

Hi Jon,

I feel I must ask ☺
“That  has to match a VPP interface by name.  But what name?”
why does it need to match a VPP interface name? shouldn’t  = MyVxlan23. Your 
control plane maintains mappings between MyVxlan23 and VPP’s sw_if_index.

/neale


From:  on behalf of Jon Loeliger 
Date: Friday, 2 February 2018 at 22:08
To: "John Lo (loj)" 
Cc: vpp-dev 
Subject: Re: [vpp-dev] VXLAN Tunnel IF Names

On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj) 
> wrote:
Hi Jon,

Hi John,

Thanks for taking the time to get back to me on this!

All VPP tunnel creation uses the mechanism of returning a sw_if_index of the 
created tunnel.

I know.  I get that.  It works.

The name of the tunnel is then followed by a number being the instance or index 
to the tunnel struct vector. Thus, the first VXLAN tunnel created is called 
vxlan_tunnel0 followed by vxlan_tunnel1, etc. The number is incrementing unless 
tunnels are deleted and created again where a newly created tunnel will reuse 
the last deleted tunnel, hence its name. If all previously deleted tunnels are 
used up, then the tunnel name number will start incrementing again.

Right.

I am not sure if it is feasible to follow this behavior to “predict” tunnel 
name.

It is not.

The problem is not just "predict it", but the user has to be
able to know the associated SW IF name at the time that
the (vxlan tunnel) create API call happens.

The reason for that is because the very next thing the
API call user is going to want to do is configure that interface.
Short of interrogating the system, there is no way to know
the IF name.  (I understand that the name can be obtained
from the sw_if_index.  That's not what I mean.)

Consider this series of PEUDO API calls that are being
issued by some client front-end.  Think of this as a batch
of CLI commands:

vxlan MyVxlan23
source 1.2.3.4
destination 10.11.12.13
vni 19
exit

interface 
do stuff to interface like apply an ACL or whatever
exit

There is no way to batch-run those as there is a step
needed to determine what  is.  It could be "vxlan_tunnel..."
anything.

That  has to match a VPP interface by name.  But what name?
The entire transactional  history of VXLANs must be known in
order to guess the next name.

BTW, GRE tunnels are created and named the same way. You added TEB (transparent 
ethernet bridging) support to GRE. Have you not been using it and bothered by 
how to predict name of created GRE tunnels?

I've not touched GRE yet.  However, it is next on my list to fix!
My current plan is to submit essentially the same patch there too.

It is not a good idea to tie tunnel name to VNI as it is not a unique ID to 
identify VXLAN tunnels. It is quite common for existence of multiple VXLAN 
tunnels with the same VNI with different remote end point IP addresses. A 
bridge domain (BD) may have multiple VXLAN tunnels with the same VNI to several 
remote servers where the same overlay network exist. It is quite common to use 
the ID for BD or VLAN as the VNI for all its VXLAN tunnels to make it easier to 
track their usage.

Excellent!  Thank you for this insight!  That makes total sense now!

I suppose it is feasible to provide another set of VXLAN tunnel create/delete 
API to allow caller to specify instance or number of the tunnel, similar to 
what you did for loopback interface.

This is the route I was headed:  Just like loopback interface naming!

In this case, the above example would be, perhaps, something like this:

vxlan MyVxlan23
instance 101
source 1.2.3.4
destination 10.11.12.13
vni 19
exit

interface vxlan_tunnel101
do stuff to interface like apply an ACL or whatever
exit

  One complication for the new API is that, upon VXLAN tunnel deletion, the 
interface created for the tunnel is not really deleted by the current code but 
put into a reuse pool.

I solved that by making a trivial  vxlan_name_renumber()  function,
and then calling vnet_interface_name_remumber(sw_if_index, instance)
to update the previously captured "vxlan_tunnel" name and rename
it using the new instance number.

When more tunnels are created, any interface from reuse pool with its existing 
interface name will be used for the new tunnel, before new interfaces are 
created. If a interface is reused upon tunnel creation, its interface name may 
not match the specified tunnel instance/number of the new tunnel creation API.  
One way to overcome this may be to not keep interface in reused pool on tunnel 
deletion. Thus, tunnel creation would always create new interface.  For 
backward compatibility, I suppose we can keep the tunnel create/delete API as 
is so interfaces of deleted tunnels are kept for reuse. The new API will then 
always create/delete interface on tunnel create/delete.  This would put a 
restriction that 

Re: [vpp-dev] Problem in forwarding multicast traffic

[Neale Ranns (nranns)]

Hi Juan,

When setting multicast routes one must specify the accepting (or RPF) interface 
for the prefix. So, additionally, you need;
   ip mroute add 224.0.0.5 via GigabitEthernet0/7/0 Accept

note though that while an interface can be configured to be both and accepting 
and forwarding interface (i.e. PIM BiDir) packets will not be replicated back 
out of the interface they came in on.

Regards,
Neale


From:  on behalf of Juan Salmon 

Date: Wednesday, 7 February 2018 at 06:59
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Problem in forwarding multicast traffic

Hi,
I want to forward multicast traffic with vpp, but after following commands, the 
multicast packet drop with ip4-drop.

ip mroute add 224.0.0.5 via GigabitEthernet0/7/0 Forward
ip mroute add 224.0.0.5 via GigabitEthernet0/8/0 Forward

The sample trace is:

00:27:52:305546: dpdk-input
  GigabitEthernet0/7/0 rx queue 0
  buffer 0x3492: current data 14, length 64, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x2
  PKT MBUF: port 0, nb_segs 1, pkt_len 78
buf_len 2176, data_len 78, ol_flags 0x0, data_off 128, phys_addr 0x7c3d24c0
packet_type 0x0
  IP4: 52:54:00:42:80:c8 -> 01:00:5e:00:00:05
  OSPF: 192.168.20.151 -> 224.0.0.5
tos 0xc0, ttl 1, length 64, checksum 0x6bc3
fragment id 0x979d
00:27:52:305566: ip4-input
  OSPF: 192.168.20.151 -> 224.0.0.5
tos 0xc0, ttl 1, length 64, checksum 0x6bc3
fragment id 0x979d
00:27:52:305570: ip4-mfib-forward-lookup
  fib 0 entry 6
00:27:52:305572: ip4-mfib-forward-rpf
  entry 6 1 Forward,
00:27:52:305572: ip4-drop
OSPF: 192.168.20.151 -> 224.0.0.5
  tos 0xc0, ttl 1, length 64, checksum 0x6bc3
  fragment id 0x979d
00:27:52:305574: error-drop
  ip4-input: ip4 adjacency drop


Best Regards,
Juan Salmon.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] New fd.io vpp project committer vote: Marco Varlese

[Neale Ranns (nranns)]

+1

From: <vpp-dev-boun...@lists.fd.io> on behalf of "Dave Barach (dbarach)" 
<dbar...@cisco.com>
Date: Tuesday, 6 February 2018 at 15:23
To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: [vpp-dev] New fd.io vpp project committer vote: Marco Varlese

Copying vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> to formally open the 
vote described below. Voting is limited to current committers, and will remain 
open for 1 week, or until folks have voted.

Thanks… Dave

From: Dave Barach (dbarach)
Sent: Tuesday, February 6, 2018 8:56 AM
To: Keith Burns (krb) <k...@cisco.com>; Florin Coras (fcoras) 
<fco...@cisco.com>; John Lo (loj) <l...@cisco.com>; Luke, Chris 
<chris_l...@comcast.com>; Damjan Marion (damarion) <damar...@cisco.com>; Neale 
Ranns (nranns) <nra...@cisco.com>; Ole Troan <o...@cisco.com>; Dave Wallace 
<dwallac...@gmail.com>; Ed Warnicke (eaw) <e...@cisco.com>
Subject: New Committer Nomination: Marco Varlese

Folks,

In view of significant code contributions to the vpp project – see below – I’m 
pleased to nominate Marco Varlese as a vpp project committer. I have high 
confidence that he’ll be a major asset to the project in a committer role.

Marco has contributed 46 merged patches, including significant new feature 
work.  Example: host stack implementation of SCTP, 8 KLOC 
https://gerrit.fd.io/r/#/c/9150. All merged patches: 
https://gerrit.fd.io/r/#/q/status:merged+owner:%22Marco+Varlese+%253Cmarco.varlese%2540suse.de%253E%22


Please vote (+1, 0, -1) on vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>. 
We’ll need a recorded vote so that the TSC will approve Marco’s nomination.

Thanks... Dave

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

Re: [vpp-dev] Consolidatation of fib_ip_proto() functions?

[Neale Ranns (nranns)]

Hi Jon,

I would welcome such a patch.

/neale

From: Jon Loeliger <j...@netgate.com>
Date: Thursday, 1 February 2018 at 17:18
To: vpp-dev <vpp-dev@lists.fd.io>, "Neale Ranns (nranns)" <nra...@cisco.com>
Subject: Consolidatation of fib_ip_proto() functions?

Neale,

I have need of using a function like fib_ip_proto(), below, in yet another file.
But rather than introduce a 5th copy of the same function, would you
accept a patch that consolidated them all into one static inline in, say,
fib_types.h where the FIB_PROTOCOL_* values are defined?

Thanks,
jdl


static inline fib_protocol_t
fib_ip_proto(bool is_ip6)
{
  return (is_ip6) ? FIB_PROTOCOL_IP6 : FIB_PROTOCOL_IP4;
}


jdl@bcc-1 $ git grep fib_ip_proto src/
src/plugins/gtpu/gtpu.c:fib_ip_proto (bool is_ip6)
src/plugins/gtpu/gtpu.c:  fib_protocol_t fp = fib_ip_proto (is_ip6);
src/plugins/gtpu/gtpu.c:  encap_fib_index = fib_table_find 
(fib_ip_proto (ipv6_set), tmp);
src/vnet/geneve/geneve.c:fib_ip_proto (bool is_ip6)
src/vnet/geneve/geneve.c: fib_protocol_t fp = fib_ip_proto (is_ip6);
src/vnet/geneve/geneve.c: encap_fib_index = fib_table_find 
(fib_ip_proto (ipv6_set), tmp);
src/vnet/vxlan-gpe/vxlan_gpe.c:fib_ip_proto (bool is_ip6)
src/vnet/vxlan-gpe/vxlan_gpe.c:   fib_protocol_t fp = fib_ip_proto (is_ip6);
src/vnet/vxlan/vxlan.c:fib_ip_proto(bool is_ip6)
src/vnet/vxlan/vxlan.c:  fib_protocol_t fp = fib_ip_proto(is_ip6);
src/vnet/vxlan/vxlan.c:encap_fib_index = fib_table_find (fib_ip_proto 
(ipv6_set), tmp);

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

Re: [vpp-dev] adding large number of route prefixes

[Neale Ranns (nranns)]

Hi Konrad,

As of 18.01 the amount of memory available for IP routes is controlled in the 
startup config with:
  ip {heap-size }

/neale

-Original Message-
From:  on behalf of Konrad Gutkowski 

Date: Thursday, 1 February 2018 at 03:01
To: vpp-dev 
Subject: [vpp-dev] adding large number of route prefixes

Hi,

While testing ipv4 routing I found that vpp crashes when supplied with  
large sets of prefixes, the exact point when vpp goes down changes  
depending on prefix set and vpp version tested.

Tried 17.10 and 18.01, first consistently crashes at around 1m (though  
tested only with sequential /24 and /32 prefixes), for the latter it  
depends on the set, for sequential it's around 390k, while public bgp  
table does crash pretty randomly around 100-300k, (my file has around 750k  
routes).

For 17.10, adding less than 1m prefixes works for both scenarios and  
continues working - adding and deleting it multiple times does not cause  
any stability issues.
It doesn't seem dependent on heap-size parameter value.

I used both cli "ip route add count" as well as modified router plugin to  
pull the table from netlink.
Any suggestions are welcome.

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


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

Re: [vpp-dev] Arp doesn't work after classifier configuration

[Neale Ranns (nranns)]

Hi Brindiya,

Could you please show me the output of:
  sh ip fib 6.6.6.1/32

Thanks,
neale

From:  on behalf of bindiya Kurle 

Date: Monday, 29 January 2018 at 10:04
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Arp doesn't work after classifier configuration

Hi,
my vpp version :
DBGvpp# show version
vpp v18.04-rc0~81-g18e955e .

I am observing whenever I do classifier configuration , arp resolution does not 
work

my configuration:

 set interface state GigabitEthernet1/0/1 up
set interface ip address GigabitEthernet1/0/1 6.6.6.1/24

classify table mask l3 ip4 src dst l4 udp src_port dst_port match 3
set ip classify intfc GigabitEthernet1/0/1 table-index 0


packet trace:
No packets in trace buffer
--- Start of thread 2 vpp_wk_1 ---
Packet 1
00:52:47:398359: dpdk-input
  GigabitEthernet1/0/1 rx queue 0
  buffer 0x2241e: current data 0, length 60, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
  PKT MBUF: port 1, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr 
0xee090800
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
Packet Offload Flags
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
  ARP: 54:ab:3a:79:85:41 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  54:ab:3a:79:85:41/6.6.6.10 -> 
ff:ff:ff:ff:ff:ff/6.6.6.1
00:52:47:398426: ethernet-input
  ARP: 54:ab:3a:79:85:41 -> ff:ff:ff:ff:ff:ff
00:52:47:398458: arp-input
  request, type ethernet/IP4, address size 6/4
  54:ab:3a:79:85:41/6.6.6.10 -> 
ff:ff:ff:ff:ff:ff/6.6.6.1
00:52:47:398497: error-drop
  arp-input: IP4 destination address not local to subnet

I saw similar issue raised in past vpp-455 but it was fixed long back all 
changes are there in the current code .

still I am seeing the issue .
Can anybody help me out with this issue?

Regards,
Bindiya




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

Re: [vpp-dev] Howto implement L3 p2p tunnel interface without assigning IP to the interface?

[Neale Ranns (nranns)]

Hi Andreas,

There are binary API equivalent messages to the CLI commands I gave.
For a non-interface based encap scheme you could reference as an example 
src/vnet/udp/udp_encap.[ch]. Not having an interface means there is no 
attachment point for features (like ACLs, NAT, etc) and you’ll need a 
do-it-yourself stats scheme.

/neale

From: Andreas Schultz <andreas.schu...@travelping.com>
Date: Friday, 26 January 2018 at 13:55
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, Ole Troan 
<otr...@employees.org>
Subject: Re: [vpp-dev] Howto implement L3 p2p tunnel interface without 
assigning IP to the interface?

Hi Neale,

Neale Ranns (nranns) <nra...@cisco.com<mailto:nra...@cisco.com>> schrieb am 
Fr., 26. Jan. 2018 um 11:27 Uhr:
Hi Andreas,

Ip[46]_sw_interface_enable_disable() are the internal APIs that enable/disable 
IP forwarding on an interface. There is an equivalent MPLS one too. The 
commands I listed previously are external means by which these internal APIs 
are invoked. It would not be acceptable to use these APIs to automatically IP 
enable GTP interfaces on interface creation.

The tunnels are not static, they are create through a management protocol over 
the 3GPP Sx reference point. Having to add manual configuration steps to make 
the tunnels work is not acceptable. So I have to use API's to setup things the 
ways I need them.
I'm not really sure the interface model is even correct my use case. I don't 
need to support L2 forwarding, so L2 bridging argument from the Wiki article 
does not apply.

Regards,
Andreas


Regards,
neale


From: Andreas Schultz 
<andreas.schu...@travelping.com<mailto:andreas.schu...@travelping.com>>
Date: Thursday, 25 January 2018 at 23:47
To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Cc: "Neale Ranns (nranns)" <nra...@cisco.com<mailto:nra...@cisco.com>>, Ole 
Troan <otr...@employees.org<mailto:otr...@employees.org>>
Subject: Re: [vpp-dev] Howto implement L3 p2p tunnel interface without 
assigning IP to the interface?

Ole Troan <otr...@employees.org<mailto:otr...@employees.org>> schrieb am Do., 
25. Jan. 2018 um 22:07 Uhr:
> Not accepting IP[46] packets on any interface type that is not IP[46] enabled 
> is a basic security feature. To IP4 enable an interface you have two option;
> 1)   Assign it an IP address
> 2)   Make it IP unnumbered to another interface that does have an 
> address, e.g.
> set int ip addr loop0 some-private-addr/32
> set int unnumbered gtpu-tunnel-0 use loop0
> set int unnumbered gtpu-tunnel-1 use loop0
> set int unnumbered gtpu-tunnel-2 use loop0
> etc…
> It doesn’t have to be a loopback, I use that only as an example.
>
> To IP6 enable an interface instead of the unnumbered trick one can just do;
> 1)   enable ip6 interface gtpu-tunnel0

Although all IPv6 interfaces by definition have an IPv6 address (the IPv6 
link-local) I do wonder if we shouldn't allow for IP processing to be enabled 
for both IP4 and IP6 independently of having an address configured. (Of course 
that would imply that some protocols wouldn't work.)

ip4_sw_interface_enable_disable() and/or ip6_sw_interface_enable_disable() did 
the trick. It works now without having to use the unnumbered option or having 
to assign a IPv4 address. I didn't check IPv6, though.

Thanks for the help,
Andreas

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

Re: [vpp-dev] Howto implement L3 p2p tunnel interface without assigning IP to the interface?

[Neale Ranns (nranns)]

Hi Andreas,

Ip[46]_sw_interface_enable_disable() are the internal APIs that enable/disable 
IP forwarding on an interface. There is an equivalent MPLS one too. The 
commands I listed previously are external means by which these internal APIs 
are invoked. It would not be acceptable to use these APIs to automatically IP 
enable GTP interfaces on interface creation.

Regards,
neale


From: Andreas Schultz <andreas.schu...@travelping.com>
Date: Thursday, 25 January 2018 at 23:47
To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Cc: "Neale Ranns (nranns)" <nra...@cisco.com>, Ole Troan <otr...@employees.org>
Subject: Re: [vpp-dev] Howto implement L3 p2p tunnel interface without 
assigning IP to the interface?

Ole Troan <otr...@employees.org<mailto:otr...@employees.org>> schrieb am Do., 
25. Jan. 2018 um 22:07 Uhr:
> Not accepting IP[46] packets on any interface type that is not IP[46] enabled 
> is a basic security feature. To IP4 enable an interface you have two option;
> 1)   Assign it an IP address
> 2)   Make it IP unnumbered to another interface that does have an 
> address, e.g.
> set int ip addr loop0 some-private-addr/32
> set int unnumbered gtpu-tunnel-0 use loop0
> set int unnumbered gtpu-tunnel-1 use loop0
> set int unnumbered gtpu-tunnel-2 use loop0
> etc…
> It doesn’t have to be a loopback, I use that only as an example.
>
> To IP6 enable an interface instead of the unnumbered trick one can just do;
> 1)   enable ip6 interface gtpu-tunnel0

Although all IPv6 interfaces by definition have an IPv6 address (the IPv6 
link-local) I do wonder if we shouldn't allow for IP processing to be enabled 
for both IP4 and IP6 independently of having an address configured. (Of course 
that would imply that some protocols wouldn't work.)

ip4_sw_interface_enable_disable() and/or ip6_sw_interface_enable_disable() did 
the trick. It works now without having to use the unnumbered option or having 
to assign a IPv4 address. I didn't check IPv6, though.

Thanks for the help,
Andreas

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

Re: [vpp-dev] Howto implement L3 p2p tunnel interface without assigning IP to the interface?

[Neale Ranns (nranns)]

Hi Andreas,

Not accepting IP[46] packets on any interface type that is not IP[46] enabled 
is a basic security feature. To IP4 enable an interface you have two option;

1)   Assign it an IP address

2)   Make it IP unnumbered to another interface that does have an address, 
e.g.
set int ip addr loop0 some-private-addr/32
set int unnumbered gtpu-tunnel-0 use loop0
set int unnumbered gtpu-tunnel-1 use loop0
set int unnumbered gtpu-tunnel-2 use loop0
etc…
It doesn’t have to be a loopback, I use that only as an example.

To IP6 enable an interface instead of the unnumbered trick one can just do;

1)   enable ip6 interface gtpu-tunnel0

hth
/neale

From:  on behalf of Andreas Schultz 

Date: Thursday, 25 January 2018 at 17:34
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Howto implement L3 p2p tunnel interface without assigning IP 
to the interface?

Hi,

Short story:

The VPP tunnel implementation HOWTO [1] says that a L3 tunnel needs an IP 
address. How do I implement a P2P tunnel interface without assigning an IP 
address to it?

Long story:

I'm implementing a GTP-U User Plane Node that conforms to 3GPP TS 29.244 [2] & 
[3]. For each Sx Session a VPP tunnel interface is created (a Sx Session can 
consist of multiple GTP tunnels that all belong to the same UE IP). A reverse 
route for the UE IP is inserted into the FIB pointing to the session tunnel 
interface.
So far this all works nicely. However when a GTP-U packet arrives, a trace 
shows that it is decapsulated, handed to ip4-input and the immediatly dropped 
without any error indication:

00:00:59:474894: ip4-udp-lookup
  UDP: src-port 2152 dst-port 2152
00:00:59:474902: gtpu4-input
  GTPU decap from gtpu_session0 teid 1 next 1 error 0
00:00:59:474942: ip4-input
  ICMP: 10.180.125.105 -> 8.8.8.8
tos 0x00, ttl 63, length 84, checksum 0xa484
fragment id 0xfef7, flags DONT_FRAGMENT
  ICMP echo_request checksum 0xc7d
00:00:59:475013: ip4-drop
ICMP: 10.180.125.105 -> 8.8.8.8
  tos 0x00, ttl 63, length 84, checksum 0xa484
  fragment id 0xfef7, flags DONT_FRAGMENT
ICMP echo_request checksum 0xc7d
00:00:59:475020: error-drop
  ip4-input: valid ip4 packets
I have traced the cause of the drop to vnet_feature_arc_start and from there to 
vnet_get_config_data. It turns out the IP feature is not configured on the 
ARC/sw_if_index combination.
When I manually add a IP address to the tunnel interface it starts to work.

I already looked at the PPPoE and the IPSec plugins, They must be doing 
something simmilar, but I can't spot the difference.

So how do I get the tunnel interface to work without having to add an IP 
address to it? Or, do I need to handle the input/decap chain differently?

My current code is at: 
https://github.com/RoadRunnr/vpp/tree/feature/gtp-dp/src/plugins/gtpdp

Thanks
Andreas

1: https://wiki.fd.io/view/VPP/How_to_add_a_tunnel_encapsulation
2: https://github.com/RoadRunnr/vpp/tree/feature/gtp-dp
3: 
http://www.etsi.org/deliver/etsi_ts/129200_129299/129244/14.01.00_60/ts_129244v140100p.pdf

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

Re: [vpp-dev] Re-verify a Commit?

[Neale Ranns (nranns)]

Hi Jon,

Leave a code review comment of:
  recheck

that will poke JJB to go do its thing again

/neale

From:  on behalf of Jon Loeliger 
Date: Tuesday, 23 January 2018 at 17:59
To: vpp-dev 
Subject: [vpp-dev] Re-verify a Commit?

Hey vpp-dev-iants,

How do I kick-off a re-verify request after a patch fails
to verify properly.  It is the mystery "unknown failure",
so we just need to try to rebuild it again.  Am I just
blindly missing a "reverify" button on an otherwise
inscrutable Gerrit page somewhere?

Thanks,
jdl

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

Re: [vpp-dev] VPP equivalent of the vrf commands in Cisco

[Neale Ranns (nranns)]

Hi Reza,

Can I refer you back to this previous thread;
  https://lists.fd.io/pipermail/vpp-dev/2017-August/006254.html

/neale

From:  on behalf of "mirzaei.reza" 

Date: Tuesday, 23 January 2018 at 09:27
To: Vpp Dev 
Subject: [vpp-dev] VPP equivalent of the vrf commands in Cisco


Hi
I want to know what is VPP equivalent of the "ip route vrf vrf_name" command in 
Cisco?
Also equivalent of these commands:
"ip vrf vrf_name"
"rd RD_value"
"route-target import vrf_name"

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

Re: [vpp-dev] MPLS-TP support

[Neale Ranns (nranns)]

Hi,

I am not aware of any effort now, nor in plan, for MPLS TP. Contributions are 
welcome ☺

Regards,
neale

-Original Message-
From:  on behalf of Алексей Болдырев 

Date: Friday, 19 January 2018 at 22:40
To: vpp-dev , vpp-dev-request 
Subject: [vpp-dev] MPLS-TP support

Please tell me if the MPLS-TP implementation is being implemented in the 
runway?

RFC:
https://tools.ietf.org/html/rfc5654
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


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

Re: [vpp-dev] Create an arc

[Neale Ranns (nranns)]

Hi Korian,

Ip4-rewrite does not do a full checksum calculation, it’s an ‘incremental’ 
update based on the fact only the TTL is decrementing – so the checksum on the 
packet must be correct on entry to this node. If your node runs before this, 
and modifies the header, it will need to do a checksum update. So, whether your 
nodes run before or after ip4-rewrite, two checksums will occur.

You mentioned before that your nodes need access to the TX interface – this is 
not necessarily known in (or just after) ip4-lookup. In ip4-lookup the result 
of the lookup is always a load_balance_t object, from which we select a bucket, 
and follow the arc according to the DPO type we find there, but that DPO type 
is not necessarily an adjacency and therefore one cannot necessarily derive 
from the DPO the TX interface. You’d have to walk down the DPO chain to do 
that. The point in the switch path when the adjacency is reached, and hence the 
TX interface known, is ip4-rewrite.

/neale

From: korian edeline <korian.edel...@ulg.ac.be>
Date: Thursday, 18 January 2018 at 14:41
To: "Dave Barach (dbarach)" <dbar...@cisco.com>, "Neale Ranns (nranns)" 
<nra...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Create an arc


Hello Neale, Dave,

@Neale

I would like to apply my modifications and let ip4-rewrite apply its, and 
compute the checksum (once). I don't want to replace it for the reason you 
cited (MTU, etc) .I don't want to put my node after ip4-rewrite, because i will 
apply my modifications, and have to recompute the checksum.

Just to clarify and be sure that i am not off topic: my first node is an 
extended version of the vnet/classify classifiers, the second one is a rewrite 
node based on the classifier matchings.

@Dave

This solution looks good to me. I'm going to give a try.

Thanks

Korian

On 01/18/2018 01:57 PM, Dave Barach (dbarach) wrote:

Here's one way to solve the problem, which should result in a patch we can 
merge:



  *   Add head-of-feature-arc processing to ip4/6_lookup_inline() under control 
of an integer argument [which will be passed as a constant 0 or 1].
  *   Create a couple of new nodes “ip4-lookup-with-post-lookup-arc” [or some 
better name] in ip4/6_forward.c, which instantiate the head of feature arc code
  *   Add the “…with-post-lookup-arc” nodes to the current pre-lookup rx 
feature arc, before the vanilla lookup nodes.
  *   Make the …with-post-lookup-arc” nodes siblings of the normal lookup 
nodes, so they inherit successor arcs/indices automatically.
  *   Add your node(s) to the post-lookup arc



To make traffic flow: enable the …with-post-lookup-arc nodes in the current rx 
feature arc AND enable your node(s) on the post-lookup arc



If done correctly, this should cost zero clock cycles in the speed path: a hard 
requirement.



HTH… D.



-Original Message-
From: korian edeline [mailto:korian.edel...@ulg.ac.be]
Sent: Thursday, January 18, 2018 6:37 AM
To: Neale Ranns (nranns) <nra...@cisco.com><mailto:nra...@cisco.com>; Dave 
Barach (dbarach) <dbar...@cisco.com><mailto:dbar...@cisco.com>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Create an arc



Hello Neale, Dave,



Thanks for your answers.



I would like to catch all (not on a prefix basis) traffic to-be-forwarded.

- I would need the TX sw_if_index, so i think the nodes should be placed after 
ip4-lookup.

- i have to be before ip4-rewrite, not to compute checksums 2 times.



Right now, my nodes are placed before lookup, via ip4-unicast feature arc and 
they can be enabled/disabled via vnet_feature_enable_disable.

Something similar, but after lookup, would be really convenient.



Regards,

Korian



On 01/18/2018 11:01 AM, Neale Ranns (nranns) wrote:

> Hi Korian,

>

> Constructing the VLIB graph between ipX-lookup and ipX-rewrite (and really to 
> interface-output) is best achieved by following the DPO architecture. You can 
> read a little about it here:

>https://wiki.fd.io/view/VPP/DPOs_and_Feature_Arcs

>

> Step one is to implement a new DPOs to represent your two new nodes. You’ll 
> find many examples of DPOs in vnet/dpo/*. Step 2 is then to ‘resolve’ the IP 
> prefix via your DPO. The means for that is, e.g, from vnet/bier/bier_table.c:

>

>  bt->bt_lfei = fib_table_entry_special_dpo_add(mpls_fib_index,

>,

>FIB_SOURCE_BIER,

>
> FIB_ENTRY_FLAG_EXCLUSIVE,

>);

>

> the rather badly named EXCLUSIVE flag means the caller is providing the DPO 
> and so FIB has no need to perform its usual resolution. The FIB_SOURCE_BIER 
> identifies ‘who’ is p

Re: [vpp-dev] Create an arc

[Neale Ranns (nranns)]

In order to prevent the calculation of the checksum twice your node would need 
to run instead of ip4-rewrite - is that your intention? – there’s quite a bit 
more going on in that node! If instead you want your node to run as well as 
ip4-rewrite, then it can be an output-feature (arc=ip4-output), where it will 
receive all packets egressing through that interface post rewrite encapsulation.

/neale


-Original Message-
From: korian edeline <korian.edel...@ulg.ac.be>
Date: Thursday, 18 January 2018 at 12:36
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "Dave Barach (dbarach)" 
<dbar...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Create an arc

Hello Neale, Dave,

Thanks for your answers.

I would like to catch all (not on a prefix basis) traffic to-be-forwarded.
- I would need the TX sw_if_index, so i think the nodes should be placed 
after ip4-lookup.
- i have to be before ip4-rewrite, not to compute checksums 2 times.

Right now, my nodes are placed before lookup, via ip4-unicast feature 
arc and they can be enabled/disabled via vnet_feature_enable_disable. 
Something similar, but after lookup, would be really convenient.

    Regards,
    Korian

On 01/18/2018 11:01 AM, Neale Ranns (nranns) wrote:
> Hi Korian,
>
> Constructing the VLIB graph between ipX-lookup and ipX-rewrite (and 
really to interface-output) is best achieved by following the DPO architecture. 
You can read a little about it here:
>https://wiki.fd.io/view/VPP/DPOs_and_Feature_Arcs
>
> Step one is to implement a new DPOs to represent your two new nodes. 
You’ll find many examples of DPOs in vnet/dpo/*. Step 2 is then to ‘resolve’ 
the IP prefix via your DPO. The means for that is, e.g, from 
vnet/bier/bier_table.c:
>
>  bt->bt_lfei = fib_table_entry_special_dpo_add(mpls_fib_index,
>,
>FIB_SOURCE_BIER,
>
FIB_ENTRY_FLAG_EXCLUSIVE,
>);
>
> the rather badly named EXCLUSIVE flag means the caller is providing the 
DPO and so FIB has no need to perform its usual resolution. The FIB_SOURCE_BIER 
identifies ‘who’ is providing the forwarding information (the DPO) and thus the 
relative priority of that information. There is a simple linear priority scheme 
among the sources enumerated by fib_source_t.
> Step 3 is to ‘stack’ your DPOs, i.e. to form the chain/graph that will be 
followed in the data-plane. The FIB API above automatically stacks the 
load_balance_t DPO (which is the result of the lookup) on your DPO passed.
>
> note that the above provides you with ‘override’ semantics, i.e. for a 
given prefix you can override (assuming your source has higher priority) the 
existing forwarding information for that prefix. If instead your requirements 
are to apply further rules/checks/replications on the packets before they are 
forwarded using the existing information, then this is what I call 
‘interposition’. I have an outstanding patch for this:
>https://gerrit.fd.io/r/#/c/9336/
> I’ll try and get it finished soon.
>
> The last issue to consider is whether your override or interposition 
needs to affect only the prefix you specify in the call to 
fib_table_entry_special_dpo_add() or to all longer mask prefixes that it 
covers. For example, if you specify 10.0.0.0/24, and some other source 
specifies 10.0.0.0/25 and 10.128.0.0/25 then your prefix is never matched. In 
order to ‘push’ your forwarding down to all longer mask prefixes in the 
sub-tree one needs to explicitly specify this. Again, this is an outstanding 
patch:
>   https://gerrit.fd.io/r/#/c/9477/
>
>
> Having said all that, if what you are after Is not running your feature 
on a per-prefix basis, but instead on a per-output interface basis, then you 
want the ip4-output feature arc ☺
>
> hth,
> neale
>
>
> -Original Message-
> From: "Dave Barach (dbarach)" <dbar...@cisco.com>
> Date: Wednesday, 17 January 2018 at 16:21
> To: korian edeline <korian.edel...@ulg.ac.be>, "vpp-dev@lists.fd.io" 
<vpp-dev@lists.fd.io>, "Neale Ranns (nranns)" <nra...@cisco.com>
> Subject: RE: [vpp-dev] Create an arc
>
>  Dear Korian,
>  
>  Steering traffic from ip4_lookup to  is easily 
accomplished by setting the fib result [dpo->dpoi_next_node] to send matching 
traffic where you want it to go.
>  
>  Add an arc from ip4/6_lookup to  by

Re: [vpp-dev] Create an arc

[Neale Ranns (nranns)]

Hi Korian,

Constructing the VLIB graph between ipX-lookup and ipX-rewrite (and really to 
interface-output) is best achieved by following the DPO architecture. You can 
read a little about it here:
  https://wiki.fd.io/view/VPP/DPOs_and_Feature_Arcs

Step one is to implement a new DPOs to represent your two new nodes. You’ll 
find many examples of DPOs in vnet/dpo/*. Step 2 is then to ‘resolve’ the IP 
prefix via your DPO. The means for that is, e.g, from vnet/bier/bier_table.c:

bt->bt_lfei = fib_table_entry_special_dpo_add(mpls_fib_index,
  ,
  FIB_SOURCE_BIER,
  FIB_ENTRY_FLAG_EXCLUSIVE,
  );

the rather badly named EXCLUSIVE flag means the caller is providing the DPO and 
so FIB has no need to perform its usual resolution. The FIB_SOURCE_BIER 
identifies ‘who’ is providing the forwarding information (the DPO) and thus the 
relative priority of that information. There is a simple linear priority scheme 
among the sources enumerated by fib_source_t.
Step 3 is to ‘stack’ your DPOs, i.e. to form the chain/graph that will be 
followed in the data-plane. The FIB API above automatically stacks the 
load_balance_t DPO (which is the result of the lookup) on your DPO passed.

note that the above provides you with ‘override’ semantics, i.e. for a given 
prefix you can override (assuming your source has higher priority) the existing 
forwarding information for that prefix. If instead your requirements are to 
apply further rules/checks/replications on the packets before they are 
forwarded using the existing information, then this is what I call 
‘interposition’. I have an outstanding patch for this:
  https://gerrit.fd.io/r/#/c/9336/
I’ll try and get it finished soon.

The last issue to consider is whether your override or interposition needs to 
affect only the prefix you specify in the call to 
fib_table_entry_special_dpo_add() or to all longer mask prefixes that it 
covers. For example, if you specify 10.0.0.0/24, and some other source 
specifies 10.0.0.0/25 and 10.128.0.0/25 then your prefix is never matched. In 
order to ‘push’ your forwarding down to all longer mask prefixes in the 
sub-tree one needs to explicitly specify this. Again, this is an outstanding 
patch:
 https://gerrit.fd.io/r/#/c/9477/


Having said all that, if what you are after Is not running your feature on a 
per-prefix basis, but instead on a per-output interface basis, then you want 
the ip4-output feature arc ☺

hth,
neale


-Original Message-
From: "Dave Barach (dbarach)" <dbar...@cisco.com>
Date: Wednesday, 17 January 2018 at 16:21
To: korian edeline <korian.edel...@ulg.ac.be>, "vpp-dev@lists.fd.io" 
<vpp-dev@lists.fd.io>, "Neale Ranns (nranns)" <nra...@cisco.com>
Subject: RE: [vpp-dev] Create an arc

Dear Korian,

Steering traffic from ip4_lookup to  is easily accomplished by 
setting the fib result [dpo->dpoi_next_node] to send matching traffic where you 
want it to go. 

Add an arc from ip4/6_lookup to  by calling 
vlib_node_add_next(...) to create the arc, then create fib entries with 
dpoi_next_node set to the returned next_index.

This is not a feature arc problem. Attempting to solve it as such will 
cause no end of trouble. 

Neale, please jump in as needed...

HTH... Dave

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of korian edeline
Sent: Wednesday, January 17, 2018 9:30 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Create an arc

Hi all,

Here is the deal:

I have 2 nodes (my-node-1, my-node-2),  I would like my-node-1 to receive 
packets from ip4-lookup, forwarding to either ip4-rewrite, error-drop or 
my-node-2. my-node-2 should only receive from my-node-1 and forward to 
ip4-rewrite or error-drop.

If I put them BEFORE ip4-lookup, i can use pre-built arc ip4-unicast and 
everything works perfect. But i figured that if i want them after ip4-lookup, i 
have to create my own arc. So here is what i have, plus replacing occurences of 
"ip4-unicast" by "my-arc".

VNET_FEATURE_ARC_INIT (my_arc, static) = {
   .arc_name = "my-arc,
   .start_nodes = VNET_FEATURES ("ip4-lookup"),
   .arc_index_ptr = _main.feature_arc_index };

What am i missing  ?

Thanks

Korian

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


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

Re: [vpp-dev] How can i setup multi-vrf mpls configuration in vpp?

[Neale Ranns (nranns)]

Hi Reza,

I would suggest you start with this:
  https://wiki.fd.io/view/VPP/MPLS_FIB

and then if you’ve further questions, perhaps a diagram outlining what you 
would like to configure.

Regards,
neale

From:  on behalf of "mirzaei.reza" 

Date: Wednesday, 17 January 2018 at 10:50
To: Vpp Dev 
Subject: [vpp-dev] How can i setup multi-vrf mpls configuration in vpp?


Hi

I want to know how can i setup multi-vrf mpls configuration in vpp? Is there 
any documents that describe this matter?

Best regards

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

Re: [vpp-dev] question about load balance

[Neale Ranns (nranns)]

You could also try adjusting in vnet/dpo/load_balance.c:

/*
* distribution error tolerance for load-balancing
*/
const f64 multipath_next_hop_error_tolerance = 0.1;

to a lower values, until it meets your needs.
Note this value is not exposed to the CLI/API for adjustment.

/neale

From: "Pierre Pfister (ppfister)" <ppfis...@cisco.com>
Date: Wednesday, 10 January 2018 at 10:39
To: 薛欣颖 <xy...@fiberhome.com>
Cc: "Neale Ranns (nranns)" <nra...@cisco.com>, vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] question about load balance

Hello,

You will not be able to get an exact match on 1/3 - 2/3 traffic sharing since 3 
is not a power of two.
If you want to get something closer, you may try to increase the values to get 
a better approximation.

For instance, 43 and 85 have a sum of 128 with 43/128 = 0.3359375, which is 
close to the 0.3 you are looking for.

- Pierre



Le 10 janv. 2018 à 07:36, 薛欣颖 <xy...@fiberhome.com<mailto:xy...@fiberhome.com>> 
a écrit :


Hi Neale,

I know what you mean.
What should I do to match exactly I configured?  And ignore constraints 'a 
load-balance is always a power of 2'.

Thanks,
Xyxue

From: Neale Ranns (nranns)<mailto:nra...@cisco.com>
Date: 2018-01-09 20:58
To: 薛欣颖<mailto:xy...@fiberhome.com>; vpp-dev<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] question about load balance
Hi Xyxue,

It does match your configuration. You requested a 2:1 ratio un-equal cost load 
balancing, you got a 5:3, which VPP considers to be close enough. It’s not 
exact because the number of buckets in a load-balance is always a power of 2.

/neale

From: <vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of 薛欣颖 <xy...@fiberhome.com<mailto:xy...@fiberhome.com>>
Date: Tuesday, 9 January 2018 at 12:26
To: vpp-dev <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] question about load balance


Hi guys,

I'm testing routing load balance. There is a question : When I configured 1:2 , 
the actual effect 3:5. My configuration and more info is shown below:

configuration:
  ip route add 4.1.1.1/24 via ip4-address 1.1.1.2 interface host-eth0 weight 1
  ip route add 4.1.1.1/24 via ip4-address 2.1.1.2 interface host-eth4 weight 2

The actual effect:
4.1.1.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:22 buckets:8 uRPF:29 to:[0:0]]
[0] [@5]: ipv4 via 2.1.1.2 host-eth4: 000c296db08c2c534a0393540800
[1] [@5]: ipv4 via 2.1.1.2 host-eth4: 000c296db08c2c534a0393540800
[2] [@5]: ipv4 via 2.1.1.2 host-eth4: 000c296db08c2c534a0393540800
[3] [@5]: ipv4 via 2.1.1.2 host-eth4: 000c296db08c2c534a0393540800
[4] [@5]: ipv4 via 2.1.1.2 host-eth4: 000c296db08c2c534a0393540800
[5] [@5]: ipv4 via 1.1.1.2 host-eth0: 000c296db078fc4dd4dad8af0800
[6] [@5]: ipv4 via 1.1.1.2 host-eth0: 000c296db078fc4dd4dad8af0800
[7] [@5]: ipv4 via 1.1.1.2 host-eth0: 000c296db078fc4dd4dad8af0800

How can I make  the actual effect the  same as my configuration?

Thanks,
Xyxue

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

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

Re: [vpp-dev] question about load balance

[Neale Ranns (nranns)]

Hi Xyxue,

It does match your configuration. You requested a 2:1 ratio un-equal cost load 
balancing, you got a 5:3, which VPP considers to be close enough. It’s not 
exact because the number of buckets in a load-balance is always a power of 2.

/neale

From:  on behalf of 薛欣颖 
Date: Tuesday, 9 January 2018 at 12:26
To: vpp-dev 
Subject: [vpp-dev] question about load balance


Hi guys,

I'm testing routing load balance. There is a question : When I configured 1:2 , 
the actual effect 3:5. My configuration and more info is shown below:

configuration:
  ip route add 4.1.1.1/24 via ip4-address 1.1.1.2 interface host-eth0 weight 1
  ip route add 4.1.1.1/24 via ip4-address 2.1.1.2 interface host-eth4 weight 2

The actual effect:
4.1.1.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:22 buckets:8 uRPF:29 to:[0:0]]
[0] [@5]: ipv4 via 2.1.1.2 host-eth4: 000c296db08c2c534a0393540800
[1] [@5]: ipv4 via 2.1.1.2 host-eth4: 000c296db08c2c534a0393540800
[2] [@5]: ipv4 via 2.1.1.2 host-eth4: 000c296db08c2c534a0393540800
[3] [@5]: ipv4 via 2.1.1.2 host-eth4: 000c296db08c2c534a0393540800
[4] [@5]: ipv4 via 2.1.1.2 host-eth4: 000c296db08c2c534a0393540800
[5] [@5]: ipv4 via 1.1.1.2 host-eth0: 000c296db078fc4dd4dad8af0800
[6] [@5]: ipv4 via 1.1.1.2 host-eth0: 000c296db078fc4dd4dad8af0800
[7] [@5]: ipv4 via 1.1.1.2 host-eth0: 000c296db078fc4dd4dad8af0800

How can I make  the actual effect the  same as my configuration?

Thanks,
Xyxue

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

Re: [vpp-dev] mpls routing

[Neale Ranns (nranns)]

Hi Holoo,

I see nothing wrong with your VPP config. So please collect a packet trace and 
the output of:
   sh mpls fib 400

Thanks,
neale

From:  on behalf of Holoo Gulakh 

Date: Tuesday, 26 December 2017 at 17:39
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] mpls routing

Hi,

I want to test a scenario in which I have two host and a VPP router.
   
host1(10.0.10.2)<-->(10.0.10.1)(Gb4/0/0)VPP(Gbb/0/0)(10.0.20.1)<-->(10.0.20.2)host2

host1 and host2 are two mpls-enabled ubuntu server.
Goal: To ping host1 from host2 using mpls label
=
VPP version: 18.01
ubuntu server : 16.04

In this scenario host2 should put a label 400 on packet and then VPP router 
should pop the label and then send it to host1.

I enter below command in host2:
  ip route add 10.0.10.2/32 encap mpls 400 via inet 
10.0.20.1
and I enter below command in VPP router:
  mpls table add 0
  set int mpls GigabitEthernet4/0/0 enable
  set int mpls GigabitEthernetb/0/0 enable
  mpls local-label 400 via 10.0.10.1 GigabitEthernet4/0/0

What happens:
===
host2 sends out packet with label 400 and VPP router gets it. but host1 does 
not get any packet.
I guess something wrong happen in VPP..

** What is wrong with my configuration??
** How should I configure hosts and VPP??
please help me with other scenarios that use:
1-mpls pop  2- mpls push   3- mpls swap
thanks in advance
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] gerrit 9904 VIRL verification is failing

[Neale Ranns (nranns)]

Hi Nitin,

Hit the ‘reply’ button and post a review comment of:
  recheck

that will poke Jenkins to redo the verification.

/neale

-Original Message-
From:  on behalf of "Saxena, Nitin" 

Date: Wednesday, 27 December 2017 at 14:38
To: "Dave Barach (dbarach)" , "vpp-dev@lists.fd.io" 

Subject: [vpp-dev] gerrit 9904 VIRL verification is failing

Hi,

I sent a patch (https://gerrit.fd.io/r/#/c/9904/) for review in which 
"vpp-csit-verify-virl-master" job is failing. 

Console logs 
(https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-csit-verify-virl-master/8798/console.log.gz)
 shows following error. 


call_home\nFlmClientException: Cisco contact was not established. This may 
be temporary.\nPlease make sure the VIRL server is connected to the Internet 
and capable of reaching the configured Cisco master.\nAlso make sure that the 
minion key provided to you matches your minion ID and domain, and remains 
valid.\nCurrent status is: Last successful contact was more than 7 days 
ago.\nLast call home check result was: Call has timed out; failed to connect or 
minion key not accepted.\n"
}

+ VIRL_SID[${index}]=
+ retval=1
+ '[' 1 -ne 0 ']'
+ echo 'VIRL simulation start failed on 10.30.51.29'
VIRL simulation start failed on 10.30.51.29
===

Seems like a temporary problem. What is the gerrit command such that 
Jenkins again start doing verification.

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


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

Re: [vpp-dev] Need Help on an ipsec Problem

[Neale Ranns (nranns)]

Hi Bin,

That looks like a FIB entry caused by there being an ARP entry for 172.28.128.4 
on GigE0/8/0. Is that true?

and it looks like from your trace that 172.28.128.4 is the tunnel endpoint. You 
don’t want to route packets to the tunnel’s destination via the tunnel…

thanks,
neale

From: "Bin Zhang (binzhang)" <binzh...@cisco.com>
Date: Tuesday, 19 December 2017 at 02:28
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Need Help on an ipsec Problem

Hi Neale,

Many thanks for the help.  You are right that I did not enable/configure the 
ipsec tunnel.  I encountered a new problem after I fixed that.  I think I still 
miss some config to make this ipsec tunnel to work on both directions. I 
received the echo reply from the destination, but vpp did not push the packet 
into the tunnel. After the ip4 look up, it went to the rewirte and tx.  How do 
I configure the tunnel interface (or routing table) to make the packet to go 
into the tunnel?

DBGvpp# show ip fib
..
172.28.128.4/32 – all the packet to this interface should be pushed to the 
tunnel
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:20 to:[9:1224] 
via:[1:84]]
[0] [@5]: ipv4 via 172.28.128.4 GigabitEthernet0/8/0: 
08002773718f08002794519e0800
..


DBGvpp# show trace
--- Start of thread 0 vpp_main ---
Packet 1

06:54:53:849574: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x1 len 98 snaplen 98 mac 66 net 80
  sec 0x5a386454 nsec 0x34d90965 vlan 0 vlan_tpid 0
06:54:53:849585: ethernet-input
  IP4: 4e:9a:96:eb:16:33 -> 02:fe:f1:95:12:6c
06:54:53:849593: ip4-input
  ICMP: 151.1.1.2 -> 172.28.128.4
tos 0x00, ttl 64, length 84, checksum 0x468d
fragment id 0x6ff8
  ICMP echo_reply checksum 0x91d6
06:54:53:849596: ip4-lookup
  fib 0 dpo-idx 3 flow hash: 0x
  ICMP: 151.1.1.2 -> 172.28.128.4
tos 0x00, ttl 64, length 84, checksum 0x468d
fragment id 0x6ff8
  ICMP echo_reply checksum 0x91d6
06:54:53:849600: ip4-rewrite
  tx_sw_if_index 1 dpo-idx 3 : ipv4 via 172.28.128.4 GigabitEthernet0/8/0: 
08002773718f08002794519e0800 flow hash: 0x
  : 08002773718f08002794519e080045546ff83f01478d97010102ac1c
  0020: 800491d60d815464385a08170d001011
06:54:53:849604: GigabitEthernet0/8/0-output
  GigabitEthernet0/8/0
  IP4: 08:00:27:94:51:9e -> 08:00:27:73:71:8f
  ICMP: 151.1.1.2 -> 172.28.128.4
tos 0x00, ttl 63, length 84, checksum 0x478d
fragment id 0x6ff8
  ICMP echo_reply checksum 0x91d6
06:54:53:849609: GigabitEthernet0/8/0-tx
  GigabitEthernet0/8/0 tx queue 0
  buffer 0xd10f: current data 0, length 98, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  IP4: 08:00:27:94:51:9e -> 08:00:27:73:71:8f
  ICMP: 151.1.1.2 -> 172.28.128.4
tos 0x00, ttl 63, length 84, checksum 0x478d
fragment id 0x6ff8
  ICMP echo_reply checksum 0x91d6

Thanks in advance,

Bin


From: "Neale Ranns (nranns)" <nra...@cisco.com>
Date: Sunday, December 17, 2017 at 8:07 AM
To: "Bin Zhang (binzhang)" <binzh...@cisco.com>, "vpp-dev@lists.fd.io" 
<vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Need Help on an ipsec Problem

Hi Bin,

I expect your IPsec tunnel is not enabled/configured to accept IPv4 packets.
Do:
  sh int featuee 

and if you see:
ip4-unicast:
  ip4-drop

then the tunnel is configured to drop all IPv4 packets.
In order to enable any interface to receive IP it must either have an IP 
address applied;
  set int ip addr  p.q.r.s/t
Or be unnumbered to another interface that has one;
  set int ip addr  p.q.r.s/t
  set int unnumbered  use 

/neale

From: <vpp-dev-boun...@lists.fd.io> on behalf of "Bin Zhang (binzhang)" 
<binzh...@cisco.com>
Date: Friday, 15 December 2017 at 23:04
To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: [vpp-dev] Need Help on an ipsec Problem

Hi Team,

I am new to VPP and would appreciate your comments and debugging tips on the 
following problem.

I have set up an ipsec tunnel between two VMs (as shown in the diagram).  The 
client side is Strongswan and the server side is VPP.  But I can not ping 
through the tunnel from the client VM (on the left) to the subnet in the VPP VM 
(on the right).  In other words, “ping 151.1.1.2” failed.  The packet is 
dropped by VPP.

I used gdb to track the code execution.  The “next index” was changed from 2 
(IP4_INPUT_NEXT_LOOKUP) to 5 (IP4_INPUT_N_NEXT) in function 
vnet_get_config_data.



  /* Last 32 bits are next index. */

  *next_index = d[n];


How do I move forward with my investigation?

More info:
[1] Packet trace of the ping packet.  As we can see, the de-tunneling worked 
and the (inner) ICMP packet was moved to ip4-input.  But it was then dropped.
00:12:16:877859: dpdk-input
  Giga

Re: [vpp-dev] a problem about dhcp

[Neale Ranns (nranns)]

Hi Xyxue,

Please file a JIRA ticket at:
  https://jira.fd.io/secure/Dashboard.jspa

/neale

From:  on behalf of 薛欣颖 
Date: Saturday, 16 December 2017 at 07:26
To: vpp-dev 
Subject: [vpp-dev] a problem about dhcp


Hi guys,

I'm testing the dhcp function. There is a problem : when I delete the dhcp 
client, the address del success, but there is no 'release message' to server.

Is there a plan to solve this problem?

Thanks,
Xyxue

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

Re: [vpp-dev] mpls API

[Neale Ranns (nranns)]

Hi Holoo,

The MPLS API is at;
  /src/vnet/mpls/mpls.api
there are examples of the various types of MPLS FIB entries in the unit-tests. 
See;
  /test/test-mpls.py

hth
/neale

From:  on behalf of Holoo Gulakh 

Date: Sunday, 17 December 2017 at 12:58
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] mpls API

Hi,
I want to add an entry to mpls fib.
How can I do that??? What are essential parameters??

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

Re: [vpp-dev] Need Help on an ipsec Problem

[Neale Ranns (nranns)]

Hi Bin,

I expect your IPsec tunnel is not enabled/configured to accept IPv4 packets.
Do:
  sh int featuee 

and if you see:
ip4-unicast:
  ip4-drop

then the tunnel is configured to drop all IPv4 packets.
In order to enable any interface to receive IP it must either have an IP 
address applied;
  set int ip addr  p.q.r.s/t
Or be unnumbered to another interface that has one;
  set int ip addr  p.q.r.s/t
  set int unnumbered  use 

/neale

From:  on behalf of "Bin Zhang (binzhang)" 

Date: Friday, 15 December 2017 at 23:04
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Need Help on an ipsec Problem

Hi Team,

I am new to VPP and would appreciate your comments and debugging tips on the 
following problem.

I have set up an ipsec tunnel between two VMs (as shown in the diagram).  The 
client side is Strongswan and the server side is VPP.  But I can not ping 
through the tunnel from the client VM (on the left) to the subnet in the VPP VM 
(on the right).  In other words, “ping 151.1.1.2” failed.  The packet is 
dropped by VPP.

I used gdb to track the code execution.  The “next index” was changed from 2 
(IP4_INPUT_NEXT_LOOKUP) to 5 (IP4_INPUT_N_NEXT) in function 
vnet_get_config_data.



  /* Last 32 bits are next index. */

  *next_index = d[n];


How do I move forward with my investigation?

More info:
[1] Packet trace of the ping packet.  As we can see, the de-tunneling worked 
and the (inner) ICMP packet was moved to ip4-input.  But it was then dropped.
00:12:16:877859: dpdk-input
  GigabitEthernet0/8/0 rx queue 0
  buffer 0x494a: current data 14, length 152, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 166
buf_len 2176, data_len 166, ol_flags 0x0, data_off 128, phys_addr 0x10b25300
packet_type 0x0
  IP4: 08:00:27:57:ad:8c -> 08:00:27:94:51:9e
  IPSEC_ESP: 172.28.128.4 -> 172.28.128.5
tos 0x00, ttl 64, length 152, checksum 0xe6d7
fragment id 0xfb19, flags DONT_FRAGMENT
00:12:16:877919: ip4-input
  IPSEC_ESP: 172.28.128.4 -> 172.28.128.5
tos 0x00, ttl 64, length 152, checksum 0xe6d7
fragment id 0xfb19, flags DONT_FRAGMENT
00:12:16:877924: ip4-lookup
  fib 0 dpo-idx 7 flow hash: 0x
  IPSEC_ESP: 172.28.128.4 -> 172.28.128.5
tos 0x00, ttl 64, length 152, checksum 0xe6d7
fragment id 0xfb19, flags DONT_FRAGMENT
00:12:16:877926: ip4-local
IPSEC_ESP: 172.28.128.4 -> 172.28.128.5
  tos 0x00, ttl 64, length 152, checksum 0xe6d7
  fragment id 0xfb19, flags DONT_FRAGMENT
00:12:16:877927: ipsec-if-input
  IPSec: spi 945163011 seq 22
00:12:16:877929: esp-decrypt
  esp: crypto aes-cbc-192 integrity sha1-96
00:12:16:877956: ip4-input
  ICMP: 172.28.128.4 -> 151.1.1.2
tos 0x00, ttl 64, length 84, checksum 0xc378
fragment id 0xb30c, flags DONT_FRAGMENT
  ICMP echo_request checksum 0xe0c1
00:12:16:877958: ip4-drop
ICMP: 172.28.128.4 -> 151.1.1.2
  tos 0x00, ttl 64, length 84, checksum 0xc378
  fragment id 0xb30c, flags DONT_FRAGMENT
ICMP echo_request checksum 0xe0c1
00:12:16:877959: error-drop
  ip4-input: valid ip4 packets

[2] Ikev2 profile on VPP
DBGvpp# show ikev2 profile
profile pr1
  auth-method shared-key-mic auth data Vpp123
  local id-type fqdn data vpp.home
  remote id-type fqdn data ss.vpn.example.com
  local traffic-selector addr 151.1.1.0 - 151.1.1.255 port 0 - 65535 protocol 0
  remote traffic-selector addr 172.28.128.4 - 172.28.128.4 port 0 - 65535 
protocol 0

[3] Tunnel info on VPP
DBGvpp# show ikev2 sa
 iip 172.28.128.4 ispi e934164d91e57f38 rip 172.28.128.5 rspi d17da080720b0634
 encr:aes-cbc-256 prf:hmac-sha1 integ:sha1-96 dh-group:modp-2048
  nonce i:62ecfcedebb59e043bc9ccfcbceeb17ab32439f93cb0005bb81633f0a914fa48
r:15ebb5e167b57c0079951a9ea2c77198b08d8398002a82c333ecd92a96e76f12
  SK_d88d1534d0e99c4430059c82c7b6d20b59ef54bbd
  SK_a  i:4766ba54d3f2d68c3575f0610f14226b7066bf53
r:b27d54dcb76cb7f261a1d9e25e93cb91ec67864c
  SK_e  i:b0c0719ad7d219a8a2b51f8b45ca4e9af6ab7bf5e4e2e50b3a6b05e8fc4d1095
r:475962cd9e562ee5f7581fecdfe50e12ab56fd946bed64283d19b5799c4edef8
  SK_p  i:9ca87f1f298b29948878900f0ae4fe3d1cb3
r:aa950829e67985a7395e7c96cb5f1eef4c7c46a4
  identifier (i) fqdn ss.vpn.example.com
  identifier (r) fqdn vpp.home
  child sa 0:
encr:aes-cbc-192 integ:sha1-96 esn:yes
spi(i) c8423981 spi(r) fc77442b
SK_e  i:fb2002ca400eda904856a61894bbb445b5df9f5c0b647034
  r:54618f411597bb6b92d619b9bd10b2fe86d50530b86b00bd
SK_a  i:2ef6391d25c7cc5b32bef76194201abdc80956f6
  r:0b211b0a7845b380146595535c7f99aa994cc3c9
traffic selectors (i):
  0 type 7 protocol_id 0 addr 172.28.128.4 - 172.28.128.4 port 0 - 65535
traffic selectors (r):
  0 type 7 protocol_id 0 addr 151.1.1.0 - 151.1.1.255 port 0 - 65535
 iip 172.28.128.4 ispi e934164d91e57f38 rip 172.28.128.5 rspi d17da080720b0634

[4] Tunnel info on Client
vagrant@client1:/etc$ sudo ip xfrm stat

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

Re: [vpp-dev] How can i use VPP as MPLS PE/P device

[Neale Ranns (nranns)]

Another hastily assembled, on-demand guide:
  https://wiki.fd.io/view/VPP/MPLS_FIB

/neale

From:  on behalf of "wangchuan...@163.com" 

Date: Wednesday, 6 December 2017 at 09:11
To: vpp-dev 
Subject: [vpp-dev] How can i use VPP as MPLS PE/P device

hi all，
I want to configure my testing MPLS network.
how can I configure VPP to act as PE or P using CLI cmd?
who can help?


best regards!


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

Re: [vpp-dev] SR MPLS not effective

[Neale Ranns (nranns)]

Hi Xyxue,

The junk value for the last label in the stack was a result of you configuring 
9 labels, when the mpls_label_dpo_t can contain only 8.
I have pushed patch:
  https://gerrit.fd.io/r/#/c/9739/
to:
1 – up this value to 12, which is as many as will allow a mpls_label_dpo_t to 
still fit on one cache line
2 – not go wandering into random memory when the stack size is exceeded, but 
instead log and error and stack on drop.
If more than 12 labels are really needed, then I’ll need to revisit this and 
probably play the same trick as we do for handling more that 4 load-balance 
buckets.

Regards,
neale

From: 薛欣颖 <xy...@fiberhome.com>
Date: Thursday, 30 November 2017 at 12:44
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "Pablo Camarillo (pcamaril)" 
<pcama...@cisco.com>, vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: Re: [vpp-dev] SR MPLS not effective


Hi Neale,

I can't configure the command like this:
'VPP# sr mpls policy add bsid 999 next 210  209  208  207  206  205  204  203  
202  201
unknown input `209  208  207  206  205  204  ...''

I configured the command like before. And the all info is shown below:
packet info:
00:05:58:166326: af-packet-input
af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
status 0x2001 len 78 snaplen 78 mac 66 net 80
sec 0x5a1feacb nsec 0x372a239a vlan 0
00:05:58:166355: ethernet-input
IP4: 00:00:00:66:00:55 -> 00:0c:29:4d:af:b5
00:05:58:166385: ip4-input
ICMP: 21.1.1.5 -> 23.1.1.5
tos 0x00, ttl 64, length 64, checksum 0x4cb1
fragment id 0x0001
ICMP echo_request checksum 0x5f5d
00:05:58:166391: ip4-lookup
fib 0 dpo-idx 33 flow hash: 0x
ICMP: 21.1.1.5 -> 23.1.1.5
tos 0x00, ttl 64, length 64, checksum 0x4cb1
fragment id 0x0001
ICMP echo_request checksum 0x5f5d
00:05:58:166401: ip4-load-balance
fib 0 dpo-idx 33 flow hash: 0x
ICMP: 21.1.1.5 -> 23.1.1.5
tos 0x00, ttl 64, length 64, checksum 0x4cb1
fragment id 0x0001
ICMP echo_request checksum 0x5f5d
00:05:58:166405: ip4-mpls-label-imposition
mpls-header:[16416:63:0:eos]   //when I 
configured two layer label,this info is ' mpls-header:[101:63:0:eos] '
00:05:58:166415: mpls-label-imposition
mpls-header:[211:255:0:neos]
00:05:58:166416: mpls-output
adj-idx 3 : mpls via 14.1.1.2 host-eth2: 000c290fe2a8000c294dafa18847 flow 
hash: 0x
: 
0020: 
00:05:58:166424: host-eth2-output
host-eth2
MPLS: 00:0c:29:4d:af:a1 -> 00:0c:29:0f:e2:a8
label 211 exp 0, s 0, ttl 255

VPP# show sr mpls policies
 
VPP# show sr mpls policies
SR MPLS policies:
[0].- BSID: 999
Type: Default
Segment Lists:
[0].- < 210, 209, 208, 207, 206, 205, 204, 203, 202, 201 >
---


VPP# show mpls fib label 999
MPLS-VRF:0, fib_index 0
999:neos/21 fib:0 index:26 locks:2
src:SR refs:1
index:27 locks:4 flags:shared, uPRF-list:28 len:1 itfs:[2, ]
index:27 pl-index:27 mpls weight=1 pref=0 recursive: oper-flags:resolved,
via 210 neos in fib:0 via-fib:27 via-dpo:[dpo-load-balance:29]
Extensions:
path:27 labels:209 208 207 206 205 204 203 202 201
forwarding: mpls-neos-chain
[@0]: dpo-load-balance: [proto:mpls index:30 buckets:1 uRPF:28 to:[0:0]]
[0] [@8]: 
mpls-label:[0]:[209:255:0:neos][208:255:0:neos][207:255:0:neos][206:255:0:neos][205:255:0:neos][204:255:0:neos][203:255:0:neos][202:255:0:neos][16416:0:1:neos]
[@2]: dpo-load-balance: [proto:mpls index:29 buckets:1 uRPF:29 to:[0:0] 
via:[586:58600]]
[0] [@8]: mpls-label:[3]:[211:255:0:neos]
[@3]: mpls via 14.1.1.2 host-eth2: 000c290fe2a8000c294dafa18847
999:eos/21 fib:0 index:28 locks:4
src:SR refs:1
index:27 locks:4 flags:shared, uPRF-list:28 len:1 itfs:[2, ]
index:27 pl-index:27 mpls weight=1 pref=0 recursive: oper-flags:resolved,
via 210 neos in fib:0 via-fib:27 via-dpo:[dpo-load-balance:29]
Extensions:
path:27 labels:209 208 207 206 205 204 203 202 201
src:recursive-resolution cover:-1 refs:1

forwarding: mpls-eos-chain
[@0]: dpo-load-balance: [proto:mpls index:31 buckets:1 uRPF:28 to:[0:0]]
[0] [@8]: 
mpls-label:[2]:[209:255:0:neos][208:255:0:neos][207:255:0:neos][206:255:0:neos][205:255:0:neos][204:255:0:neos][203:255:0:neos][202:255:0:neos][16416:0:1:neos]
[@2]: dpo-load-balance: [proto:mpls index:29 buckets:1 uRPF:29 to:[0:0] 
via:[586:58600]]
[0] [@8]: mpls-label:[3]:[211:255:0:neos]
[@3]: mpls via 14.1.1.2 host-eth2: 000c290fe2a8000c294dafa18847


VPP# show mpls fib label 210
MPLS-VRF:0, fib_index 0
210:neos/21 fib:0 index:27 locks:4
src:CLI refs:1
index:29 locks:2 flags:shared, uPRF-list:29 len:1 itfs:[2, ]
index:29 pl-index:29 ip4 weight=1 pref=0 attached-nexthop: oper-flags:resolved,
14.1.1.2 host-eth2
[@0]: ipv4 via 14.1.1.2 host-eth2: 000c290fe2a8000c294dafa10800
Extensions:
path:29 labels:211
src:recursive-resolution cover:-1 refs:1

forwarding: mpls-neos-chain
[@0]: dpo-load-balance: [proto:mpls index:29 buckets:1 uRPF:29 to:[0:0] 
via:[686

Re: [vpp-dev] Bug?

[Neale Ranns (nranns)]

By ‘receive’ in this context, I assume you mean it accepts the packet that has 
arrived on the wire. As opposed to the fact that the packet did indeed arrive 
at that interface - clearly it is not the receiving device that influences 
which packets arrive at which interfaces.

So, let me bounce this back to you. Under what circumstances do L3 and L2 ports 
accept a packet?

Regards,
neale

From:  on behalf of Yuliang Li 

Date: Tuesday, 5 December 2017 at 04:55
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Bug?

Hi,

I am using vpp v18.01-rc0~160-ge13c799 (show version in vppctl). I feel I find 
a bug.

I have two physical interfaces TenGigabitEthernet5/0/0 (int1) and 
TenGigabitEthernet5/0/1 (int2).

Normally, if I send traffic (from another server) to int1, I expect int2 should 
NOT receive the traffic. This is true when int2 is in l3 mode.

However, if I set int2 to l2 mode (e.g., set interface l2 bridge 
TenGigabitEthernet5/0/1 2), int2 will receive the same traffic as int1 does. 
This problem happens no matter int1 is in l2 or l3 mode. I use the trace to 
confirm that int2 receives the same traffic as int1 does.

Does anyone know this problem?

Thanks,
--
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

[Neale Ranns (nranns)]

Hi Prabhjot,

If there is only one link between VPP A and B, regardless of the number of .1q 
sub-interfaces, the forward and reverse direction packets *should* have the 
same MAC addresses.

You mention ECMP. Is the reverse direction traffic arriving on the same 
interface from which it was sent?
Perhaps you could show a packet trace for the forward and reverse direction.

Regards,
neale



From: Prabhjot Singh Sethi <prabh...@techtrueup.com>
Date: Monday, 4 December 2017 at 12:53
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "prabh...@techtrueup.com" 
<prabh...@techtrueup.com>
Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, Omer Majeed 
<omer.maj...@rwth-aachen.de>
Subject: Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

Hi Neale,

we have the traffic working however the packets looks like
source 1.1.1.3 (02:00:00:00:00:01) dest 2.2.2.3 (02:00:00:00:00:02)
however for reverse traffic
source 2.2.2.3 (02:fe:c9:7a:70:00) dest 1.1.1.3 (02:00:00:00:00:01)

use of BVI for this purpose is ruled out as this use case also need to handle 
ECMP route with multiple VLAN interfaces

Packet  Egressed by VPP needs to be going though some third party firewall VM 
eventually, so at this point we are unable to rule out
strict requirement on source MAC.

so essentially we were looking at option to set MAC on VLAN interfaces while 
correlating it to linux counterpart.

so my expectation is there should be a way to have uniformity in source and 
dest MAC for forward and reverse traffic

Regards,
Prabhjot

- Original Message -
From:
"Neale Ranns (nranns)" <nra...@cisco.com>

To:
"prabh...@techtrueup.com" <prabh...@techtrueup.com>
Cc:
"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, "Omer Majeed" 
<omer.maj...@rwth-aachen.de>
Sent:
Sat, 2 Dec 2017 08:00:06 +
Subject:
Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface


Hi Prabhjot,

Your explanation of what you want I think I understand; it’s the ability to set 
the src,dst MAC address of a packet as it egresses of VLAN interface. Where in 
this case a vlan interface is a 802.1Q interface and not a BVI*.
But I don’t understand why you want this. You say “we are not looking for any 
additional datapath lookup based on MAC”, in other words, the RX side does not 
care what the src,dst MAC addresses are, so why is it important what the TX 
side sets? Is it for the benefit of intervening switches? If so I still don’t 
understand why ☹

What is the issue you are trying to address by setting different src,dst MAC 
addresses? Perhaps there are existing means to achieve this already.

Regards,
neale

*In some vendor’s documentation ‘VLAN’ interfaces, also known as BVI, SVI or 
IRB (depending on your preferred vendor, platform or decade) is what VPP terms 
an BVI. This is an L3 port attached to a bridge-domain.

-Original Message-----
From: "prabh...@techtrueup.com" <prabh...@techtrueup.com>
Date: Friday, 1 December 2017 at 18:37
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, Omer Majeed 
<omer.maj...@rwth-aachen.de>
Subject: Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

hi Neale,
we are not looking for any additional datapath lookup based on MAC here.
this is related to one of the feature that we are trying to translate
to VPP. where we need to handle and generate traffic with configure
destination and source MAC. we have tried multiple options and were
able to handle incoming traffic, but we were having issues sending
traffic with specific source MAC particularly with ECMP routes.

so i only see two ways either we support configurable MAC address on
vlan interface
or have some ability to configure which source MAC to use in the route
configuration

please let me know if you want to understand the feature in detail. we
can setup a short call for the same.

Regards,
Prabhjot

Quoting "Neale Ranns (nranns)" <nra...@cisco.com>:

> Hi Prabhjot,
>
> I would say it is possible, but one would need to place the NIC in
> promiscuous mode for an L3 interface, do maybe do MAC to interface
> matching in the data-plane which would cost many cycles. Or an rx
> would you still want to match to input interface based only on the
> VLAN Tag.
>
> I confess I don’t understand why you want such a feature, when the
> VLAN tag identifies the sub-interface. Perhaps you could help me
> understand.
>
> Thanks,
> neale
>
> -Original Message-
> From: "prabh...@techtrueup.com" <prabh...@techtrueup.com>
> Date: Friday, 1 December 2017 at 13:30
> To: Omer Majeed <omer.maj...@rwth-aachen.de>
> Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, "Neale Ranns
> (nranns)" <nra...@cisco.com>
> Subject: Re: [

Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

[Neale Ranns (nranns)]

Hi Prabhjot,

Your explanation of what you want I think I understand; it’s the ability to set 
the src,dst MAC address of a packet as it egresses of VLAN interface. Where in 
this case a vlan interface is a 802.1Q interface and not a BVI*.
But I don’t understand why you want this. You say “we are not looking for any 
additional datapath lookup based on MAC”, in other words, the RX side does not 
care what the src,dst MAC addresses are, so why is it important what the TX 
side sets? Is it for the benefit of intervening switches? If so I still don’t 
understand why ☹

What is the issue you are trying to address by setting different src,dst MAC 
addresses? Perhaps there are existing means to achieve this already.

Regards,
neale

*In some vendor’s documentation ‘VLAN’ interfaces, also known as BVI, SVI or 
IRB (depending on your preferred vendor, platform or decade) is what VPP terms 
an BVI. This is an L3 port attached to a bridge-domain.

-Original Message-
From: "prabh...@techtrueup.com" <prabh...@techtrueup.com>
Date: Friday, 1 December 2017 at 18:37
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, Omer Majeed 
<omer.maj...@rwth-aachen.de>
Subject: Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

hi Neale,
we are not looking for any additional datapath lookup based on MAC here.
this is related to one of the feature that we are trying to translate  
to VPP. where we need to handle and generate traffic with configure  
destination and source MAC. we have tried multiple options and were  
able to handle incoming traffic, but we were having issues sending  
traffic with specific source MAC particularly with ECMP routes.

so i only see two ways either we support configurable MAC address on  
vlan interface
or have some ability to configure which source MAC to use in the route  
configuration

please let me know if you want to understand the feature in detail. we  
can setup a short call for the same.
    
    Regards,
Prabhjot

Quoting "Neale Ranns (nranns)" <nra...@cisco.com>:

> Hi Prabhjot,
>
> I would say it is possible, but one would need to place the NIC in  
> promiscuous mode for an L3 interface, do maybe do MAC to interface  
> matching in the data-plane which would cost many cycles. Or an rx  
> would you still want to match to input interface based only on the  
> VLAN Tag.
>
> I confess I don’t understand why you want such a feature, when the  
> VLAN tag identifies the sub-interface. Perhaps you could help me  
> understand.
>
> Thanks,
> neale
>
> -Original Message-
> From: "prabh...@techtrueup.com" <prabh...@techtrueup.com>
> Date: Friday, 1 December 2017 at 13:30
> To: Omer Majeed <omer.maj...@rwth-aachen.de>
> Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, "Neale Ranns  
> (nranns)" <nra...@cisco.com>
> Subject: Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface
>
> hi Neale,
>  we are expecting to be able to handle different MAC addresses for
> VLAN interfaces. This feature seems to be not available in VPP as of
> now.
>
> we also tried looking for possible work around, which were dead ends
> as of now. Please let us know if we agree to this as something that
> can be done for VPP, we can work on this and contribute if useful.
>
> please share your inputs
>
> Regards,
> Prabhjot
>
> Quoting Omer Majeed <omer.maj...@rwth-aachen.de>:
>
> > Hi Neale,
> >
> > Thanks for the reply.
> > A physical interface could have multiple Vlan interfaces and I  
> want traffic
> > originating from Vlan interface to have user defined Mac address 
rather
> > than parent's Mac address.
> >
> > In Linux we have this privilege to associate Mac addresses to Vlan
> > interfaces using ifconfig.
> > In Linux, we use vconfig to create Vlan interface and then we could
> > leverage ifconfig to configure our own Mac address on the Vlan  
> interface.
> >
> > Could we have something similar in VPP?
> >
> > Best Regards,
> > Omer
> >
> > On Wed, Nov 29, 2017 at 6:44 PM, Neale Ranns (nranns)  
> <nra...@cisco.com>
> > wrote:
> >
> >> Hi Omer,
> >>
> >>
>

Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

[Neale Ranns (nranns)]

Hi Prabhjot,

I would say it is possible, but one would need to place the NIC in promiscuous 
mode for an L3 interface, do maybe do MAC to interface matching in the 
data-plane which would cost many cycles. Or an rx would you still want to match 
to input interface based only on the VLAN Tag.

I confess I don’t understand why you want such a feature, when the VLAN tag 
identifies the sub-interface. Perhaps you could help me understand.

Thanks,
neale

-Original Message-
From: "prabh...@techtrueup.com" <prabh...@techtrueup.com>
Date: Friday, 1 December 2017 at 13:30
To: Omer Majeed <omer.maj...@rwth-aachen.de>
Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, "Neale Ranns (nranns)" 
<nra...@cisco.com>
Subject: Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

hi Neale,
 we are expecting to be able to handle different MAC addresses for  
VLAN interfaces. This feature seems to be not available in VPP as of  
now.

we also tried looking for possible work around, which were dead ends  
as of now. Please let us know if we agree to this as something that  
can be done for VPP, we can work on this and contribute if useful.

please share your inputs

Regards,
Prabhjot

Quoting Omer Majeed <omer.maj...@rwth-aachen.de>:

> Hi Neale,
>
> Thanks for the reply.
> A physical interface could have multiple Vlan interfaces and I want 
traffic
> originating from Vlan interface to have user defined Mac address rather
> than parent's Mac address.
>
> In Linux we have this privilege to associate Mac addresses to Vlan
> interfaces using ifconfig.
> In Linux, we use vconfig to create Vlan interface and then we could
> leverage ifconfig to configure our own Mac address on the Vlan interface.
>
> Could we have something similar in VPP?
    >
> Best Regards,
> Omer
>
> On Wed, Nov 29, 2017 at 6:44 PM, Neale Ranns (nranns) <nra...@cisco.com>
> wrote:
>
>> Hi Omer,
>>
>>
>>
>> You can set the MAC address of a ‘host’ interface when it is created:
>>
>>   create host-interface name  [hw-addr ]
>>
>>
>>
>> you can also change it after creation:
>>
>>   set interface mac address  
>>
>>
>>
>> but you cannot set the MAC address of a VLAN interface. A VLAN interface
>> will always have the same MAC address as its parent/physical interface.
>>
>>
>>
>> Regards,
>>
>> Neale
>>
>>
>>
>>
>>
>> *From: *<vpp-dev-boun...@lists.fd.io> on behalf of Omer Majeed <
>> omer.maj...@rwth-aachen.de>
>> *Date: *Wednesday, 29 November 2017 at 11:45
>> *To: *"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
>> *Subject: *[vpp-dev] Fwd: :: Setting Mac address on Vlan interface
>>
>>
>>
>> Hi,
>>
>>
>>
>> I am trying to form an ecmp between Vlan interfaces. Traffic coming with
>> IP 1.1.1.5 would go through Vlan interfaces host-tap0.1 and host-tap1.1
>> forming ecmp.
>>
>>
>>
>> ip route add 1.1.1.5/32 table 3 via 1.1.1.5 host-tap0.1
>> ip route add 1.1.1.5/32 table 3 via 1.1.1.5 host-tap1.1
>>
>>
>> set ip arp host-tap0.1 1.1.1.5 02:00:00:00:00:02
>>
>> set ip arp host-tap1.1 1.1.1.5 02:00:00:00:00:02
>>
>>
>>
>> ip route add 1.1.1.5/32 table 5 via 1.1.1.5 host-tap2.1
>>
>> ip route add 1.1.1.5/32 table 5 via 1.1.1.5 host-tap3.1
>>
>>
>>
>> set ip arp host-tap2.1 1.1.1.5 02:00:00:00:00:01
>>
>> set ip arp host-tap3.1 1.1.1.5 02:00:00:00:00:01
>>
>>
>>
>> However traffic flows having Source Mac addresses as that of respective
>> Vlan interfaces. Is there any way I could set Vlan interfaces with my own
>> desired Mac Addresses, so that the traffic has user defined Mac addresses
>> as Source Mac addresses.
>>
>>
>>
>> Thanks.
>>
>> Best Regards,
>>
>> Omer Majeed
>>
>>
>>
>>




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

Re: [vpp-dev] SR MPLS not effective

[Neale Ranns (nranns)]

Hi Xyxue,

To get a 10 label stack, you need to do;
sr mpls policy add bsid 999 next 210  209  208  207  206  205  204  203  202  
201
i.e. only use the ‘next’ keyword once.

And then if you don’t get the desired result, could show me the following 
outputs;
  sh sr mpls polic
  sh mpls fib 999
  sh mpls fib 210
  st trace  <<< for a ‘bad’ packet.

thanks,
neale

From: 薛欣颖 <xy...@fiberhome.com>
Date: Thursday, 30 November 2017 at 10:23
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "Pablo Camarillo (pcamaril)" 
<pcama...@cisco.com>, vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: Re: [vpp-dev] SR MPLS not effective


Hi Neale，

After referring to your example, I modified my configuration. And the two layer 
label SR MPLS works well.
But when configure ten layer label, the bottom label is different from the 
configuration.

vpp1 configuration:
create host-interface name eth4 mac 00:0c:29:4d:af:b5
create host-interface name eth2 mac 00:0c:29:4d:af:a1
set interface state host-eth2 up
set interface state host-eth4 up
set interface ip address host-eth2 14.1.1.1/24
set interface ip address host-eth4 21.1.1.1/24
mpls table add 0
set interface mpls host-eth2 enable
sr mpls policy add bsid 999 next 210 next 209 next 208 next 207 next 206 next 
205 next 204 next 203 next 202 next 201   // encap 10 layer label
sr mpls steer l3 23.1.1.0/24 via sr policy bsid 999
mpls local-label add non-eos 210 via 14.1.1.2 host-eth2 out-label 211

Actually, the bottom is 16416 (the value configured is 201).  The ttl is 63 and 
others is 255.
The trace info and message info is shown below:

00:31:47:618725: af-packet-input
af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
status 0x2001 len 78 snaplen 78 mac 66 net 80
sec 0x5a1fb1aa nsec 0x22ae91a9 vlan 0
00:31:47:618752: ethernet-input
IP4: 00:00:00:66:00:55 -> 00:0c:29:4d:af:b5
00:31:47:618815: ip4-input
ICMP: 21.1.1.5 -> 23.1.1.5
tos 0x00, ttl 64, length 64, checksum 0x4cb1
fragment id 0x0001
ICMP echo_request checksum 0x5f5d
00:31:47:618823: ip4-lookup
fib 0 dpo-idx 34 flow hash: 0x
ICMP: 21.1.1.5 -> 23.1.1.5
tos 0x00, ttl 64, length 64, checksum 0x4cb1
fragment id 0x0001
ICMP echo_request checksum 0x5f5d
00:31:47:618833: ip4-load-balance
fib 0 dpo-idx 34 flow hash: 0x
ICMP: 21.1.1.5 -> 23.1.1.5
tos 0x00, ttl 64, length 64, checksum 0x4cb1
fragment id 0x0001
ICMP echo_request checksum 0x5f5d
00:31:47:618837: ip4-mpls-label-imposition
mpls-header:[16416:63:0:eos]
00:31:47:618844: mpls-label-imposition
mpls-header:[211:255:0:neos]
00:31:47:618846: mpls-output
adj-idx 3 : mpls via 14.1.1.2 host-eth2: 000c290fe2a8000c294dafa18847 flow 
hash: 0x
: 
0020: 
00:31:47:618853: host-eth2-output
host-eth2
MPLS: 00:0c:29:4d:af:a1 -> 00:0c:29:0f:e2:a8
label 211 exp 0, s 0, ttl 255

Thanks for your help.

Thanks,
Xyxue


From: Neale Ranns (nranns)<mailto:nra...@cisco.com>
Date: 2017-11-29 16:37
To: 薛欣颖<mailto:xy...@fiberhome.com>; Pablo Camarillo 
(pcamaril)<mailto:pcama...@cisco.com>; vpp-dev<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] SR MPLS not effective

Hi Xyxue,

Here’s a hastily assembled guide on how I would do it;
  https://wiki.fd.io/view/VPP/Segment_Routing_for_MPLS

I’ve not verified the configs myself. If you use it, please let me know any 
errors you find.

Regards,
neale



From: 薛欣颖 <xy...@fiberhome.com>
Date: Wednesday, 29 November 2017 at 08:13
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "Pablo Camarillo (pcamaril)" 
<pcama...@cisco.com>, vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: Re: [vpp-dev] SR MPLS not effective

After add the 'mpls local-label add non-eos 33 mpls-lookup-in-table 0 ' on P,  
the mistake still exist.

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

Re: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

[Neale Ranns (nranns)]

Hi Omer,

You can set the MAC address of a ‘host’ interface when it is created:
  create host-interface name  [hw-addr ]

you can also change it after creation:
  set interface mac address  

but you cannot set the MAC address of a VLAN interface. A VLAN interface will 
always have the same MAC address as its parent/physical interface.

Regards,
Neale


From:  on behalf of Omer Majeed 

Date: Wednesday, 29 November 2017 at 11:45
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Fwd: :: Setting Mac address on Vlan interface

Hi,

I am trying to form an ecmp between Vlan interfaces. Traffic coming with IP 
1.1.1.5 would go through Vlan interfaces host-tap0.1 and host-tap1.1 forming 
ecmp.

ip route add 1.1.1.5/32 table 3 via 1.1.1.5 host-tap0.1
ip route add 1.1.1.5/32 table 3 via 1.1.1.5 host-tap1.1

set ip arp host-tap0.1 1.1.1.5 02:00:00:00:00:02
set ip arp host-tap1.1 1.1.1.5 02:00:00:00:00:02

ip route add 1.1.1.5/32 table 5 via 1.1.1.5 host-tap2.1
ip route add 1.1.1.5/32 table 5 via 1.1.1.5 host-tap3.1

set ip arp host-tap2.1 1.1.1.5 02:00:00:00:00:01
set ip arp host-tap3.1 1.1.1.5 02:00:00:00:00:01

However traffic flows having Source Mac addresses as that of respective Vlan 
interfaces. Is there any way I could set Vlan interfaces with my own desired 
Mac Addresses, so that the traffic has user defined Mac addresses as Source Mac 
addresses.

Thanks.
Best Regards,
Omer Majeed

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

Re: [vpp-dev] SR MPLS not effective

[Neale Ranns (nranns)]

Hi Xyxue,

Here’s a hastily assembled guide on how I would do it;
  https://wiki.fd.io/view/VPP/Segment_Routing_for_MPLS

I’ve not verified the configs myself. If you use it, please let me know any 
errors you find.

Regards,
neale

From: 薛欣颖 <xy...@fiberhome.com>
Date: Wednesday, 29 November 2017 at 08:13
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "Pablo Camarillo (pcamaril)" 
<pcama...@cisco.com>, vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: Re: [vpp-dev] SR MPLS not effective



Hi Neale,

After add the 'mpls local-label add non-eos 33 mpls-lookup-in-table 0 ' on P,  
the mistake still exist.

create host-interface name eth2 mac 00:0c:29:0f:e2:a8
create host-interface name eth3 mac 00:0c:29:0f:e2:b2
set interface state host-eth2 up
set interface state host-eth3 up
set interface ip address host-eth3 12.1.1.1/24
mpls table add 0
set interface mpls host-eth2 enable
set interface mpls host-eth3 enable
set interface ip address host-eth2 14.1.1.2/24
create mpls tunnel out-label 60 via 12.1.1.2 host-eth3
set interface state mpls-tunnel0 up
sr mpls policy add bsid 33 next 60
sr mpls steer l3 23.1.1.0/24 via sr policy bsid 33
set interface mpls mpls-tunnel0 enable
mpls local-label add non-eos 33 mpls-lookup-in-table 0   // local-label 
33/non-eos configured

the mistake is the same as before:
00:06:02:539782: af-packet-input
af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
status 0x2001 len 86 snaplen 86 mac 66 net 80
sec 0x5a1e5992 nsec 0x193b68e0 vlan 0
00:06:02:539813: ethernet-input
MPLS: 00:0c:29:4d:af:a1 -> 00:0c:29:0f:e2:a8
00:06:02:539869: mpls-input
MPLS: next mpls-lookup[1] label 33 ttl 255
00:06:02:539878: mpls-lookup
MPLS: next [0], lookup fib index 0, LB index 25 hash 0 label 33 eos 0
00:06:02:539889: error-drop
mpls-input: MPLS DROP DPO

Is there any example on SR MPLS configuration  I can get?

Thanks,
Xyxue
____

From: Neale Ranns (nranns)<mailto:nra...@cisco.com>
Date: 2017-11-28 20:29
To: 薛欣颖<mailto:xy...@fiberhome.com>; Pablo Camarillo 
(pcamaril)<mailto:pcama...@cisco.com>; vpp-dev<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] SR MPLS not effective
Hi Xyxue,

Your trace says:

00:01:54:346249: mpls-lookup
MPLS: next [0], lookup fib index 0, LB index 26 hash 0 label 33 eos 0

so the packet required an MPLS lookup on label 33 non-eos. Your config has no 
local-label 33/non-eos configured, so the packet is dropped.

/neale


From: <vpp-dev-boun...@lists.fd.io> on behalf of 薛欣颖 <xy...@fiberhome.com>
Date: Tuesday, 28 November 2017 at 12:20
To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>, vpp-dev 
<vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] SR MPLS not effective


Hi Pablo,

After hearing your advice, I modified my configuration on P:

create host-interface name eth2 mac 00:0c:29:0f:e2:a8
create host-interface name eth3 mac 00:0c:29:0f:e2:b2
set interface state host-eth2 up
set interface state host-eth3 up
set interface ip address host-eth3 12.1.1.1/24
mpls table add 0
set interface mpls host-eth2 enable
set interface mpls host-eth3 enable
set interface ip address host-eth2 14.1.1.2/24
create mpls tunnel out-label 60 via 12.1.1.2 host-eth3
set interface state mpls-tunnel0 up
sr mpls policy add bsid 33 next 60   //exchange the 
out-label to 60
sr mpls steer l3 23.1.1.0/24 via sr policy bsid 33
set interface mpls mpls-tunnel0 enable

the trace info on P:
00:01:54:346199: af-packet-input
af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
status 0x2001 len 86 snaplen 86 mac 66 net 80
sec 0x5a1d417b nsec 0xdffd3a9 vlan 0
00:01:54:346226: ethernet-input
MPLS: 00:0c:29:4d:af:a1 -> 00:0c:29:0f:e2:a8
00:01:54:346243: mpls-input
MPLS: next mpls-lookup[1] label 33 ttl 255
00:01:54:346249: mpls-lookup
MPLS: next [0], lookup fib index 0, LB index 26 hash 0 label 33 eos 0
00:01:54:346259: error-drop
mpls-input: MPLS DROP DPO

The SR MPLS still not effctive. Is there any example on SR MPLS configuration?

Thanks,
Xyxue


From: Pablo Camarillo (pcamaril)<mailto:pcama...@cisco.com>
Date: 2017-11-28 18:16
To: 薛欣颖<mailto:xy...@fiberhome.com>; vpp-dev<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] SR MPLS not effective
Hi Xyxue,

Could you please explain what you want to achieve with this config? Where do 
you want to start your SR policy?
None of the configs that you described below for P will work.

In the case #1 you are creating a SR policy with BSID 33. Then for any packet 
with incoming label 33 you will push the SID list of the SR policy. However, 
you are also creating an mpls local-label for 33 as well which you do not need.
On top of that, you are configuring the SR policy with SID list < 60 >, but you 
have not set a local-label/route for 60. Hence packet will be dropped.

Thanks.

Cheers,
Pablo.

From: <vpp-dev-boun...@lists.fd.io> on behalf of 薛欣颖

Re: [vpp-dev] sr mpls fault

[Neale Ranns (nranns)]

Hi Xyxue,

I’ll look into the crash.
In the meantime, perhaps your config is somewhat curious. What is your 
intention with 3.1.1.0/24? It has been added as an extranet route (i.e. it’s in 
table 0 and table 1) but in table 0 you have an override of the route via the 
SR steering. If you remove the ip route for 3.1.1.0/24 in table 0, I expect 
there will be no crash.

The SR policy says ‘forward in the same way as for label 1000’ but there is no 
local-label/route for 1000.
You don’t need MPLS table 1.

/neale

From:  on behalf of 薛欣颖 
Date: Monday, 27 November 2017 at 06:55
To: vpp-dev 
Subject: [vpp-dev] sr mpls fault


Hi guys,

Is the vpp support sr mpls now?
After I configured the following command, I configured 'sr mpls steer l3 
3.1.1.0/24 via sr policy bsid 33 del'.
Then there was a SIGABRT . Are there any illegal command in my configuration?

configuration：
create host-interface name eth2 mac 00:0c:29:6d:b0:82
create host-interface name eth1 mac 00:0c:29:6d:b0:78
create host-interface name eth3 mac 00:0c:29:6d:b0:8c
set interface state host-eth2 up
set interface state host-eth1 up
set interface state host-eth3 up
set interface ip table host-eth2 1
set interface ip address host-eth1 2.1.1.1/24
set interface ip address host-eth2 1.1.1.1/24
set interface ip address host-eth3 4.1.1.1/24
create mpls tunnel out-label 33 out-label 53 via 2.1.1.2 host-eth1
create mpls tunnel out-label 133 out-label 153 via 4.1.1.2 host-eth3
set interface state mpls-tunnel0 up
set interface state mpls-tunnel1 up
mpls table add 0
set interface mpls host-eth1 enable
set interface mpls host-eth3 enable
ip route add 3.1.1.0/24 via interface mpls-tunnel0 table 0
ip route add 3.1.1.0/24 via interface mpls-tunnel1 table 0
mpls local-label add eos 1053 ip4-lookup-in-table 1
mpls local-label add non-eos 1023 mpls-lookup-in-table 0
mpls local-label add eos 1153 ip4-lookup-in-table 1
mpls local-label add non-eos 1123 mpls-lookup-in-table 0
mpls table add 1
ip route add 3.1.1.0/24 via interface mpls-tunnel0 table 1
sr mpls policy add bsid 33 next 1000
sr mpls steer l3 3.1.1.0/24 via sr policy bsid 33


Program received signal SIGABRT, Aborted.
0x2b3ba59a2c37 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  0x2b3ba59a2c37 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x2b3ba59a6028 in __GI_abort () at abort.c:89
#2  0x00406e51 in os_panic () at 
/home/fos/vpp18.01/build-data/../src/vpp/vnet/main.c:272
#3  0x2b3ba52c0ac8 in debugger () at 
/home/fos/vpp18.01/build-data/../src/vppinfra/error.c:84
#4  0x2b3ba52c0ecf in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0,
fmt=0x2b3ba4f61100 "%s:%d (%s) assertion `%s' fails") at 
/home/fos/vpp18.01/build-data/../src/vppinfra/error.c:143
#5  0x2b3ba4e45aaf in fib_attached_export_purge (fib_entry=0x2b3ba6be7838)
at /home/fos/vpp18.01/build-data/../src/vnet/fib/fib_attached_export.c:373
#6  0x2b3ba4e469f1 in fib_attached_export_cover_modified_i 
(fib_entry=0x2b3ba6be7838)
at /home/fos/vpp18.01/build-data/../src/vnet/fib/fib_attached_export.c:491
#7  0x2b3ba4e46a7c in fib_attached_export_cover_update 
(fib_entry=0x2b3ba6be7838)
at /home/fos/vpp18.01/build-data/../src/vnet/fib/fib_attached_export.c:513
#8  0x2b3ba4e2c037 in fib_entry_cover_updated (fib_entry_index=43)
at /home/fos/vpp18.01/build-data/../src/vnet/fib/fib_entry.c:1390
#9  0x2b3ba4e34ed6 in fib_entry_cover_update_one (cover=0x2b3ba6be7428, 
covered=43, args=0x0)
at /home/fos/vpp18.01/build-data/../src/vnet/fib/fib_entry_cover.c:168
#10 0x2b3ba4e34d01 in fib_entry_cover_walk_node_ptr (depend=0x2b3ba6bec68c, 
args=0x2b3ba6f0f670)
at /home/fos/vpp18.01/build-data/../src/vnet/fib/fib_entry_cover.c:80
#11 0x2b3ba4e27aa3 in fib_node_list_walk (list=60, fn=0x2b3ba4e34cb6 
,
args=0x2b3ba6f0f670) at 
/home/fos/vpp18.01/build-data/../src/vnet/fib/fib_node_list.c:375
#12 0x2b3ba4e34d91 in fib_entry_cover_walk (cover=0x2b3ba6be7428, 
walk=0x2b3ba4e34eaa ,
args=0x0) at 
/home/fos/vpp18.01/build-data/../src/vnet/fib/fib_entry_cover.c:104
#13 0x2b3ba4e34f24 in fib_entry_cover_update_notify 
(fib_entry=0x2b3ba6be7428)
at /home/fos/vpp18.01/build-data/../src/vnet/fib/fib_entry_cover.c:177
#14 0x2b3ba4e2b4c9 in fib_entry_post_update_actions 
(fib_entry=0x2b3ba6be7428, source=FIB_SOURCE_CLI,
old_flags=FIB_ENTRY_FLAG_LOOSE_URPF_EXEMPT) at 
/home/fos/vpp18.01/build-data/../src/vnet/fib/fib_entry.c:885
#15 0x2b3ba4e2bc85 in fib_entry_special_remove (fib_entry_index=30, 
source=FIB_SOURCE_CLI)
at /home/fos/vpp18.01/build-data/../src/vnet/fib/fib_entry.c:1209
#16 0x2b3ba4e2bcd4 in fib_entry_delete (fib_entry_index=30, 
source=FIB_SOURCE_SR)
at /home/fos/vpp18.01/build-data/../src/vnet/fib/fib_entry.c:1226
#17 

Re: [vpp-dev] default route

[Neale Ranns (nranns)]

Tldr;
  Deleted no. modified yes.

There is always an entry for the all zeros address (a.k.a the default route) in 
the IPv4 and IPv6 FIB. Principally this exists so that in the data-plane after 
looking in the FIB for a match there is no need to say ‘if 
(matching-entry-exists)’, since as a last resort, it will match the default 
route. In the absence of any modifications, the forwarding result for the 
default route is to drop the packet – which is presumably the behaviour one 
would want if the default route could be deleted.
The default route can be modified via the CLI or API like any other route.

Regards,
neale


From:  on behalf of 15803846349 
<15803846...@qq.com>
Date: Saturday, 25 November 2017 at 15:52
To: vpp-dev 
Subject: [vpp-dev] default route

Hi, can the defult routes be deleted or modified in vpp 18.01?


来自 魅族 MX4 Pro
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issue with MPLS local label CLI

[Neale Ranns (nranns)]

Hi Marek,

You need to add ‘via’ keyword before the path:
DBGvpp# mpls local-label add non-eos 102 via mpls-lookup-in-table 0
DBGvpp# sh mpls fib 102
sh mpls fib 102
MPLS-VRF:0, fib_index 0
102:neos/21 fib:0 index:13 locks:2
  src:CLI refs:1
index:17 locks:2 flags:shared, uPRF-list:13 len:0 itfs:[]
  index:17 pl-index:17 mpls weight=1 pref=0 deag:  oper-flags:resolved,
   [@0]: dst-address,unicast lookup in MPLS-VRF:0

forwarding:   mpls-neos-chain
  [@0]: dpo-load-balance: [proto:mpls index:16 buckets:1 uRPF:13 to:[0:0]]
[0] [@6]: dst-address,unicast lookup in MPLS-VRF:0
DBGvpp#

From: "Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)" 
<mgrad...@cisco.com>
Date: Wednesday, 22 November 2017 at 14:14
To: "Neale Ranns (nranns)" <nra...@cisco.com>, vpp-dev <vpp-dev@lists.fd.io>
Subject: RE: Issue with MPLS local label CLI

Neal,

thanks for quick answer!
I’ve just pulled vpp code (HEAD @ 3ce7bcb),
and now I get following error message:

vpp# mpls local-label add 102 non-eos mpls-lookup-in-table 0
mpls local-label: unkown input: mpls-lookup-in-table 0

Regards,
Marek

From: Neale Ranns (nranns)
Sent: 22 listopada 2017 12:07
To: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) 
<mgrad...@cisco.com>; vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: Issue with MPLS local label CLI

Hi Marek,

Accidental breakage on my part. Fixed in:
  https://gerrit.fd.io/r/#/c/9520/

/neale

From: "Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)" 
<mgrad...@cisco.com<mailto:mgrad...@cisco.com>>
Date: Wednesday, 22 November 2017 at 10:53
To: vpp-dev <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Cc: "Neale Ranns (nranns)" <nra...@cisco.com<mailto:nra...@cisco.com>>
Subject: Issue with MPLS local label CLI

Hi,

mpls local-label add non-eos 102 mpls-lookup-in-table 0

is rejected by vppctl (unknown input …) since
https://gerrit.fd.io/r/#/c/9439/

Is it a bug, or such command is no longer valid?

BTW. There is also some issue with docs for the command:
https://docs.fd.io/vpp/18.01/clicmd_src_vnet_mpls.html

Thanks,
Marek


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

Re: [vpp-dev] Issue with MPLS local label CLI

[Neale Ranns (nranns)]

Hi Marek,

Accidental breakage on my part. Fixed in:
  https://gerrit.fd.io/r/#/c/9520/

/neale

From: "Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)" 
<mgrad...@cisco.com>
Date: Wednesday, 22 November 2017 at 10:53
To: vpp-dev <vpp-dev@lists.fd.io>
Cc: "Neale Ranns (nranns)" <nra...@cisco.com>
Subject: Issue with MPLS local label CLI

Hi,

mpls local-label add non-eos 102 mpls-lookup-in-table 0

is rejected by vppctl (unknown input …) since
https://gerrit.fd.io/r/#/c/9439/

Is it a bug, or such command is no longer valid?

BTW. There is also some issue with docs for the command:
https://docs.fd.io/vpp/18.01/clicmd_src_vnet_mpls.html

Thanks,
Marek


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

Re: [vpp-dev] MPLS LABEL problem

[Neale Ranns (nranns)]

Hi Xyxue,

You need to create the default MPLS table before you enable an interface for 
MPLS.

So in your sequence this command:
  set interface mpls host-eth1 enable
should have returned an error. I’ve patched with
   https://gerrit.fd.io/r/#/c/9519/
so now one gets;
  DBGvpp# set int mpls loop0 enable
 set interface mpls: default MPLS table must be created first

please edit your config sequence with
   mpls table add 0
I expect you also want to add your MPLS local-labels to the default MSPL table 
rather than you the MPLS table 1 that you create. Since the lookup for the MPS 
table will occur in the default table, as that is the table that all interfaces 
are bound to.

Regards,
neale

From:  on behalf of 薛欣颖 
Date: Wednesday, 22 November 2017 at 01:55
To: vpp-dev 
Subject: [vpp-dev] MPLS LABEL problem


Hi guys,

My vpp version :18.01.

vpp1-vpp2
When the flows out of vpp1, it has two layers of tags.
The flow was dropped in vpp2. And the error information:MPLS not enabled. Is 
there anything wrong in my configuration on vpp2?
Has the configuration in 18.01 changed?


   
 vpp1
  create host-interface name eth2 mac 00:0c:29:6d:b0:82
  create host-interface name eth1 mac 00:0c:29:6d:b0:78
  set interface ip table host-eth2 1
  set interface ip address host-eth2 1.1.1.1/24
  set interface ip address host-eth1 2.1.1.1/24
  set interface state host-eth2 up
  set interface state host-eth1 up
  set interface mpls host-eth1 enable
  create mpls tunnel out-label 33 out-label 34 via 2.1.1.2 host-eth1
  set interface state mpls-tunnel0 up
  mpls table add 1
  ip route add 3.1.1.0/24 via ip4-address 2.1.1.2 interface mpls-tunnel0 table 1
  mpls local-label add eos 1023 table 1 ip4-lookup-in-table 1
  mpls local-label add non-eos 1023 table 1 mpls-lookup-in-table 1

   
 vpp2
  create host-interface name eth2 mac 2c:53:4a:03:93:31
  create host-interface name eth1 mac 2c:53:4a:03:94:59
  set interface ip table host-eth2 1
  set interface ip address host-eth1 2.1.1.2/24
  set interface ip address host-eth2 3.1.1.1/24
  set interface state host-eth2 up
  set interface state host-eth1 up
  set interface mpls host-eth1 enable
  create mpls tunnel out-label 1023 out-label 1024 via 2.1.1.1 host-eth1
  set interface state mpls-tunnel0 up
  mpls table add 1
  ip route add 1.1.1.0/24 via ip4-address 2.1.1.1 interface mpls-tunnel0 table 1
  mpls local-label add eos 34 table 1 ip4-lookup-in-table 1
  mpls local-label add non-eos 33 table 1 mpls-lookup-in-table 1

the vpp2 error information is shown below:

VPP# show errors
   CountNode  Reason
  4889   mpls-input   MPLS input packets 
decapsulated
  4889   mpls-input   MPLS not enabled
31ip4-input   valid ip4 packets
   103 ethernet-input no error
 2arp-input   ARP replies sent
 1arp-input   ARP request IP4 source 
address learned
VPP# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:11:22:232258: af-packet-input
  af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
  status 0x1 len 132 snaplen 132 mac 66 net 80
  sec 0x5a141690 nsec 0x3162f619 vlan 0
00:11:22:232280: ethernet-input
  MPLS: 00:0c:29:6d:b0:78 -> 2c:53:4a:03:94:59
00:11:22:232332: mpls-input
  MPLS: next BUG![2]  label 33 ttl 255
00:11:22:232342: error-drop
  mpls-input: MPLS not enabled


Thanks,
xyxue

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

[vpp-dev] Deprecate [S]NAT APIs

[Neale Ranns (nranns)]

>From src/plugins/nat/nat.api

/*
 * Old "snat" APIs, will be deprecated after 17.10
 */

is it time?

/neale

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

[vpp-dev] RFC: Import/includes in .api files

[Neale Ranns (nranns)]

Hi All,

I’d like to be able to re-use types defined in one .api file in many other .api 
files. My specific objective is to re-use a fib_path_t across the many APIs 
that describe a destination to which to send packets.

My first attempt at this is:
  https://gerrit.fd.io/r/#/c/9489/

I updated vppapigen to accept the keyword ‘import’, munch the subsequent 
string, and then generate the #include in the resulting .api.h. then the fun 
started… multiple type definitions, include guards, here be dragons, turn back 
now and seek assistance.
I later realised that an import statement is not required. If I create 
vnet/fib/fib.api and add it to vnet_all_api_h.h at the top, then that has some 
success. However, no import statement is not so friendly to other tools that 
parse the .api files.

So an RFC that is really an RFH; how is it best to approach this?

Regards,
Neale


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

Re: [vpp-dev] FW: Coverity build failed with 18 errors

[Neale Ranns (nranns)]

Hi Chris,

Thank you. Please let me know if the build remains on strike ☺

/neale

-Original Message-
From: "Luke, Chris" <chris_l...@comcast.com>
Date: Friday, 10 November 2017 at 14:53
To: "Neale Ranns (nranns)" <nra...@cisco.com>, Chris Luke <chr...@flirble.org>, 
"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] FW: Coverity build failed with 18 errors

Thanks Neale; merged. Hopefully normal service will be resumed on this 
afternoons run! :)

Chris.

> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> Behalf Of Neale Ranns (nranns)
> Sent: Friday, November 10, 2017 7:33
> To: Chris Luke <chr...@flirble.org>; vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] FW: Coverity build failed with 18 errors
> 
> Hi Chris,
> 
> And this one for VOM:
>   https://gerrit.fd.io/r/#/c/9374/
> 
> /neale
    > 
> -Original Message-
> From: <vpp-dev-boun...@lists.fd.io> on behalf of "Neale Ranns (nranns)"
> <nra...@cisco.com>
> Date: Friday, 10 November 2017 at 11:59
> To: Chris Luke <chr...@flirble.org>, "vpp-dev@lists.fd.io"  d...@lists.fd.io>
> Subject: Re: [vpp-dev] FW: Coverity build failed with 18 errors
> 
> 
> Hi Chris,
> 
> I just pushed:
>   https://gerrit.fd.io/r/#/c/9370/
> to fix the use of integer types in BIER.
> 
> I’ll look at the VOM ones too.
> 
> /neale
> 
> 
> -Original Message-
> From: <vpp-dev-boun...@lists.fd.io> on behalf of Chris Luke
> <chr...@flirble.org>
> Date: Thursday, 9 November 2017 at 22:05
> To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
> Subject: [vpp-dev] FW: Coverity build failed with 18 errors
> 
> FYI, Coverity has just failed to build because of issues in BIER 
(and maybe
> VOM); some of these may have existed a while, because these all 
seem
> to be
> warnings and Coverity fails a build based on number of rejected 
build
> units
> exceeding a % threshold. Likely BIER was merged and triggered the
> threshold.
> 
> I note that BIER is using C99 stdint types; Coverity appears to 
be fussy
> about how these get defined (missing include?); also we agreed 
here on
> this
> list just a few weeks ago that VPP uses its own typedefs for 
specified-
> width
> integers (u64 etc) so we should not be using such C99 types 
anyway.
> 
> For those interested, the Coverity build log is available at
> https://vpp.flirble.org/coverity/20171109/build-log.txt though 
please
> don't
> ask me to interpret it!
> 
> Chris.
> 
> -Original Message-
> From: VPP [mailto:v...@brae.flirble.org]
> Sent: Thursday, November 9, 2017 15:29
> To: chr...@flirble.org
> Subject: Coverity build failed with 18 errors
> 
> Coverity build failed with 18 errors.
> 
> Latest commit: v18.01-rc0-251-g75e974b
> 
> Error counts from cov-int/build-log.txt:
> 84205:[ERROR] [104291] EXECUTING: /bin/sed s|:*$||
> 84459:[ERROR] 1 error detected in the compilation of
> "../../../src/vnet/fib/fib_path.c".
> 91374:[ERROR] 1 error detected in the compilation of
> "../../../src/vnet/bier/bier_fmask.c".
> 91462:[ERROR] 1 error detected in the compilation of
> "../../../src/vnet/bier/bier_fmask_db.c".
> 91532:[ERROR] 1 error detected in the compilation of
> "../../../src/vnet/bier/bier_entry.c".
> 91700:[ERROR] 1 error detected in the compilation of
> "../../../src/vnet/bier/bier_output.c".
> 91775:[ERROR] 1 error detected in the compilation of
> "../../../src/vnet/bier/bier_table.c".
> 91828:[ERROR] 1 error detected in the compilation of
> "../../../src/vnet/bier/bier_lookup.c".
> 91840:[ERROR] 1 error detected in the compilation of
> "../../../src/vnet/bier/bier_fmask.c".
> 91847:[ERROR] 1 error detected in the compilation of
> "../../../src/vnet/bier/bier_fmask_db.c".
> 91954:[ERROR] 5 errors detected i

Re: [vpp-dev] FW: Coverity build failed with 18 errors

[Neale Ranns (nranns)]

Hi Chris,

And this one for VOM:
  https://gerrit.fd.io/r/#/c/9374/

/neale

-Original Message-
From: <vpp-dev-boun...@lists.fd.io> on behalf of "Neale Ranns (nranns)" 
<nra...@cisco.com>
Date: Friday, 10 November 2017 at 11:59
To: Chris Luke <chr...@flirble.org>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] FW: Coverity build failed with 18 errors


Hi Chris,

I just pushed:
  https://gerrit.fd.io/r/#/c/9370/
to fix the use of integer types in BIER.

I’ll look at the VOM ones too.

/neale
 

-Original Message-
From: <vpp-dev-boun...@lists.fd.io> on behalf of Chris Luke 
<chr...@flirble.org>
Date: Thursday, 9 November 2017 at 22:05
To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: [vpp-dev] FW: Coverity build failed with 18 errors

FYI, Coverity has just failed to build because of issues in BIER (and 
maybe
VOM); some of these may have existed a while, because these all seem to 
be
warnings and Coverity fails a build based on number of rejected build 
units
exceeding a % threshold. Likely BIER was merged and triggered the 
threshold.

I note that BIER is using C99 stdint types; Coverity appears to be fussy
about how these get defined (missing include?); also we agreed here on 
this
list just a few weeks ago that VPP uses its own typedefs for 
specified-width
integers (u64 etc) so we should not be using such C99 types anyway.

For those interested, the Coverity build log is available at
https://vpp.flirble.org/coverity/20171109/build-log.txt though please 
don't
ask me to interpret it!

Chris.

-Original Message-
From: VPP [mailto:v...@brae.flirble.org] 
Sent: Thursday, November 9, 2017 15:29
To: chr...@flirble.org
Subject: Coverity build failed with 18 errors

Coverity build failed with 18 errors.

Latest commit: v18.01-rc0-251-g75e974b

Error counts from cov-int/build-log.txt:
84205:[ERROR] [104291] EXECUTING: /bin/sed s|:*$||
84459:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/fib/fib_path.c".
91374:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask.c".
91462:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask_db.c".
91532:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_entry.c".
91700:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_output.c".
91775:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_table.c".
91828:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_lookup.c".
91840:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask.c".
91847:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask_db.c".
91954:[ERROR] 5 errors detected in the compilation of
"../../../src/vnet/bier/bier_types.c".
91982:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_entry.c".
92104:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_output.c".
92160:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_table.c".
92396:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_lookup.c".
92796:[ERROR] 5 errors detected in the compilation of
"../../../src/vnet/bier/bier_types.c".
93191:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_test.c".
93644:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_test.c".

Probable error information from the compiler:

84180:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_fmas
k.h",
84181-  line 57: error #20: identifier "uint32_t" is undefined
84182-  uint32_t bfmb_count;
84183-  ^
--

84428:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_fmas
k.h",
84429-  line 57: error #20: identifier "uint32_t" is undefined
84430-  uint32_t bfmb_count;
84431-  ^
--

87392:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/b

Re: [vpp-dev] FW: Coverity build failed with 18 errors

[Neale Ranns (nranns)]

Hi Chris,

I just pushed:
  https://gerrit.fd.io/r/#/c/9370/
to fix the use of integer types in BIER.

I’ll look at the VOM ones too.

/neale
 

-Original Message-
From:  on behalf of Chris Luke 
Date: Thursday, 9 November 2017 at 22:05
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] FW: Coverity build failed with 18 errors

FYI, Coverity has just failed to build because of issues in BIER (and maybe
VOM); some of these may have existed a while, because these all seem to be
warnings and Coverity fails a build based on number of rejected build units
exceeding a % threshold. Likely BIER was merged and triggered the threshold.

I note that BIER is using C99 stdint types; Coverity appears to be fussy
about how these get defined (missing include?); also we agreed here on this
list just a few weeks ago that VPP uses its own typedefs for specified-width
integers (u64 etc) so we should not be using such C99 types anyway.

For those interested, the Coverity build log is available at
https://vpp.flirble.org/coverity/20171109/build-log.txt though please don't
ask me to interpret it!

Chris.

-Original Message-
From: VPP [mailto:v...@brae.flirble.org] 
Sent: Thursday, November 9, 2017 15:29
To: chr...@flirble.org
Subject: Coverity build failed with 18 errors

Coverity build failed with 18 errors.

Latest commit: v18.01-rc0-251-g75e974b

Error counts from cov-int/build-log.txt:
84205:[ERROR] [104291] EXECUTING: /bin/sed s|:*$||
84459:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/fib/fib_path.c".
91374:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask.c".
91462:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask_db.c".
91532:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_entry.c".
91700:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_output.c".
91775:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_table.c".
91828:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_lookup.c".
91840:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask.c".
91847:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask_db.c".
91954:[ERROR] 5 errors detected in the compilation of
"../../../src/vnet/bier/bier_types.c".
91982:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_entry.c".
92104:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_output.c".
92160:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_table.c".
92396:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_lookup.c".
92796:[ERROR] 5 errors detected in the compilation of
"../../../src/vnet/bier/bier_types.c".
93191:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_test.c".
93644:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_test.c".

Probable error information from the compiler:
84180:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_fmas
k.h",
84181-  line 57: error #20: identifier "uint32_t" is undefined
84182-  uint32_t bfmb_count;
84183-  ^
--
84428:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_fmas
k.h",
84429-  line 57: error #20: identifier "uint32_t" is undefined
84430-  uint32_t bfmb_count;
84431-  ^
--
87392:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87393-  .h", line 56: warning #20: identifier "uint16_t" is
undefined
87394-  uint16_t index;
87395-  ^
--
87397:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87398-  .h", line 72: warning #20: identifier "uint16_t" is
undefined
87399-  uint16_t index;
87400-  ^
--
87402:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87403-  .h", line 87: warning #20: identifier "uint16_t" is
undefined
87404-  uint16_t index;
87405-  ^
--
87423:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87424-  .h", line 54: warning #1563: function
"bier_bit_string_is_zero" not
87425-  emitted, consider modeling it or review parse diagnostics to
improve
87426-  fidelity
--
87430:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87431-  .h", line 69: 

Re: [vpp-dev] And Boost Log too?

[Neale Ranns (nranns)]

Hi Jon,

It doesn’t need it. I must have left that in by mistake. I’ll take it out.

Thanks,
neale

From:  on behalf of Jon Loeliger 
Date: Wednesday, 8 November 2017 at 20:56
To: vpp-dev 
Subject: [vpp-dev] And Boost Log too?

Folks,

Looks like VPP top-of-tree needs boost_log now.  And it isn't
in the install-deps.  And my "yum install boost-log" goes MIA.

Hints?

Thanks,
jdl



g++ -o /home/jdl/workspace/vpp/build-root/vom_test/vom_test -I 
/home/jdl/workspace/vpp/src/vpp-api/ -std=c++11 -g -Wall -pthread 
-I/home/jdl/workspace/vpp/src 
-I/home/jdl/workspace/vpp/build-root/install-vpp-native//vpp/include 
-I/home/jdl/workspace/vpp/build-root/vapi_test/ -DBOOST_LOG_DYN_LINK -O0 -g 
vom_test.cpp 
/home/jdl/workspace/vpp/build-root/build-vpp-native/vpp/vpp-api/vom/.libs/libvom.so
 -lboost_log -lboost_thread -lboost_system -lboost_filesystem 
-lboost_unit_test_framework 
-L/home/jdl/workspace/vpp/build-root/build-vpp-native/vpp/.libs/ 
-L/home/jdl/workspace/vpp/build-root/build-vpp-native/vpp/vpp-api/vapi/.libs/ 
-lvppinfra -lvlibmemoryclient -lsvm -lpthread -lcheck -lrt -lm -lvapiclient 
-lsubunit
/usr/bin/ld: cannot find -lboost_log
collect2: error: ld returned 1 exit status
make[2]: *** [/home/jdl/workspace/vpp/build-root/vom_test/vom_test] Error 1
make[2]: Leaving directory `/home/jdl/workspace/vpp/test/ext'
make[1]: *** [ext] Error 2
make[1]: Leaving directory `/home/jdl/workspace/vpp/test'
make: *** [test] Error 2


# make install-dep -n
sudo -E yum groupinstall  'Development Tools'
sudo -E yum install  redhat-lsb glibc-static java-1.8.0-openjdk-devel yum-utils 
apr-devel numactl-devel check check-devel boost boost-devel openssl-devel 
python-devel python-virtualenv chrpath libffi-devel rpm-build

$ sudo yum install boost-log
Loaded plugins: auto-update-debuginfo, fastestmirror
Loading mirror speeds from cached hostfile
 * base: repo1.dal.innoscale.net
 * epel: kdeforge2.unl.edu
 * epel-debuginfo: mirror.steadfast.net
 * extras: repo1.dal.innoscale.net
 * updates: repo1.dal.innoscale.net
No package boost-log available.


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

Re: [vpp-dev] gtpu tunneling decap-next ip4 issue

[Neale Ranns (nranns)]

Hi Ryota-san,

I glad it works now. I couple of comments, marked [nr], on your setup are 
inline below.

Regards,
neale

-Original Message-
From: Ryota Yushina <r-yush...@ce.jp.nec.com>
Date: Monday, 6 November 2017 at 10:12
To: "Ni, Hongjun" <hongjun...@intel.com>, "Neale Ranns (nranns)" 
<nra...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] gtpu tunneling decap-next ip4 issue


To Hongjon-san, Neale-san

Thank you so much for your great help. This patch solved the problem!
ICMP packets were encapped and routed to target. 
As your discussion, vpp crashed at accessing gtpu_tunnel soruce mac address 
pointer(=null).


Below is just my memo.

I faced a new issue.
An decapped IP4 packet(inner ip4 packet) was through to "ip4-drop" via 
"ip4-input" from "gtpu4-input" on GTPu-endpoint(recv).
My expected graph flow was "gtpu4-input" -> "ip4-input" -> "ip4-lookup" -> 
...

So I created gtpu tunnel with following uses "node ip4-lookup" option 
instead of "ip4".
# create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  
encap-vrf-id 152 decap-next node ip4-lookup

It worked fine.

Followngs are my final configurations. Ping from vpp#3 returned from vpp#4 
via vpp#7.
<vpp#3>
set interface ip address TenGigabitEthernet82/0/1 10.9.0.3/16
ip route 11.9.0.0/16 via 10.9.0.1
set interface state TenGigabitEthernet82/0/1 up

<vpp#7>
set interface ip address TenGigabitEthernet82/0/1 10.9.0.1/16
set interface ip table TenGigabitEthernet82/0/0 152
set interface ip address TenGigabitEthernet82/0/0 192.168.152.70/24
create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  
encap-vrf-id 152 decap-next node ip4-lookup
set interface ip address gtpu_tunnel0 11.9.0.1/16
ip route 11.9.0.0/16 via gtpu_tunnel0

[nr] Having applied the subnet 11.9.0.0/16 to the GTPu interface, this route is 
unnecessary and in fact unused, since the interface configuration takes 
precedence. If you do ‘sh ip fib 11.9.0.0/16’ you should see both the 
‘src:interface’ and ‘src:CLI’.

ip route 10.9.0.0/16 via TenGigabitEthernet82/0/1
set interface state TenGigabitEthernet82/0/1 up
set interface state TenGigabitEthernet82/0/0 up

<vpp#4>
set interface ip table TenGigabitEthernet82/0/0 152
set interface ip address TenGigabitEthernet82/0/0 192.168.152.40/24
create gtpu tunnel src 192.168.152.40 dst 192.168.152.70 teid  
encap-vrf-id 152 decap-next node ip4-lookup
create loopback interaface
set interface ip address loop0 11.9.0.0.4/16

[nr] because you applied the 11.9.0.0/16 subnet to the loopback interface, 
there is no subnet configured on the GTP-u interface. Any interface type that 
does not have a configured IPv4 address cannot accept IPv4 traffic – that’s a 
basic security feature. Packets arriving on such an interface will be dropped 
just after ip4-input. If you were to apply the subnet on the GTP-u interface 
instead, then you would be able to revert your GTP-u tunnel decap-node 
configuration to perform ip4-input. This would be preferred since the 
decapsulated IP packets would then be subject to the usual input checks (i.e. 
TTL, chksum, etc).

ip route 10.9.0.0/16 via gtpu_tunnel0
set interface state TenGigabitEthernet82/0/0 up
set interface state loop0 up

> +- VPP#3 -
> |
> | [TenGigabitEthernet82/0/1: 10.9.0.3]
> +-- | 
> |
> +-VPP#7 | 
> | [TenGigabitEthernet82/0/1: 10.9.0.1]
> |
> | [gtpu_tunnel0: 11.9.0.1]
> |   |
> | [TenGigabitEthernet82/0/0: 192.168.152.70] --> vrf:152
> +-- || ---
> ||
> +-- || ---
> | [TenGigabitEthernet82/0/0: 192.168.152.40] --> vrf:152
> |
> | [loop0: 11.9.0.4]
> +- VPP#4 -

    ---
Best Regards,

Ryota Yushina,
NEC




> -Original Message-
> From: Ni, Hongjun [mailto:hongjun...@intel.com]
> Sent: Friday, November 03, 2017 10:50 AM
> To: Neale Ranns (nranns) <nra...@cisco.com>; Yushina Ryota(油科 亮太) 
<r-yush...@ce.jp.nec.com>; vpp-dev@lists.fd.io
> Subject: RE: [vpp-dev] gtpu tunneling decap-next ip4 issue
> 
> To Neale,
> Thank you for reminding. Have submitted a patch to fix it. 
https://gerrit.fd.io/r/#/c/9207/
> 
> To Ryota,
&g

Re: [vpp-dev] IPV6 Forwarding error

[Neale Ranns (nranns)]

Hi Ewan,

It should never be invalid. These sorts of checks in the data-plane only serve 
to reduce performance.
You should examine the VLIB nodes prior to the ipv6 lookup (multicast or 
unicast) to determine which one is setting the FIB index incorrectly.

Regards,
neale

From: "yug...@telincn.com" <yug...@telincn.com>
Date: Monday, 6 November 2017 at 04:55
To: "Neale Ranns (nranns)" <nra...@cisco.com>, vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: Re: [vpp-dev] IPV6 Forwarding error

Hi  neale,
I add this protection, but other errors come out in many different ways, all 
are ipv6 fib process errors.



fib_node_index_t
ip6_mfib_table_lookup2 (const ip6_mfib_t *mfib,
const ip6_address_t *src,
const ip6_address_t *grp)
{
ip6_mfib_node_t *i6mn;
ip6_mfib_key_t key;
if(!mfib)
return 0; (or  return ~0;)

IP6_MFIB_MK_KEY(grp, src, );

i6mn = (ip6_mfib_node_t*) rn_match(key.key,
   (struct radix_node_head *)mfib->rhead); 
// const cast

ASSERT(NULL != i6mn);

return (i6mn->i6mn_entry);
}


Regards,
Ewan

yug...@telincn.com

From: yug...@telincn.com<mailto:yug...@telincn.com>
Date: 2017-11-06 09:17
To: Neale Ranns (nranns)<mailto:nra...@cisco.com>; 
vpp-dev<mailto:vpp-dev@lists.fd.io>
Subject: Re: Re: [vpp-dev] IPV6 Forwarding error
Hi neale,
I've added a protection on it, but should it be invalid somehow?

Regards,
Ewan
________
yug...@telincn.com

From: Neale Ranns (nranns)<mailto:nra...@cisco.com>
Date: 2017-11-04 23:01
To: yug...@telincn.com<mailto:yug...@telincn.com>; 
vpp-dev<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] IPV6 Forwarding error

Hi Ewan,

I would guess that fib_index0 is invalid.

/neale

From: <vpp-dev-boun...@lists.fd.io> on behalf of "yug...@telincn.com" 
<yug...@telincn.com>
Date: Saturday, 4 November 2017 at 11:11
To: vpp-dev <vpp-dev@lists.fd.io>
Subject: [vpp-dev] IPV6 Forwarding error

Hi all,
Here is ipv6 forwarding error, my version is 17.04.
Any idea?




Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
mfib_forward_lookup (is_v4=0, frame=0x7fffb8626f00, node=0x7fffb5cffe80, 
vm=0x779aa2a0 )
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vnet/mfib/mfib_forward.c:305
305 mfei0 = ip6_mfib_table_lookup2(ip6_mfib_get(fib_index0),
(gdb) bt
#0  mfib_forward_lookup (is_v4=0, frame=0x7fffb8626f00, node=0x7fffb5cffe80, 
vm=0x779aa2a0 )
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vnet/mfib/mfib_forward.c:305
#1  ip6_mfib_forward_lookup (frame=0x7fffb8626f00, node=0x7fffb5cffe80, 
vm=0x779aa2a0 )
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vnet/mfib/mfib_forward.c:353
#2  ip6_mfib_forward_lookup_avx2 (vm=0x779aa2a0 , 
node=0x7fffb5cffe80, frame=0x7fffb8626f00)
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vnet/mfib/mfib_forward.c:369
#3  0x77757129 in dispatch_node (vm=0x779aa2a0 , 
node=0x7fffb5cffe80, type=,
dispatch_state=VLIB_NODE_STATE_POLLING, frame=, 
last_time_stamp=10161712619298)
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:998
#4  0x7775741d in dispatch_pending_node (vm=vm@entry=0x779aa2a0 
, p=0x7fffb8556de8,
last_time_stamp=) at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:1144
#5  0x77757e7d in vlib_main_or_worker_loop (is_main=1, 
vm=0x779aa2a0 )
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:1591
#6  vlib_main_loop (vm=0x779aa2a0 ) at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:1611
#7  vlib_main (vm=vm@entry=0x779aa2a0 , 
input=input@entry=0x7fffb4cd4fa0)
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:1739
#8  0x77790f23 in thread0 (arg=140737347494560) at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/unix/main.c:507
#9  0x75a3dce0 in clib_calljmp () at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vppinfra/longjmp.S:110
#10 0x7fffd410 in ?? ()
#11 0x7779193d in vlib_unix_main (argc=, argv=)
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/unix/main.c:606

Regards,
Ewan

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

Re: [vpp-dev] IPV6 Forwarding error

[Neale Ranns (nranns)]

Hi Ewan,

I would guess that fib_index0 is invalid.

/neale

From:  on behalf of "yug...@telincn.com" 

Date: Saturday, 4 November 2017 at 11:11
To: vpp-dev 
Subject: [vpp-dev] IPV6 Forwarding error

Hi all,
Here is ipv6 forwarding error, my version is 17.04.
Any idea?



Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
mfib_forward_lookup (is_v4=0, frame=0x7fffb8626f00, node=0x7fffb5cffe80, 
vm=0x779aa2a0 )
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vnet/mfib/mfib_forward.c:305
305 mfei0 = ip6_mfib_table_lookup2(ip6_mfib_get(fib_index0),
(gdb) bt
#0  mfib_forward_lookup (is_v4=0, frame=0x7fffb8626f00, node=0x7fffb5cffe80, 
vm=0x779aa2a0 )
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vnet/mfib/mfib_forward.c:305
#1  ip6_mfib_forward_lookup (frame=0x7fffb8626f00, node=0x7fffb5cffe80, 
vm=0x779aa2a0 )
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vnet/mfib/mfib_forward.c:353
#2  ip6_mfib_forward_lookup_avx2 (vm=0x779aa2a0 , 
node=0x7fffb5cffe80, frame=0x7fffb8626f00)
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vnet/mfib/mfib_forward.c:369
#3  0x77757129 in dispatch_node (vm=0x779aa2a0 , 
node=0x7fffb5cffe80, type=,
dispatch_state=VLIB_NODE_STATE_POLLING, frame=, 
last_time_stamp=10161712619298)
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:998
#4  0x7775741d in dispatch_pending_node (vm=vm@entry=0x779aa2a0 
, p=0x7fffb8556de8,
last_time_stamp=) at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:1144
#5  0x77757e7d in vlib_main_or_worker_loop (is_main=1, 
vm=0x779aa2a0 )
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:1591
#6  vlib_main_loop (vm=0x779aa2a0 ) at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:1611
#7  vlib_main (vm=vm@entry=0x779aa2a0 , 
input=input@entry=0x7fffb4cd4fa0)
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/main.c:1739
#8  0x77790f23 in thread0 (arg=140737347494560) at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/unix/main.c:507
#9  0x75a3dce0 in clib_calljmp () at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vppinfra/longjmp.S:110
#10 0x7fffd410 in ?? ()
#11 0x7779193d in vlib_unix_main (argc=, argv=)
at 
/home/wangzy/Desktop/VBRASV100R001/vpp1704/build-data/../src/vlib/unix/main.c:606

Regards,
Ewan

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

Re: [vpp-dev] Can't ping VPP int addr, until VPP int ping outside first

[Neale Ranns (nranns)]

Hi John,

Could you please provide a packet trace from VPP whilst it is unresponsive.

Thanks,
neale

From:  on behalf of John Wei 
Date: Friday, 3 November 2017 at 20:20
To: vpp-dev 
Subject: [vpp-dev] Can't ping VPP int addr, until VPP int ping outside first

I have configured tow interface within VPP
# vppctl show int addr
GigabitEthernet13/0/0 (up):
  192.168.50.166/24
GigabitEthernetb/0/0 (up):
  192.168.50.201/24
gre0 (up):
gre1 (up):
On a different node, on the same subnet (192.168.50.151), I was not able to get 
ping response from 166, until I did a "vppctl ping 192.168.50.151."

## on 192.168.50.151

# ping 192.168.50.166
PING 192.168.50.166 (192.168.50.166) 56(84) bytes of data.
From 192.168.50.151 icmp_seq=1 Destination Host Unreachable
<< delete repeated message>
From 192.168.50.151 icmp_seq=23 Destination Host Unreachable
From 192.168.50.151 icmp_seq=24 Destination Host Unreachable
<< On VPP node, did a vppctl ping 192.168.50.151>>
64 bytes from 192.168.50.166: icmp_seq=27 ttl=64 
time=0.498 ms
64 bytes from 192.168.50.166: icmp_seq=28 ttl=64 
time=0.435 ms
64 bytes from 192.168.50.166: icmp_seq=29 ttl=64 
time=0.316 ms
64 bytes from 192.168.50.166: icmp_seq=30 ttl=64 
time=0.469 ms
Any guess what I may have done wrong? Or, this is a v17.10 bug?


John





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

Re: [vpp-dev] dpdk output function

[Neale Ranns (nranns)]

Hi Yuliang,

It will call:
  vnet_interface_output_node()
from
 src/vnet/interface_output.c

There is also a TenGigabitEthernet5/0/1-tx node. Since you Are using DPDK on 
this interface, that will call:
  dpdk_interface_tx()
from
  src/plugins/dpdk/device/device.c

hth
neale

From:  on behalf of Yuliang Li 

Date: Wednesday, 1 November 2017 at 05:31
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] dpdk output function

Hi,

Some node is called "TenGigabitEthernet5/0/1-output". I am using dpdk on this 
interface. Does anyone know what is the function that this node calls?

Thanks,
--
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Segmentation fault in ikev2 test

[Neale Ranns (nranns)]

Hi Xyxue,

If you don’t have at a FIB with index 2 (i.e. you haven’t created to additional 
IP tables/VRFs) then:
  The '(vnet_buffer (p0)->sw_if_index[VLIB_TX] ' is 2 when 'del-sa' execute 
fail.

is certainly the cause of your crash. I would attempt to determine when and 
where this value was set in IPSEC path.
If it doesn’t happen all the time, then that’s often indicative of a single 
versus dual loop code path.

regards
neale


From:  on behalf of 薛欣颖 
Date: Tuesday, 31 October 2017 at 09:43
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Segmentation fault in ikev2 test


Hi,


I'm testing ikev2 and there is something error in my test:

 VPP# ikev2 initiate del-sa ee25d9aa4e7a0f1a
0: ikev2_generate_message:1774: sa state changed to 
IKEV2_STATE_NOTIFY_AND_DELETE

 Program received signal SIGSEGV, Segmentation fault.
0x2b293d767f4b in ip4_fib_mtrie_lookup_step_one (m=0x0, 
dst_address=0x2b2991d243f4) at 
/root/tmp64/build-data/../src/vnet/ip/ip4_mtrie.h:225
225   next_leaf = m->root_ply.leaves[dst_address->as_u16[0]];
(gdb) bt
#0  0x2b293d767f4b in ip4_fib_mtrie_lookup_step_one (m=0x0, 
dst_address=0x2b2991d243f4) at 
/root/tmp64/build-data/../src/vnet/ip/ip4_mtrie.h:225
#1  0x2b293d769bb3 in ip4_lookup_inline (vm=0x2b293d59c120 
, node=0x2b293f843080, frame=0x2b293fbfe800,
lookup_for_responses_to_locally_received_packets=0) at 
/root/tmp64/build-data/../src/vnet/ip/ip4_forward.c:362
#2  0x2b293d76a02f in ip4_lookup (vm=0x2b293d59c120 , 
node=0x2b293f843080, frame=0x2b293fbfe800)
at /root/tmp64/build-data/../src/vnet/ip/ip4_forward.c:472
#3  0x2b293d31b910 in dispatch_node (vm=0x2b293d59c120 , 
node=0x2b293f843080, type=VLIB_NODE_TYPE_INTERNAL,
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x2b293fbfe800, 
last_time_stamp=375367370313442) at 
/root/tmp64/build-data/../src/vlib/main.c:1032
#4  0x2b293d31bef3 in dispatch_pending_node (vm=0x2b293d59c120 
, pending_frame_index=0, last_time_stamp=375367370313442)
at /root/tmp64/build-data/../src/vlib/main.c:1182
#5  0x2b293d31e009 in vlib_main_or_worker_loop (vm=0x2b293d59c120 
, is_main=1) at /root/tmp64/build-data/../src/vlib/main.c:1649
#6  0x2b293d31e0bb in vlib_main_loop (vm=0x2b293d59c120 ) 
at /root/tmp64/build-data/../src/vlib/main.c:1668
#7  0x2b293d31e76f in vlib_main (vm=0x2b293d59c120 , 
input=0x2b293f728fb0) at /root/tmp64/build-data/../src/vlib/main.c:1804
#8  0x2b293d361d48 in thread0 (arg=47456122945824) at 
/root/tmp64/build-data/../src/vlib/unix/main.c:515
#9  0x2b293e2e8dcc in clib_calljmp () at 
/root/tmp64/build-data/../src/vppinfra/longjmp.S:128
#10 0x7ffcf2dbf510 in ?? ()
#11 0x2b293d3621e1 in vlib_unix_main (argc=4, argv=0x7ffcf2dc0798) at 
/root/tmp64/build-data/../src/vlib/unix/main.c:578
#12 0x00407ff1 in main (argc=4, argv=0x7ffcf2dc0798) at 
/root/tmp64/build-data/../src/vpp/vnet/main.c:206
(gdb)

in ip4_lookup_inline
'
fib_index0 =
vec_elt (im->fib_index_by_sw_if_index,
 vnet_buffer (p0)->sw_if_index[VLIB_RX]);
fib_index0 =
(vnet_buffer (p0)->sw_if_index[VLIB_TX] ==
 (u32) ~ 0) ? fib_index0 : vnet_buffer (p0)->sw_if_index[VLIB_TX];
'

The '(vnet_buffer (p0)->sw_if_index[VLIB_TX] ' is (u32) ~ 0 when 'del-sa' 
execute success.
The '(vnet_buffer (p0)->sw_if_index[VLIB_TX] ' is 2 when 'del-sa' execute fail.

By the way, the fault doesn't happen every time.

What should I do to solve the problem?

Thanks,
xyxue

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

Re: [vpp-dev] problem in l3 VLAN

[Neale Ranns (nranns)]

Hi Xyxue,

Support for VLANs on host/af_packet interface was added rather recently. See:
  https://gerrit.fd.io/r/#/c/8435/
and its cherry-picked cousins.

/neale


From:  on behalf of 薛欣颖 
Date: Tuesday, 31 October 2017 at 02:10
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] problem in l3 VLAN


Hi,

Is the vpp support l3 VLAN?

I'm testing two direct connect sub interfaces. The configuration and result are 
shown below:

vpp1:
VPP# set interface ip address host-eth2.1 1.1.1.2/24
VPP#
VPP# ping 1.1.1.1

Statistics: 5 sent, 0 received, 100% packet loss
VPP# show adj
[@0] ipv4-glean: host-eth1
[@1] ipv4-glean: host-eth2
[@2] ipv4 via 192.168.247.140 host-eth2: 000c2903f35c293129c20800
[@3] ipv4 via 192.1.190.254 host-eth1: 005056f225e2000c293129b80800
[@4] ipv4 via 192.168.247.254 host-eth2: 005056ec6077000c293129c20800
[@5] ipv4-glean: host-eth2.1
VPP#

vpp2:
VPP# show interface address
host-eth1 (up):
  192.3.1.130/24
host-eth2 (up):
  192.168.247.140/24
host-eth2.1 (up):
  1.1.1.1/24
VPP# show adj
[@0] ipv4-glean: host-eth1
[@1] ipv4-glean: host-eth2
[@2] ipv4 via 192.168.247.138 host-eth2: 000c293129c2000c2903f3500800
[@3] ipv4 via 192.3.1.1 host-eth1: 005056c7000c2903f3460800
[@4] ipv4 via 192.168.247.254 host-eth2: 005056ec6077000c2903f3500800
[@5] ipv4 via 192.3.1.254 host-eth1: 005056e6791c2903f3460800
[@6] ipv4-glean: host-eth2.1
VPP#

Thanks,
xyxue



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

Re: [vpp-dev] GRE error on vpp 17.04

[Neale Ranns (nranns)]

Hi Ewan,

As with all interface types, if you want to RX IP traffic on a GRE interface, 
then it either needs an IP address or to be unnumbered to another interface 
that has an address.

Regards,
neale

From: "yug...@telincn.com" <yug...@telincn.com>
Date: Wednesday, 25 October 2017 at 05:34
To: "Neale Ranns (nranns)" <nra...@cisco.com>, vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: Re: [vpp-dev] GRE error on vpp 17.04

Hi  neale,
Do we need to set ip address on gre interface?

Regards,
Ewan

____
yug...@telincn.com

From: Neale Ranns (nranns)<mailto:nra...@cisco.com>
Date: 2017-10-24 19:07
To: yug...@telincn.com<mailto:yug...@telincn.com>; 
vpp-dev<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] GRE error on vpp 17.04
Hi Ewan,

I have more positive results;

vagrant@localhost:/vpp$ vppctl
vpp#
vpp# sh int
  Name   Idx   State  Counter  Count
local00down
vpp# create gre tunnel src 1.1.1.1 dst 2.2.2.2
gre0
vpp# set int ip address gre0 9.9.9.1/24
vpp# sh int addr
gre0 (dn):
  9.9.9.1/24
local0 (dn):
vpp# sh ver
vpp v17.04.2-4~ga8f93f8 built by vagrant on localhost at Tue Oct 24 02:20:15 
PDT 2017
vpp#

perhaps there is something broken with your VPP install?

/neale


From: "yug...@telincn.com" <yug...@telincn.com>
Date: Tuesday, 24 October 2017 at 10:10
To: "Neale Ranns (nranns)" <nra...@cisco.com>, vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: Re: [vpp-dev] GRE error on vpp 17.04

Hi neale,
There is no overlapping sub-net, here are more info.


root@ubuntu:/home/ewan# vppctl create gre tunnel src 1.1.1.1 dst 2.2.2.2
gre0

root@ubuntu:/home/ewan# vppctl show int addr
gre0 (dn):
local0 (dn):

root@ubuntu:/home/ewan# vppctl set int ip address gre0  9.9.9.1/24
exec error: Misc



Regards,
Ewan

yug...@telincn.com

From: Neale Ranns (nranns)
Date: 2017-10-24 00:06
To: yug...@telincn.com; vpp-dev
Subject: Re: [vpp-dev] GRE error on vpp 17.04

Hi Ewan,

Are you adding an overlapping sub-net?
Can we see please:
  sh int addr

regards,
neale


From: <vpp-dev-boun...@lists.fd.io> on behalf of "yug...@telincn.com" 
<yug...@telincn.com>
Date: Monday, 23 October 2017 at 10:20
To: vpp-dev <vpp-dev@lists.fd.io>
Subject: [vpp-dev] GRE error on vpp 17.04

Hi all, I've encountered one error when I try  GRE function, here are details, 
any idea?




root@test:~# vppctl show int
  Name   Idx   State  Counter  Count
GigabitEthernet0/19/0 1 up
GigabitEthernet2/0/0  2 up   rx packets
254671
 rx bytes
37541529
 tx packets 
48109
 tx bytes 
2086857
 drops 
254385
 punts  
  276
 ip4
79595
 ip6   
158846
 tx-error   
   14
gre0  5down
host-vGE0_19_03 up   rx packets 
 1173
 rx bytes  
166827
 drops  
 1173
 ip6
 1173
host-vGE2_0_0 4 up   rx packets 
 2004
 rx bytes  
270989
 tx packets 
32301
 tx bytes
10289989
 drops  
 1813
 ip4
  804
 ip6
 1182
local00down

root@test:~# vppctl set int ip address gre0 9.9.9.1/24
exec error: Misc




root@vbras:~#



Regards,
EWAN


yug...@telincn.com


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

Re: [vpp-dev] GRE error on vpp 17.04

[Neale Ranns (nranns)]

Hi Ewan,

I have more positive results;

vagrant@localhost:/vpp$ vppctl
vpp# 
vpp# sh int
              Name               Idx       State          Counter          
Count     
local0                            0        down      
vpp# create gre tunnel src 1.1.1.1 dst 2.2.2.2
gre0
vpp# set int ip address gre0 9.9.9.1/24 
vpp# sh int addr
gre0 (dn):
  9.9.9.1/24
local0 (dn):
vpp# sh ver
vpp v17.04.2-4~ga8f93f8 built by vagrant on localhost at Tue Oct 24 02:20:15 
PDT 2017
vpp# 

perhaps there is something broken with your VPP install?

/neale


From: "yug...@telincn.com" <yug...@telincn.com>
Date: Tuesday, 24 October 2017 at 10:10
To: "Neale Ranns (nranns)" <nra...@cisco.com>, vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: Re: [vpp-dev] GRE error on vpp 17.04

Hi neale,
There is no overlapping sub-net, here are more info.


root@ubuntu:/home/ewan# vppctl create gre tunnel src 1.1.1.1 dst 2.2.2.2 
gre0

root@ubuntu:/home/ewan# vppctl show int addr
gre0 (dn):
local0 (dn):

root@ubuntu:/home/ewan# vppctl set int ip address gre0  9.9.9.1/24 
exec error: Misc

 

Regards,
Ewan
____
yug...@telincn.com
 
From: Neale Ranns (nranns)
Date: 2017-10-24 00:06
To: yug...@telincn.com; vpp-dev
Subject: Re: [vpp-dev] GRE error on vpp 17.04
 
Hi Ewan,
 
Are you adding an overlapping sub-net?
Can we see please:
  sh int addr
 
regards,
neale
 
 
From: <vpp-dev-boun...@lists.fd.io> on behalf of "yug...@telincn.com" 
<yug...@telincn.com>
Date: Monday, 23 October 2017 at 10:20
To: vpp-dev <vpp-dev@lists.fd.io>
Subject: [vpp-dev] GRE error on vpp 17.04
 
Hi all, I've encountered one error when I try  GRE function, here are details, 
any idea?
 



root@test:~# vppctl show int
  Name   Idx   State  Counter  
Count 
GigabitEthernet0/19/0 1 up   
GigabitEthernet2/0/0  2 up   rx packets
254671
 rx bytes
37541529
 tx packets 
48109
 tx bytes 
2086857
 drops 
254385
 punts  
  276
 ip4
79595
 ip6   
158846
 tx-error   
   14
gre0  5down  
host-vGE0_19_03 up   rx packets 
 1173
 rx bytes  
166827
 drops  
 1173
 ip6
 1173
host-vGE2_0_0 4 up   rx packets 
 2004
 rx bytes  
270989
 tx packets 
32301
 tx bytes
10289989
 drops  
 1813
 ip4
  804
 ip6
 1182
local00down  

root@test:~# vppctl set int ip address gre0 9.9.9.1/24
exec error: Misc




root@vbras:~# 



Regards,
EWAN
 

yug...@telincn.com


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

Re: [vpp-dev] GRE error on vpp 17.04

[Neale Ranns (nranns)]

Hi Ewan,

Are you adding an overlapping sub-net?
Can we see please:
  sh int addr

regards,
neale


From:  on behalf of "yug...@telincn.com" 

Date: Monday, 23 October 2017 at 10:20
To: vpp-dev 
Subject: [vpp-dev] GRE error on vpp 17.04

Hi all, I've encountered one error when I try  GRE function, here are details, 
any idea?



root@test:~# vppctl show int
  Name   Idx   State  Counter  Count
GigabitEthernet0/19/0 1 up
GigabitEthernet2/0/0  2 up   rx packets
254671
 rx bytes
37541529
 tx packets 
48109
 tx bytes 
2086857
 drops 
254385
 punts  
  276
 ip4
79595
 ip6   
158846
 tx-error   
   14
gre0  5down
host-vGE0_19_03 up   rx packets 
 1173
 rx bytes  
166827
 drops  
 1173
 ip6
 1173
host-vGE2_0_0 4 up   rx packets 
 2004
 rx bytes  
270989
 tx packets 
32301
 tx bytes
10289989
 drops  
 1813
 ip4
  804
 ip6
 1182
local00down

root@test:~# vppctl set int ip address gre0 9.9.9.1/24
exec error: Misc



root@vbras:~#


Regards,
EWAN


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

Re: [vpp-dev] not_last parameter of ip_add_del_route from ip.api

[Neale Ranns (nranns)]

Hi Marek,

It can be removed.

/neale

From: "Dave Barach (dbarach)" <dbar...@cisco.com>
Date: Wednesday, 18 October 2017 at 13:30
To: "Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)" 
<mgrad...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, "Neale Ranns 
(nranns)" <nra...@cisco.com>
Subject: RE: not_last parameter of ip_add_del_route from ip.api

Adding Neale for further comment, but I believe it’s a FIB 1.0 historical 
artifact which has no obvious reason to exist at this point.

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)
Sent: Wednesday, October 18, 2017 5:59 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] not_last parameter of ip_add_del_route from ip.api

Hi,

while working on adding MPLS support to HC,
I noticed that ‘not_last’ param of ip_add_del_route
is ignored by the message handler in ip_api.c:
https://gerrit.fd.io/r/#/c/8826/

Could it be removed or I missed something?

Regards,
Marek

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

Re: [vpp-dev] [vppsb-dev] Router plugin with VPP 1707 - incoming OSPF Hello packets are dropped by VPP

[Neale Ranns (nranns)]

Hi Michael,

It is present in 17.04 also.

/neale


From: Michael Borokhovich <michael...@gmail.com>
Date: Wednesday, 11 October 2017 at 19:09
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: "Shaw, Jeffrey B" <jeffrey.b.s...@intel.com>, "vppsb-...@lists.fd.io" 
<vppsb-...@lists.fd.io>, vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] [vppsb-dev] Router plugin with VPP 1707 - incoming OSPF 
Hello packets are dropped by VPP

Hi Neale,

Was the mfib present in 1704? If not, maybe I can try router plugin with the 
recent fixes on 1704?

Thanks,
Michael.


On Wed, Oct 11, 2017 at 4:59 AM, Neale Ranns (nranns) 
<nra...@cisco.com<mailto:nra...@cisco.com>> wrote:
Hi Michael,

It doesn’t work in 17.07 because we introduced the IP-multicast FIB (mfib). 
Your 224.0.0.0/24<http://224.0.0.0/24> route now needs to be in the mfib not 
the unicast FIB. Please try the mfib APIs I mentioned in my previous mail.

Thanks,
Neale



From: Michael Borokhovich <michael...@gmail.com<mailto:michael...@gmail.com>>
Date: Wednesday, 11 October 2017 at 05:34
To: "Neale Ranns (nranns)" <nra...@cisco.com<mailto:nra...@cisco.com>>
Cc: "Shaw, Jeffrey B" 
<jeffrey.b.s...@intel.com<mailto:jeffrey.b.s...@intel.com>>, 
"vppsb-...@lists.fd.io<mailto:vppsb-...@lists.fd.io>" 
<vppsb-...@lists.fd.io<mailto:vppsb-...@lists.fd.io>>, vpp-dev 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] [vppsb-dev] Router plugin with VPP 1707 - incoming OSPF 
Hello packets are dropped by VPP

Hi Neale,

In the router plugin, the code below ("vppsb/router/router/tap_inject.c") 
should make sure that incoming multicast packets are forwarded from VPP to 
Linux. However, it does not work if "FIN_VERSION" is not 1 (i.e., it works for 
1609 but not for 1707). Do you have any idea why?

Thanks!
Michael.

Hi Michael,

Both of;
  vppctl ip mroute 224.0.0.0/8<http://224.0.0.0/8> via GigabitEthernet0/4/0 
Accept
  vppctl ip mroute 224.0.0.0/8<http://224.0.0.0/8> via local Forward
the first says you are accepting (i.e RPF checks on) GigE0/4/0 the second says 
you are ‘forwarding/replicating’ to VPP’s local IP stack.

The mfib equivalent of the fib API you were using is;
  extern fib_node_index_t mfib_table_entry_special_add(u32 fib_index,
 const mfib_prefix_t 
*prefix,
 mfib_source_t source,
 mfib_entry_flags_t flags,
 index_t rep_dpo);

if you include the flag MFIB_ENTRY_ACCEPT_ALL_ITF then mfib will accept from 
any incoming interface, hence you won’t need an explicit ‘Accept’ rule. But 
this API is strict about the last argument ‘dpo’ being a replicate DPO type. 
See the mfib_test.c examples on how to construct one for use with the API.


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

Re: [vpp-dev] [vppsb-dev] Router plugin with VPP 1707 - incoming OSPF Hello packets are dropped by VPP

[Neale Ranns (nranns)]

Hi Michael,

It doesn’t work in 17.07 because we introduced the IP-multicast FIB (mfib). 
Your 224.0.0.0/24 route now needs to be in the mfib not the unicast FIB. Please 
try the mfib APIs I mentioned in my previous mail.

Thanks,
Neale



From: Michael Borokhovich <michael...@gmail.com>
Date: Wednesday, 11 October 2017 at 05:34
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: "Shaw, Jeffrey B" <jeffrey.b.s...@intel.com>, "vppsb-...@lists.fd.io" 
<vppsb-...@lists.fd.io>, vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] [vppsb-dev] Router plugin with VPP 1707 - incoming OSPF 
Hello packets are dropped by VPP

Hi Neale,

In the router plugin, the code below ("vppsb/router/router/tap_inject.c") 
should make sure that incoming multicast packets are forwarded from VPP to 
Linux. However, it does not work if "FIN_VERSION" is not 1 (i.e., it works for 
1609 but not for 1707). Do you have any idea why?

Thanks!
Michael.

Hi Michael,

Both of;
  vppctl ip mroute 224.0.0.0/8<http://224.0.0.0/8> via GigabitEthernet0/4/0 
Accept
  vppctl ip mroute 224.0.0.0/8<http://224.0.0.0/8> via local Forward
the first says you are accepting (i.e RPF checks on) GigE0/4/0 the second says 
you are ‘forwarding/replicating’ to VPP’s local IP stack.

The mfib equivalent of the fib API you were using is;
  extern fib_node_index_t mfib_table_entry_special_add(u32 fib_index,
 const mfib_prefix_t 
*prefix,
 mfib_source_t source,
 mfib_entry_flags_t flags,
 index_t rep_dpo);

if you include the flag MFIB_ENTRY_ACCEPT_ALL_ITF then mfib will accept from 
any incoming interface, hence you won’t need an explicit ‘Accept’ rule. But 
this API is strict about the last argument ‘dpo’ being a replicate DPO type. 
See the mfib_test.c examples on how to construct one for use with the API.


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

Re: [vpp-dev] Mac Address Api Changes

[Neale Ranns (nranns)]

+1

From:  on behalf of Jon Loeliger 
Date: Tuesday, 10 October 2017 at 22:55
To: "John Lo (loj)" 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Mac Address Api Changes

On Tue, Oct 10, 2017 at 2:41 PM, John Lo (loj) 
> wrote:
The two APIs affected are the older ones in L2FIB which use “u64 mac” instead 
of “u8 mac[6]” to pass MAC addresses:

•L2fib_add_del

•L2_fib_table_details

I believe it is a good change to reduce confusion wrt how 6-byte MAC is stored 
in u64 with big/little endian hosts. The change would also require updates to 
user programs of these APIs, which we believe should be minimal.

If we don’t get strong objections within a week, we will assume the change is 
acceptable and allow this API change in the master branch. It won’t affect 
17.10 release.

Regards,
John

Sure.  +1

jdl

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

Re: [vpp-dev] [vppsb-dev] Router plugin with VPP 1707 - incoming OSPF Hello packets are dropped by VPP

[Neale Ranns (nranns)]

Hi Michael,

Both of;
  vppctl ip mroute 224.0.0.0/8 via GigabitEthernet0/4/0 Accept
  vppctl ip mroute 224.0.0.0/8 via local Forward
the first says you are accepting (i.e RPF checks on) GigE0/4/0 the second says 
you are ‘forwarding/replicating’ to VPP’s local IP stack.

The mfib equivalent of the fib API you were using is;
  extern fib_node_index_t mfib_table_entry_special_add(u32 fib_index,
 const mfib_prefix_t 
*prefix,
 mfib_source_t source,
 mfib_entry_flags_t flags,
 index_t rep_dpo);

if you include the flag MFIB_ENTRY_ACCEPT_ALL_ITF then mfib will accept from 
any incoming interface, hence you won’t need an explicit ‘Accept’ rule. But 
this API is strict about the last argument ‘dpo’ being a replicate DPO type. 
See the mfib_test.c examples on how to construct one for use with the API.


/neale

From:  on behalf of Michael Borokhovich 

Date: Tuesday, 10 October 2017 at 00:41
To: "Shaw, Jeffrey B" 
Cc: "vppsb-...@lists.fd.io" , vpp-dev 

Subject: Re: [vpp-dev] [vppsb-dev] Router plugin with VPP 1707 - incoming OSPF 
Hello packets are dropped by VPP

I tried various options, like below, but none of the work. How can I use the 
mroute to specify a node (and not an interface or an address)? 

vppctl ip mroute 224.0.0.0/8 via GigabitEthernet0/4/0
vppctl ip mroute 224.0.0.0/8 via GigabitEthernet0/4/0 Accept
vppctl ip mroute 224.0.0.0/8 via GigabitEthernet0/4/0 Forward

On Mon, Oct 9, 2017 at 6:36 PM, Shaw, Jeffrey B  
wrote:
Probably, but I don’t know the command.  Essentially you want a CLI command 
that configures a fib to direct packets/flows to an arbitrary node.
 
Maybe “ip route” or “ip mroute” has what you need.
 
DBGvpp# ip help
  mroute ip mroute [add|del] / 
[table ] [via  [],
… 
  route  ip route [add|del] [count ] 
/ [table ] [via  \
   [] [weight ]] 
| [via arp  ] |
   [via 
drop|punt|local|arp|classify ] [lookup in table 
]
 
-Jeff
 
From: Michael Borokhovich [mailto:michael...@gmail.com] 
Sent: Monday, October 09, 2017 3:26 PM
To: Shaw, Jeffrey B 
Cc: vpp-dev ; vppsb-...@lists.fd.io

Subject: Re: [vppsb-dev] Router plugin with VPP 1707 - incoming OSPF Hello 
packets are dropped by VPP
 
Jef, is there a cli command I can use to instruct VPP to forward multicast to 
that node?
 
On Mon, Oct 9, 2017 at 6:23 PM, Shaw, Jeffrey B  
wrote:
We have this code, which is supposed to tell the fib that packets going to the 
224.0.0.x/24 network should be delivered to our node.
 
  {
    dpo_proto_t proto = 0;
    dpo_id_t dpo = DPO_INVALID;
    fib_prefix_t pfx = {};
 
    pfx.fp_addr.ip4.as_u32 = 0x00E0; /* 224.0.0.0 */
    pfx.fp_len = 24;
    pfx.fp_proto = FIB_PROTOCOL_IP4;
    proto = DPO_PROTO_IP4;
 
    vlib_node_add_next (vm, ip4_lookup_node.index, im->tx_node_index);
 
    dpo_set(, tap_inject_dpo_type, proto, ~0);
 
    fib_table_entry_special_dpo_add(0,
  ,
  FIB_SOURCE_API,
  FIB_ENTRY_FLAG_EXCLUSIVE,
  );
 
    dpo_reset();
  }
 
It is possible this code isn’t working the same as it has in the past.
 
With the FIB changes since the router plugin was initially developed, there 
might be a different/better way to get multicast packets delivered to our node.
 
-Jef
 
 
From: vppsb-dev-boun...@lists.fd.io [mailto:vppsb-dev-boun...@lists.fd.io] On 
Behalf Of Michael Borokhovich
Sent: Monday, October 09, 2017 3:16 PM
To: vpp-dev ; vppsb-...@lists.fd.io
Subject: Re: [vppsb-dev] Router plugin with VPP 1707 - incoming OSPF Hello 
packets are dropped by VPP
 
Here is the trace of the packet that is dropped. Any help is very appreciated.
 
00:05:18:275995: dpdk-input
  GigabitEthernet0/4/0 rx queue 0
  buffer 0x446a: current data 14, length 68, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x1
  PKT MBUF: port 0, nb_segs 1, pkt_len 82
    buf_len 2176, data_len 82, ol_flags 0x0, data_off 128, phys_addr 0x6990d980
    packet_type 0x0
  IP4: fa:16:3e:4a:b3:60 -> 01:00:5e:00:00:05
  OSPF: 10.0.10.1 -> 224.0.0.5
    tos 0xc0, ttl 1, length 68, checksum 0x2986
    fragment id 0x9b15
00:05:18:276166: ip4-input
  OSPF: 10.0.10.1 -> 224.0.0.5
    tos 0xc0, ttl 1, length 68, checksum 0x2986
    fragment id 0x9b15
00:05:18:276403: ip4-mfib-forward-lookup
  fib 0 entry 0
00:05:18:276503: ip4-mfib-forward-rpf
  entry 0 -1 
00:05:18:276516: ip4-drop
    OSPF: 10.0.10.1 -> 224.0.0.5
      tos 0xc0, ttl 

Re: [vpp-dev] Router plugin with VPP 1707 - incoming OSPF Hello packets are dropped by VPP

[Neale Ranns (nranns)]

Hi Michael,

Could you give me a ‘sh trace’ ?

Thanks,
neale

From:  on behalf of Michael Borokhovich 

Date: Monday, 9 October 2017 at 18:14
To: vpp-dev 
Subject: [vpp-dev] Router plugin with VPP 1707 - incoming OSPF Hello packets 
are dropped by VPP

Hi,

After applying the fixes suggested by Jeff, I was able to compile the router 
plugin with VPP 1707.

It runs and allows to enable tap-inject and set up interfaces addresses without 
crashing.

The problem I'm facing now is with setting up FRR OSPF on top of the VPP+router 
plugin.

FRR OSPF is configured and I see OSPF Hello packets flowing out of the machine. 
However, the incoming OSPF Hello packets are dropped by VPP (with the reason 
"ip4 adjacency drop") and never reach the FRR.

The same settings worked with VPP 1609 + router plugin. Maybe I need to 
configure something manually in VPP to allow reception of OSPF multicast 
packets?

So, to summarize the problem, incoming OSPF Hello packets are dropped by VPP, 
while the outgoing hello packets successfully sent by FRR via VPP to the 
neighbouring router.

Any help is appreciated.

Thanks,
Michael.


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

Re: [vpp-dev] Multiple VRFs in 1609

[Neale Ranns (nranns)]

Hi Michael,

It would be best if you fixed the caller to not pass ~0. In this case the ~0 is 
coming from the packet VLIB_RX interface. So best to find and fix the input 
node that should have set this correctly.

/neale

From: Michael Borokhovich <michael...@gmail.com>
Date: Friday, 6 October 2017 at 15:49
To: "Shaw, Jeffrey B" <jeffrey.b.s...@intel.com>
Cc: "Pierre Pfister (ppfister)" <ppfis...@cisco.com>, Florin Coras 
<fcoras.li...@gmail.com>, vpp-dev <vpp-dev@lists.fd.io>, "Neale Ranns (nranns)" 
<nra...@cisco.com>, "vppsb-...@lists.fd.io" <vppsb-...@lists.fd.io>
Subject: Re: [vpp-dev] Multiple VRFs in 1609

Hi Jeff,

Regarding the workaround for the problem [3] (segfault). Do you think it is 
enough just to add a simple check e.g., if(index != ~0)? Or we have a problem 
somewhere else since the ~0 index should not be passed to this function?

Thanks,
Michael.


On Thu, Oct 5, 2017 at 1:03 PM, Shaw, Jeffrey B 
<jeffrey.b.s...@intel.com<mailto:jeffrey.b.s...@intel.com>> wrote:
Hi Michael, do you really need the router plugin?  Based on the commands you’re 
using it seems you’re adding routes using the vpp cli interface, which is not 
how the router plugin is supposed to work.  Those routes won’t show up on the 
control side (i.e. Linux).  Nor is there any support for multiple routing 
tables.  The routes should be added from the control side, then they are 
mirrored to VPP.

@Pierre,
I was able to get the router plugin to work with VPP 1707 (348edb1 
[origin/stable/1707] Set MAC address needs the HW interface index).
I used vppsb commit 529ec1b [origin/master] Fix name of VCL LD_PRELOAD lib dir 
env var.

A few things went wrong:

1)  Had to disable testrtnl_plugin in vppsb/netlink[1] to get netlink to 
compile

2)  Delete the reference to vlib_buffer_chain_validate() in vppsb/router 
after symbol lookup failure[2]

3)  Work-around a segmentation fault[3] in 
vlib_increment_simple_counter()due to an index being set to ~0

I can submit two patches to fix 1 and 2.

For number 3, it looks like we might want to check for an invalid interface?  
This function is probably used often, so adding that check will be bad for 
performance.  Maybe we can check for invalid interface in process_drop_punt() 
instead.

always_inline void
vlib_increment_simple_counter (vlib_simple_counter_main_t * cm,
   u32 thread_index, u32 index, u64 increment)
{
  counter_t *my_counters;

  my_counters = cm->counters[thread_index];
  my_counters[index] += increment;  <--- 
seg-fault happens here when index is ~0, maybe check it?
}


-Jeff

More details…

[1] Building netlink fails... need to disable test.c

/root/vpp/build-data/../netlink/test/test.c: In function 
‘mapper_ns_add_command_fn’:
/root/vpp/build-data/../netlink/test/test.c:125:14: error: implicit declaration 
of function ‘ip4_fib_index_from_table_id’ 
[-Werror=implicit-function-declaration]
   u32 fib4 = ip4_fib_index_from_table_id(table_id);
  ^
/root/vpp/build-data/../netlink/test/test.c:126:14: error: implicit declaration 
of function ‘ip6_fib_index_from_table_id’ 
[-Werror=implicit-function-declaration]
   u32 fib6 = ip6_fib_index_from_table_id(table_id);
  ^
cc1: all warnings being treated as errors


[2] After "enable tap-inject", we see vpp0 in the Linux "ip link". Setting "ip 
link set dev vpp0 up" produces the following error... need to not call that 
function.

/root/vpp/build-root/install-vpp_debug-native/vpp/bin/vpp: symbol lookup error: 
/usr/lib/vpp_plugins/router.so: undefined symbol: vlib_buffer_chain_validate


[3] Segmentation fault because the "index" is ~0
Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x76d985a6 in vlib_increment_simple_counter (cm=0x7fffb67143bc, 
thread_index=0, index=4294967295, increment=1) at 
/root/vpp/build-data/../src/vlib/counter.h:84
84my_counters[index] += increment;
(gdb) bt
#0  0x76d985a6 in vlib_increment_simple_counter (cm=0x7fffb67143bc, 
thread_index=0, index=4294967295, increment=1) at 
/root/vpp/build-data/../src/vlib/counter.h:84
#1  0x76d9c8d8 in process_drop_punt (vm=0x77b9d440 
, node=0x7fffb6758ec0, frame=0x7fffb5c92400, 
disposition=VNET_ERROR_DISPOSITION_DROP) at 
/root/vpp/build-data/../src/vnet/interface_output.c:1018
#2  0x76d9cebb in process_drop (vm=0x77b9d440 , 
node=0x7fffb6758ec0, frame=0x7fffb5c92400) at 
/root/vpp/build-data/../src/vnet/interface_output.c:1155
#3  0x778f40f0 in dispatch_node (vm=0x77b9d440 , 
node=0x7fffb6758ec0, type=VLIB_NODE_TYPE_INTERNAL, 
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffb5c92400, 
last_time_stamp=1322800753683)
at /root/vpp/build-data/../src/vlib/main.c:1016
#4  0x778f46a9 in dispatch_pending_node (vm=0x77b9d440 
, pen

Re: [vpp-dev] Adding IP Addr to Multiple IFs

[Neale Ranns (nranns)]

Hi Jon,

We don’t support overlapping subnets on interfaces. I was trying to fix the 
cases where it is errorneously allowed with this patch:
  https://gerrit.fd.io/r/#/c/8057/
but I’ve not yet found all the CSIT failures yet.

/neale

From:  on behalf of Jon Loeliger 
Date: Thursday, 28 September 2017 at 10:20
To: vpp-dev 
Subject: [vpp-dev] Adding IP Addr to Multiple IFs

Packet Handlers,

I have a question regarding adding IP address on multiple interfaces.
I know.  Seems like it should be obvious and easy.  But I am not really
a Domain Expert here.  So questions about both expected behavior
and a possible bug.  We'll see.

Let's start with this sequence of vppctl commands:
vpp# show int
  Name   Idx   State  Counter  Count
TenGigabitEthernet6/0/0   1down
TenGigabitEthernet6/0/1   2down
TenGigabitEthernet6/0/2   3down
TenGigabitEthernet6/0/3   4down
local00down
vpp# set interface ip address TenGigabitEthernet6/0/0 
1.2.3.4/32
vpp# set interface ip address TenGigabitEthernet6/0/0 
1.2.3.4/32
set interface ip address: failed to add 1.2.3.4/32 which 
conflicts with 1.2.3.4/32 for interface 
TenGigabitEthernet6/0/0

So VPP has recognized an overlapping request and complains.  Good.
But not that it is an exact overlap and could have let it slide.  Ah well.
vpp# set interface ip address TenGigabitEthernet6/0/1 
1.2.3.4/32
vpp#

Hrm.  No complaint here.  Turns out the address is already associated
with FIB/table_id 0.  OK.

But also, no IP address added to the second IF either:
vpp# show int address
TenGigabitEthernet6/0/0 (dn):
  1.2.3.4/32
TenGigabitEthernet6/0/1 (dn):
TenGigabitEthernet6/0/2 (dn):
TenGigabitEthernet6/0/3 (dn):
local0 (dn):

Which means it was silently accepted, but didn't do what was asked of it.
To be very clear, that means that at the layer above the API call here,
there is no way to determine if that API call was successful or not.  In fact,
that API call always returns "0 == ALL OK" in these cases.  So any layer
above the API that relied on that return value to store configuration requests
in a side DB just got lied to and won't do the Right Thing here.

So, digging.

I think the first layer problem is in function
vl_api_sw_interface_add_del_address_t_handler():
static void vl_api_sw_interface_add_del_address_t_handler
  (vl_api_sw_interface_add_del_address_t * mp)
{
  vlib_main_t *vm = vlib_get_main ();
  vl_api_sw_interface_add_del_address_reply_t *rmp;
  int rv = 0;
  u32 is_del;
  VALIDATE_SW_IF_INDEX (mp);
  is_del = mp->is_add == 0;
  if (mp->del_all)
ip_del_all_interface_addresses (vm, ntohl (mp->sw_if_index));
  else if (mp->is_ipv6)
ip6_add_del_interface_address (vm, ntohl (mp->sw_if_index),
   (void *) mp->address,
   mp->address_length, is_del);
  else
ip4_add_del_interface_address (vm, ntohl (mp->sw_if_index),
   (void *) mp->address,
   mp->address_length, is_del);
  BAD_SW_IF_INDEX_LABEL;
  REPLY_MACRO (VL_API_SW_INTERFACE_ADD_DEL_ADDRESS_REPLY);

}
Notice that the REPLY_MACRO() always picks of a return value as rv = 0.
So we can add "error = ..." to the add and delete arms, and slam it to 0 in the
"delete all" arm, and check for a non-null error to return rv = -1 instead.
Adding all that doesn't fix it.  (Note that over in ip46_cli.c this is 
essentially
the approach taken there.)

Landing in ip4_add_del_interface_address_internal(), the FIB on the sw_if_index
is located and the additional IP addr is checked for conflicts with existing 
entries
in the foreach_ip_interface_address() macro loop.  That's all fine.

It then passes the buck to  ip_interface_address_add_del() along with the FIB.
The outline of that routine sort of goes like this:

addr = lookup IP addr in FIB table
check something

if (del)
delete ip addr
set invalid addr index return parameter
else if (addr failed to lookup above)
add ip addr
set new addr index return parameter
else
silently say we have ip addr already
set addr index from lookup in return parameter

return success

That last "return success" basically means everything will always
be happy all the way back to an initial API call essentially every time.

So.  In the case of adding the same IP address to a second IF, that
just happens to have the same (default) FIB on it, I think control flow
ends up in the "else" clause above.  And that always works.
Instead, is there a way to check if the addr is being added to an IF
whose sw_if_index is the same-as or different-from the sw_if_index
of the original addr in the FIB entry?  Could we return "all happy"
if they 

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 <jozef.glon...@pantheon.tech>
Date: Friday, 29 September 2017 at 04:09
To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Cc: "Neale Ranns (nranns)" <nra...@cisco.com>
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] vlan sub interfaces

[Neale Ranns (nranns)]

With my release manager hat on …
Do we consider support for VLAN tags on an AF packet interface a bug fix (to be 
back ported) or a new feature (available from 17.10 onwards)?

/neale

-Original Message-
From: "prabh...@techtrueup.com" <prabh...@techtrueup.com>
Date: Thursday, 28 September 2017 at 13:07
To: "Dave Barach (dbarach)" <dbar...@cisco.com>
Cc: "Neale Ranns (nranns)" <nra...@cisco.com>, "John Lo (loj)" 
<l...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, Akshaya 
Nadahalli <aksh...@rtbrick.com>
Subject: Re: [vpp-dev] vlan sub interfaces

yes i verified it on stable/1707 itself.

Regards,
Prabhjot

Quoting "Dave Barach (dbarach)" <dbar...@cisco.com>:

> See https://gerrit.fd.io/r/#/c/8590. The patch cherry-picked easily  
> to stable/1707.
>
> Assuming that the cherry-pick patch validates - and that it solves  
> your problem - it will be up to Neale [as the 17.07 release manager]  
> whether to merge it or not.
>
> Please let us know whether the cherry-pick patch works for you.
>
> Thanks… Dave
>
> From: vpp-dev-boun...@lists.fd.io  
> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Prabhjot Singh Sethi
> Sent: Thursday, September 28, 2017 3:27 PM
> To: Akshaya Nadahalli <aksh...@rtbrick.com>; Prabhjot Singh Sethi  
> <prabh...@techtrueup.com>; vpp-dev@lists.fd.io; John Lo (loj)  
> <l...@cisco.com>
> Subject: Re: [vpp-dev] vlan sub interfaces
>
> yes it works perfectly fine with this patch.
> i hope this will be pushed to 17.07 branch as well.
>
> Thanks for the help :)
>
> Regards,
> Prabhjot
>
> - Original Message -
> From:
> "Akshaya Nadahalli" <aksh...@rtbrick.com<mailto:aksh...@rtbrick.com>>
>
> To:
> "Prabhjot Singh Sethi"  
> <prabh...@techtrueup.com<mailto:prabh...@techtrueup.com>>,  
> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>, "John Lo"  
> <l...@cisco.com<mailto:l...@cisco.com>>
> Cc:
>
> Sent:
> Thu, 28 Sep 2017 19:18:50 +0530
> Subject:
> Re: [vpp-dev] vlan sub interfaces
>
>
> Hi Prabhjot,
>
>
>
> Can you pls try with below patch and see if it helps:
>
> https://gerrit.fd.io/r/#/c/8435/
>
>
>
> Regards,
>
> Akshaya N
>
> On Thursday 28 September 2017 03:45 PM, Prabhjot Singh Sethi wrote:
> trying again with more appropriate subject
>
> Can some one please help if i am missing any thing over here ?
>
> As mentioned earlier, i have interface host-eth10 and sub interface  
> host-eth10.10 (create sub host-eth10 10)
> host-eth10 is associated to bridge domain 2 and sub interface is  
> associated to bridge domain 3
> when VPP receives tagged packet with vlan 10 it still associates it  
> to bd 2 and not bd 3
>
> Note: if i don't associate any bd with base interface it just drops  
> the packet with some error.
>
> Regards,
> Prabhjot
>
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
> --
> Regards,
> Akshaya N




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

Re: [vpp-dev] Static Route Data API Data Structures

[Neale Ranns (nranns)]

Hi Jon,

Some answers inline.

Thanks,
neale

-Original Message-
From: Jon Loeliger <j...@netgate.com>
Date: Thursday, 21 September 2017 at 16:42
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Static Route Data API Data Structures

On Tue, Aug 29, 2017 at 9:37 AM, Neale Ranns (nranns) <nra...@cisco.com> 
wrote:
>
> Hi Jon,
>
> The new API does not function correctly in master at this time. If you 
want to ride on the bleeding edge with the new API, the code I intend to commit 
is (complete AFAICT) here:
>   https://gerrit.fd.io/r/#/c/7819/
>
> it’s not committed yet because I need to do an n-step dance with CSIT 
changes to make the verify jobs pass. This will take a few weeks (because 
vacations).
>
> Regards,
> neale


Hi Neale,

Hope your vacation went well!

Glad to see you are back at The Salt Mines, though!  Any chance for
a brief update on the progress of this whole Route Table re-work effort?

It’s committed and ready to go. 
I’m still working through some updates to CSIT to behave w.r.t. adding tables 
first before adding routes or binding interfaces. After that I will add the 
checks in VPP to enforce it.


Specifically, I have code poised to use the "add_del_table" API call, and
I *think* that I can do that now.  But can I remove the soon-to-be-obsolete
create_table_if_needed flag yet?

You can remove that flag. I mistakenly left the flag in the API, but it has no 
effect in VPP. Too late to remove it now we are in the API Freeze, I’ll do it 
in the next iteration.

Also, I read a comment about the need to ensure that an interface does
not have addresses on it when the IF is bound to a route table.  I get
the "why" behind that, but I'd like a small clarification:  Is that per-AF?
Or is that "across the board"?

Per-AF. One could bind an interface to a new IPv4 tale whilst it had IPv6 
address.

The reason I ask is the potentially somewhat disconnected special case
API call intf_add_del_address which contains a flag "del_all".  And it
does as advertised -- it removes all IPv4 and IPv6 addresses in one shot.

But if the route table addition is per-AF, it might make sense to have
the two calls coordinated a bit better.  That is:

- Modify intf_add_del_address to del_all per AF, or all AFs
- Modify intf_sw_interface_set_table to accept and bind one or both AFs

It is all in an effort to avoid repeatedly removing and re-adding the
addresses that might be present in either or both AFs on an interface.

See where I am headed there?  Am I way off base?

I agree that is inconsistent. I would propose the del_all case becomes AF 
specific. But I would also suggest this in an API change, albeit semantic not 
syntactic, and so we should wait for the next release.

Regards,
neale

Thanks,
jdl


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

Re: [vpp-dev] Problem in ARP reply

[Neale Ranns (nranns)]

Hi Andrew,

Can you describe your use case/requirements in more detail please. Addresses on 
the subnet the ARP request arrives on, the ARP proxy range configured and a 
packet trace indicating what you consider to be incorrect behaviour.

Thanks,
neale

From:  on behalf of Andrew Taylor 

Date: Sunday, 24 September 2017 at 00:13
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Problem in ARP reply

Hi,

In following code in /vnet/ethernet/arp.c

1058 if (!(FIB_ENTRY_FLAG_CONNECTED & dst_flags))
1059 {
1060   error0 = ETHERNET_ARP_ERROR_l3_dst_address_not_local;
1061   goto drop1;
1062 }

I think the flag should be FIB_ENTRY_FLAG_LOCAL. is it correct?

Because when I set ARP proxy, the reply is sent with local address!


Best Regards
Andrew Taylor




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

Re: [vpp-dev] VPP 1704 and router plugin

[Neale Ranns (nranns)]

Hi Bhanu,

Sorry, then I’m out of ideas. And I don’t have access to similar HW to try and 
reproduce and debug. A var args issue is still my best guess.

/neale

From: Bhanu Chander Gaddoju <bhanu.gadd...@nxp.com>
Date: Tuesday, 19 September 2017 at 10:24
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "Dave Barach (dbarach)" 
<dbar...@cisco.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, "Ni, Hongjun" 
<hongjun...@intel.com>
Subject: RE: [vpp-dev] VPP 1704 and router plugin

Hi Neale,

  I am getting the same issue even after the change.

Regards,
Bhanu,
HSDC, NXP India.


From: Bhanu Chander Gaddoju
Sent: Tuesday, September 19, 2017 9:52 AM
To: Neale Ranns (nranns) <nra...@cisco.com>; Dave Barach (dbarach) 
<dbar...@cisco.com>; vpp-dev@lists.fd.io; Ni, Hongjun <hongjun...@intel.com>
Subject: RE: [vpp-dev] VPP 1704 and router plugin

Hi Neale,

   Please find the information below,

 ARCH  =   aarch64
 OS   =   Ubuntu 16.04
GCC =   Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4

 I am using VPP stable/1704 and external DPDK version 17.02.

 I will test as you suggested and would let you know.


Regards,
Bhanu,
HSDC, NXP India.


From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Tuesday, September 19, 2017 2:15 AM
To: Bhanu Chander Gaddoju 
<bhanu.gadd...@nxp.com<mailto:bhanu.gadd...@nxp.com>>; Dave Barach (dbarach) 
<dbar...@cisco.com<mailto:dbar...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; Ni, Hongjun 
<hongjun...@intel.com<mailto:hongjun...@intel.com>>
Subject: Re: [vpp-dev] VPP 1704 and router plugin

Hi Bhanu,

Can you give us some information on the CPU arch, OS and compiler version you 
are using please.

My best guess at the issue here is the problem of integer promotion through a 
variadic function. Perhaps you could test this idea by declaring;
 int fproto = FIB_PROTOCOL_IP4;
And then pass the variable ‘fproto’ and not FIB_PROTOCOL_IP4 to the call to 
vlib_cli_output (in frame 4).

Regards,
neale


From: <vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of Bhanu Chander Gaddoju 
<bhanu.gadd...@nxp.com<mailto:bhanu.gadd...@nxp.com>>
Date: Monday, 18 September 2017 at 00:58
To: "Dave Barach (dbarach)" <dbar...@cisco.com<mailto:dbar...@cisco.com>>, 
"vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>, "Ni, Hongjun" 
<hongjun...@intel.com<mailto:hongjun...@intel.com>>
Subject: Re: [vpp-dev] VPP 1704 and router plugin

Hi All,

   Could you please help me to resolve this issue.

Regards,
Bhanu.


From: Bhanu Chander Gaddoju
Sent: Tuesday, September 12, 2017 10:18 PM
To: 'Dave Barach (dbarach)' <dbar...@cisco.com<mailto:dbar...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; Ni, Hongjun 
<hongjun...@intel.com<mailto:hongjun...@intel.com>>
Subject: RE: VPP 1704 and router plugin

Hi Dave,

Thank you for your response.
fib_table->ft_desc is not NULL. Please find the details below,

(gdb) c
Continuing.

Breakpoint 1, format_fib_table_name (s=0x0, ap=...) at 
/root/vpp-1704/build-data/../src/vnet/fib/fib_table.c:1095
1095/root/vpp-1704/build-data/../src/vnet/fib/fib_table.c: No such file or 
directory.
(gdb) n
1096in /root/vpp-1704/build-data/../src/vnet/fib/fib_table.c
(gdb)
1097in /root/vpp-1704/build-data/../src/vnet/fib/fib_table.c
(gdb)
1096in /root/vpp-1704/build-data/../src/vnet/fib/fib_table.c
(gdb)
1097in /root/vpp-1704/build-data/../src/vnet/fib/fib_table.c
(gdb)
1100in /root/vpp-1704/build-data/../src/vnet/fib/fib_table.c
(gdb)
1102in /root/vpp-1704/build-data/../src/vnet/fib/fib_table.c
(gdb) p fib_table
$2 = (fib_table_t *) 0x3e1c9b80
(gdb) p fib_table->ft_desc
$3 = (u8 *) 0x3eb07a80 "ipv4-VRF:0"
(gdb) p *fib_table
$4 = {{v4 = {fib_entry_by_dst_address = {0x3d92f738, 0x0, 0x0, 0x0, 
0x3d92ead8, 0x0 , 0x3d92b9a0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x3d92f170}, mtrie = {
ply_pool = 0x3eb5b000, default_leaf = 1}, table_id = 0, index = 0, 
flow_hash_config = 31, fwd_classify_table_index = 4294967295, 
rev_classify_table_index = 4294967295}, v6 = {
  table_id = 1033041720, index = 65535, flow_hash_config = 0}, mpls = 
{mf_entries = 0x3d92f738, mf_lbs = {0, 0, 0, 0, 0, 0, 1033038552, 65535, 0 
, 1033025952, 65535,
0 , 1033040240, 65535, 1052094464, 65535, 1, 0, 0, 0, 
31, 4294967295, 4294967295, 0 }}}, ft_proto = 
FIB_PROTOCOL_IP4, ft_locks = 3,
  ft_table_id = 0, ft_index = 0, ft_flow_hash_config = 31, ft_src_route_counts 
= {2, 0, 5, 0, 3, 0 

[vpp-dev] 17.07.01 Released

[Neale Ranns (nranns)]

Dear All,

The 17.07.01 release is now available on a nexus server near you.

Best regards,
neale

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

Re: [vpp-dev] VPP 1704 and router plugin

[Neale Ranns (nranns)]

Hi Bhanu,

Can you give us some information on the CPU arch, OS and compiler version you 
are using please.

My best guess at the issue here is the problem of integer promotion through a 
variadic function. Perhaps you could test this idea by declaring;
 int fproto = FIB_PROTOCOL_IP4;
And then pass the variable ‘fproto’ and not FIB_PROTOCOL_IP4 to the call to 
vlib_cli_output (in frame 4).

Regards,
neale


From:  on behalf of Bhanu Chander Gaddoju 

Date: Monday, 18 September 2017 at 00:58
To: "Dave Barach (dbarach)" , "vpp-dev@lists.fd.io" 
, "Ni, Hongjun" 
Subject: Re: [vpp-dev] VPP 1704 and router plugin

Hi All,

   Could you please help me to resolve this issue.

Regards,
Bhanu.


From: Bhanu Chander Gaddoju
Sent: Tuesday, September 12, 2017 10:18 PM
To: 'Dave Barach (dbarach)' ; vpp-dev@lists.fd.io; Ni, 
Hongjun 
Subject: RE: VPP 1704 and router plugin

Hi Dave,

Thank you for your response.
fib_table->ft_desc is not NULL. Please find the details below,

(gdb) c
Continuing.

Breakpoint 1, format_fib_table_name (s=0x0, ap=...) at 
/root/vpp-1704/build-data/../src/vnet/fib/fib_table.c:1095
1095/root/vpp-1704/build-data/../src/vnet/fib/fib_table.c: No such file or 
directory.
(gdb) n
1096in /root/vpp-1704/build-data/../src/vnet/fib/fib_table.c
(gdb)
1097in /root/vpp-1704/build-data/../src/vnet/fib/fib_table.c
(gdb)
1096in /root/vpp-1704/build-data/../src/vnet/fib/fib_table.c
(gdb)
1097in /root/vpp-1704/build-data/../src/vnet/fib/fib_table.c
(gdb)
1100in /root/vpp-1704/build-data/../src/vnet/fib/fib_table.c
(gdb)
1102in /root/vpp-1704/build-data/../src/vnet/fib/fib_table.c
(gdb) p fib_table
$2 = (fib_table_t *) 0x3e1c9b80
(gdb) p fib_table->ft_desc
$3 = (u8 *) 0x3eb07a80 "ipv4-VRF:0"
(gdb) p *fib_table
$4 = {{v4 = {fib_entry_by_dst_address = {0x3d92f738, 0x0, 0x0, 0x0, 
0x3d92ead8, 0x0 , 0x3d92b9a0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x3d92f170}, mtrie = {
ply_pool = 0x3eb5b000, default_leaf = 1}, table_id = 0, index = 0, 
flow_hash_config = 31, fwd_classify_table_index = 4294967295, 
rev_classify_table_index = 4294967295}, v6 = {
  table_id = 1033041720, index = 65535, flow_hash_config = 0}, mpls = 
{mf_entries = 0x3d92f738, mf_lbs = {0, 0, 0, 0, 0, 0, 1033038552, 65535, 0 
, 1033025952, 65535,
0 , 1033040240, 65535, 1052094464, 65535, 1, 0, 0, 0, 
31, 4294967295, 4294967295, 0 }}}, ft_proto = 
FIB_PROTOCOL_IP4, ft_locks = 3,
  ft_table_id = 0, ft_index = 0, ft_flow_hash_config = 31, ft_src_route_counts 
= {2, 0, 5, 0, 3, 0 , 3}, ft_total_route_counts = 11, ft_desc 
= 0x3eb07a80 "ipv4-VRF:0"}



Regards,
Bhanu,
HSDC, NXP India.


From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
Sent: Tuesday, September 12, 2017 10:04 PM
To: Bhanu Chander Gaddoju 
>; 
vpp-dev@lists.fd.io; Ni, Hongjun 
>
Subject: RE: VPP 1704 and router plugin

Set a breakpoint in format_fib_table_name, and see if e.g. fib_table->ft_desc 
is NULL.

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Bhanu Chander Gaddoju
Sent: Tuesday, September 12, 2017 11:45 AM
To: vpp-dev@lists.fd.io; Ni, Hongjun 
>
Subject: [vpp-dev] VPP 1704 and router plugin

Hi All,

  We are building router plugin with VPP 1704 branch. We used VPP stable/1704 
branch and vppsb source code after (https://gerrit.fd.io/r/#/c/5881/ ) check in.

  Router plugin is loaded properly. We are able to see the router plugin when 
“vppctl  show plugin” command is issued.
  But, VPP daemon is getting crashed when we issue “vppctl show ip fib”. Crash 
dump and the VPP configuration is given below.
  Please help me in resolving this issue.

Crash Dump:
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x96b00034 in do_percent (va=, fmt=, 
_s=) at 
/root/vpp-1704/build-data/../src/vppinfra/format.c:372
#2  va_format (s=0x57a9dfe8 "ipv4-VRF:0, fib_index 0, flow hash: ", 
s@entry=0x0, fmt=fmt@entry=0x96e72ca8 "%U, fib_index %d, flow hash: %U", 
va=0x568fd988, va@entry=0x568fd9a8)
at /root/vpp-1704/build-data/../src/vppinfra/format.c:403
#3  0x96ed3cb4 in vlib_cli_output (vm=vm@entry=0x96f28ed0 
, fmt=fmt@entry=0x96e72ca8 "%U, fib_index %d, flow hash: 
%U")
at 

Re: [vpp-dev] JVPP API for adding MPLS local label

[Neale Ranns (nranns)]

CLI: sh mpls fib
API: mpls_fib_dump

/neale

From: Jozef Glončák <jozef.glon...@pantheon.tech>
Date: Tuesday, 12 September 2017 at 11:16
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "vpp-dev@lists.fd.io" 
<vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] JVPP API for adding MPLS local label


Thank you for response.



And is there any >>show<< command in VPP through which I can see that  local 
label was configured?



Jozef Glončák

Pantheon Technologies, s. r. o.

____
From: Neale Ranns (nranns) <nra...@cisco.com>
Sent: Monday, September 11, 2017 19:21
To: Jozef Glončák; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] JVPP API for adding MPLS local label


Hi Jozef,



It’s mpls_route_add_del



Regards,

neale



From: <vpp-dev-boun...@lists.fd.io> on behalf of Jozef Glončák 
<jozef.glon...@pantheon.tech>
Date: Monday, 11 September 2017 at 13:48
To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: [vpp-dev] JVPP API for adding MPLS local label



Hello developers,



I would like substitude this VPP CLI command

mpls local-label add eos 101 ip4-lookup-in-table 1

with JVPP API call, but I am not able to find equivalent.



Is it possible?



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] JVPP API for adding MPLS local label

[Neale Ranns (nranns)]

Hi Jozef,

It’s mpls_route_add_del

Regards,
neale

From:  on behalf of Jozef Glončák 

Date: Monday, 11 September 2017 at 13:48
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] JVPP API for adding MPLS local label


Hello developers,



I would like substitude this VPP CLI command

mpls local-label add eos 101 ip4-lookup-in-table 1
with JVPP API call, but I am not able to find equivalent.



Is it possible?



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] u32 vs uint32_t

[Neale Ranns (nranns)]

+1. I’ll patch the uses of uin32_t.

/neale

From:  on behalf of "Dave Barach (dbarach)" 

Date: Monday, 11 September 2017 at 18:59
To: Dave Wallace , Florin Coras , 
"Luke, Chris" 
Cc: vpp-dev 
Subject: Re: [vpp-dev] u32 vs uint32_t

+1, let’s stick with u32... Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Dave Wallace
Sent: Monday, September 11, 2017 12:36 PM
To: Florin Coras ; Luke, Chris 
Cc: vpp-dev 
Subject: Re: [vpp-dev] u32 vs uint32_t

+1
On 09/11/2017 11:27 AM, Florin Coras wrote:
Hi Chris,

Personally, I’d like to enforce the use of u32. Is it an option to just replace 
all occurrences of uint32_t in ip.h/mpls.h?

Thanks,
Florin

On Sep 11, 2017, at 7:55 AM, Luke, Chris 
> wrote:

For discussion: VPP has traditionally used its own fixed-width types, such as 
u32 and u64 and only uses standard types when referring to the external world 
(eg, to talk to libc, etc). Recently I’ve noticed the C99 variant, uint32_t 
creeping in more and into VPP internal matters. As a matter of style and 
consistency, which should we as a project be using?

Reason I ask: The recent MPLS patch (https://gerrit.fd.io/r/#/c/8371) uses both 
styles in .h files but doesn’t have stdint.h included in any path leading to 
those .h’s; Coverity appears to be fussy about this – it checks that all types 
used in a .h are defined in the scope of that .h. Upshot is that Coverity is 
balking at this and only 54% of the project now compiles under Coverity

To resolve the issue with Coverity, I am torn with adding “#include ” 
to ip.h/mpls.h to fix it where it happens, or just accept that humans are 
inconsistent and add it to vppinfra/types.h. Thoughts?

Chris.

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






___

vpp-dev mailing list

vpp-dev@lists.fd.io

https://lists.fd.io/mailman/listinfo/vpp-dev

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

Re: [vpp-dev] Static Route Data API Data Structures

[Neale Ranns (nranns)]

-Original Message-
From: Jon Loeliger <j...@netgate.com>
Date: Tuesday, 29 August 2017 at 21:23
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Static Route Data API Data Structures

>> As with all things VPP the allocation of the data-structure that 
represents
>> the LPM-DB comes from a memory pool. This data-structure thus has an
>> associated pool index – this is the FIB index. So, there is a one to one
>> mapping between the externally visible and client assigned ‘table ID’ and
>> the internal use only ‘FIB index’. Both are a u32, neither are strictly 
typed…
>
> Ah, I see.  Mapping in one direction is pool index, and a hash table
> in the other direction?
>
> As some APIs appear to want the FIB index, is there an API to do
> the FIB Id lookup for a Table Id?  (I'd posit that either needs to be one,
> or the APIs that accept a FIB Id need to be converted to Table Id.)
> Or, are all those references to a FIB Id really *also* supposed to
> be a Table Id?
>
> (I'm not seeing this line up with the API call ip_fib_dump yet.  Does it?
> If it does, and I see that it has route details in the fib_path, the 
table id
> is lost.  So no client-side FIB-to-TableId mapping can be established.)

Neale,

My double bad.  I see (and understand!) this now:

/** \brief IP FIB table response
@param table_id - IP fib table id
@address_length - mask length
@address - ip4 prefix
@param count - the number of fib_paths in path
@param path  - array of of fib_path structures
*/
manual_endian manual_print define ip_fib_details
{
  u32 context;
  u32 table_id;
  u8  address_length;
  u8  address[4];
  u32 count;
  vl_api_fib_path_t path[count];
};

That table_id *is* the dump coming back with the mapping from
FIB index to Table Id, right?

That should be the client’s assigned table-ID (not VPP’s FIB index). There 
should be a table-Id in the vl_api_fib_path_t too, which is relevant for 
recursive paths (it would be the next_hop_table_id when the route was added)

S,   Will FIB index allocation always be dense?  If it is
coming from a pool allocation, it should be, right?  So FIB
indices are going to be reused after they are free'd up, right?

Yes, yes and yes,

And this dump/details response will be in dense-index order, right?

One would reasonably expect so. For v6 it would appear to be the case, but, 
reading code in:
  vl_api_ip_fib_dump_t_handler()
fib_entry_cmp_for_sort()
  fib_entry_cmp()
it does not compare the route’s FIB-index. So I expect the details to come 
prefix sorted.
We might want to change that loop code in the v4 dump handler to do one table 
at a time, like v6 does.

/neale

jdl


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

Re: [vpp-dev] Static Route Data API Data Structures

[Neale Ranns (nranns)]

Hi Jon,

Some answers inline.

Regards,
neale

-Original Message-
From: Jon Loeliger <j...@netgate.com>
Date: Tuesday, 29 August 2017 at 20:40
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Static Route Data API Data Structures

On Tue, Aug 29, 2017 at 4:21 AM, Neale Ranns (nranns) <nra...@cisco.com> 
wrote:
> Hi Jon,
>

Neale,

> By ‘IP’ in this context we mean IPv4 and IPv6 and unicast and multicast
> (known as sub-address families or SAFIs). To provide this separation we
> therefore need 4 ‘tables’ per-VRF, one for each SAFI.

You say 4 here, but really we implement 2, one for IPv4 and one for IPv6.
So, an interface can be bound to multiple tables.  But is it limited to
one IPv4 and one IPv6 table?

Yes.
It was my choice to keep the unicast and multicast table-id the same within a 
given VRF. I thought that to be the simpler approach. It saves the interface 
being bound twice..

> A ‘table’ in this context is the well known longest-prefix matching DB.
> Tables are known by a unique per-AFI ID (note per-AFI not per-SAFI,
> so IPv4 unicast and multicast share the same table-id).

A table doesn't know its Address Family, except by the inspection of
the types of routes within it, right? (But both uni- and multi-cast routes
are possible in just one table, right?)

as you say, when you create a table you specify the AFI

Any checking done to prevent inter-family mixing in one table?

If you then add a route of the wrong AFI to that table one of two things will 
happen;
1) The route will be added to the table for that AFI that happens to have that 
same ID
2) You’ll get a no-such-table error

Or is that up to convention and enforcement by the API user?

GIGO

> It is the client’s responsibility to associate unique table IDs to tables
> within all of its VRFs.

Ah, there.  Only the external client (management agent) maintains
any notion of actual Virtual Routers.  To that end, multiple routing
tables are supplied for client use as it sees fit.

> The client is free to choose the table-ID from the full u32 range.
> So, bottom line, in the context of IP forwarding[,] a table (and its
> associated ID) refer to an instance of a LPM DB.

Right.  But prefix management is left up to something else (routing 
protocol).

Yes.

> Despite code comments and variable naming, VPP does not maintain
> the concept of a VRF, i.e. it does not maintain a grouping of ‘tables’.

This is an important observation.

> At the client interface VPP deals only with table IDs – i.e. an 
identifier that
> the client provided for a given LPM DB. All APIs that claim to accept a
> VRF index should be renamed to accept an IP table ID.

Would you (collectively) be receptive of patches to that end?

I (individually) would be ☺

And is "table id" the name?  Not anything more descriptive,
such as "Route Table Id"?

IMO if the context is clear that the API is related to IP, then table-id is 
descriptive. But, otherwise, or even if you think the context is clear, I’d be 
happy with ip_table_id.

> As with all things VPP the allocation of the data-structure that 
represents
> the LPM-DB comes from a memory pool. This data-structure thus has an
> associated pool index – this is the FIB index. So, there is a one to one
> mapping between the externally visible and client assigned ‘table ID’ and
> the internal use only ‘FIB index’. Both are a u32, neither are strictly 
typed…

Ah, I see.  Mapping in one direction is pool index, and a hash table
in the other direction?

Yes.

As some APIs appear to want the FIB index, is there an API to do
the FIB Id lookup for a Table Id?  (I'd posit that either needs to be one,
or the APIs that accept a FIB Id need to be converted to Table Id.)
Or, are all those references to a FIB Id really *also* supposed to
be a Table Id?

I’d hope they are really after a table-ID, given that there is no API for the 
conversion and know way I can think of that the client would learn a FIB-index.

(I'm not seeing this line up with the API call ip_fib_dump yet.  Does it?
If it does, and I see that it has route details in the fib_path, the table 
id
is lost.  So no client-side FIB-to-TableId mapping can be established.)

ip_fib_dump could probably use some TLC…

> With regards to the creation of tables, I’m currently working on the API
> you discovered – ip_table_add_del. With this API the client instructs VPP
> to add/delete a ‘table ID’ (as discussed above).

OK, good.

> The VPP FIB has the concept of ownership or ‘sourcing’

Re: [vpp-dev] Static Route Data API Data Structures

[Neale Ranns (nranns)]

Hi Jon,

The new API does not function correctly in master at this time. If you want to 
ride on the bleeding edge with the new API, the code I intend to commit is 
(complete AFAICT) here:
  https://gerrit.fd.io/r/#/c/7819/

it’s not committed yet because I need to do an n-step dance with CSIT changes 
to make the verify jobs pass. This will take a few weeks (because vacations).

Regards,
neale

-Original Message-
From: Jon Loeliger <j...@netgate.com>
Date: Tuesday, 29 August 2017 at 14:49
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Static Route Data API Data Structures

On Tue, Aug 29, 2017 at 4:21 AM, Neale Ranns (nranns) <nra...@cisco.com> 
wrote:
> Hi Jon,
>
> (apologies for repeating some of what you already know, but from the top…)
>
> A VRF is virtualisation of a router’s *IP* routing and forwarding. VRFs 
are typically identified by a name (and again typically named to refer to the 
VPN customer they represent). IP packets in VRF RED must be separate from IP 
packets in VRF BLUE. By ‘IP’ in this context we mean IPv4 and IPv6 and unicast 
and multicast (known as sub-address families or SAFIs). To provide this 
separation we therefore need 4 ‘tables’ per-VRF, one for each SAFI. A ‘table’ 
in this context is the well known longest-prefix matching DB. Tables are known 
by a unique per-AFI ID (note per-AFI not per-SAFI, so IPv4 unicast and 
multicast share the same table-id). It is the client’s responsibility to 
associate unique table IDs to tables within all of its VRFs. The client is free 
to choose the table-ID from the full u32 range. So, bottom line, in the context 
of IP forwarding a table (and its associated ID) refer to an instance of a LPM 
DB.
>
> Despite code comments and variable naming, VPP does not maintain the 
concept of a VRF, i.e. it does not maintain a grouping of ‘tables’. At the 
client interface VPP deals only with table IDs – i.e. an identifier that the 
client provided for a given LPM DB. All APIs that claim to accept a VRF index 
should be renamed to accept an IP table ID.
> As with all things VPP the allocation of the data-structure that 
represents the LPM-DB comes from a memory pool. This data-structure thus has an 
associated pool index – this is the FIB index. So, there is a one to one 
mapping between the externally visible and client assigned ‘table ID’ and the 
internal use only ‘FIB index’. Both are a u32, neither are strictly typed…
>
> With regards to the creation of tables, I’m currently working on the API 
you discovered – ip_table_add_del. With this API the client instructs VPP to 
add/delete a ‘table ID’ (as discussed above). The VPP FIB has the concept of 
ownership or ‘sourcing’ of its resources. Sources can be external (i.e. the CLI 
or the API) or internal (e.g. LISP and DHCP). FIB resources are only completely 
free’d was there are no more sources that are referencing it.
> My intention with the table add/delete API is that the client can add the 
table then insert routes and bind interfaces. If the client then deletes the 
table its routes will be purged. The table will then be deleted iff it held the 
last reference. With the introduction of this API VPP will insist that it has 
been called to create the table before any routes or interfaces refer to it.
> The current behaviour is that tables can be created either by setting an 
interface into that table, or by setting the ‘create_vrf_if_needed’ flag in a 
route add. There is no means to delete it, hence my new API work.
>
> Hth,
> neale

Neale,

That helps tremendously!

I am poised to add a bunch of route-related API calls to our project.
Are the "new" IP Route APIs in place at this time?  Or shall I wait a bit
and watch for a bit still?

Thank you!

jdl


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

Re: [vpp-dev] Static Route Data API Data Structures

[Neale Ranns (nranns)]

Hi Jon,

(apologies for repeating some of what you already know, but from the top…)

A VRF is virtualisation of a router’s *IP* routing and forwarding. VRFs are 
typically identified by a name (and again typically named to refer to the VPN 
customer they represent). IP packets in VRF RED must be separate from IP 
packets in VRF BLUE. By ‘IP’ in this context we mean IPv4 and IPv6 and unicast 
and multicast (known as sub-address families or SAFIs). To provide this 
separation we therefore need 4 ‘tables’ per-VRF, one for each SAFI. A ‘table’ 
in this context is the well known longest-prefix matching DB. Tables are known 
by a unique per-AFI ID (note per-AFI not per-SAFI, so IPv4 unicast and 
multicast share the same table-id). It is the client’s responsibility to 
associate unique table IDs to tables within all of its VRFs. The client is free 
to choose the table-ID from the full u32 range. So, bottom line, in the context 
of IP forwarding a table (and its associated ID) refer to an instance of a LPM 
DB.

Despite code comments and variable naming, VPP does not maintain the concept of 
a VRF, i.e. it does not maintain a grouping of ‘tables’. At the client 
interface VPP deals only with table IDs – i.e. an identifier that the client 
provided for a given LPM DB. All APIs that claim to accept a VRF index should 
be renamed to accept an IP table ID.
As with all things VPP the allocation of the data-structure that represents the 
LPM-DB comes from a memory pool. This data-structure thus has an associated 
pool index – this is the FIB index. So, there is a one to one mapping between 
the externally visible and client assigned ‘table ID’ and the internal use only 
‘FIB index’. Both are a u32, neither are strictly typed…

With regards to the creation of tables, I’m currently working on the API you 
discovered – ip_table_add_del. With this API the client instructs VPP to 
add/delete a ‘table ID’ (as discussed above). The VPP FIB has the concept of 
ownership or ‘sourcing’ of its resources. Sources can be external (i.e. the CLI 
or the API) or internal (e.g. LISP and DHCP). FIB resources are only completely 
free’d was there are no more sources that are referencing it.
My intention with the table add/delete API is that the client can add the table 
then insert routes and bind interfaces. If the client then deletes the table 
its routes will be purged. The table will then be deleted iff it held the last 
reference. With the introduction of this API VPP will insist that it has been 
called to create the table before any routes or interfaces refer to it.
The current behaviour is that tables can be created either by setting an 
interface into that table, or by setting the ‘create_vrf_if_needed’ flag in a 
route add. There is no means to delete it, hence my new API work.

Hth,
neale


-Original Message-
From:  on behalf of Jon Loeliger 
Date: Monday, 28 August 2017 at 01:36
To: vpp-dev 
Subject: [vpp-dev] Static Route Data API Data Structures

VPP-ites,

I am delving into the world of static routes.  I am clearly missing
some basic information and would like some help understanding
how static routes work.

For starters, I'm a little unclear on what exactly these items are,
or what they represent or hold, and their relationship to each other:

- VRF index / VRF id
- Table id
- FIB index  / FIB id

The only place I can find that even defines "VRF" is on this wiki page:

https://wiki.fd.io/view/VPP/What_is_VPP%3F

(Yeah, the final %3F is needed.)

And even that is in passing:

Some of the functionality that a routing application can create 
includes:

   o Virtual Routing and Forwarding (VRF) tables (in the thousands)


How is a VRF created/deleted/managed?  I don't see an obvious API call
that looks like it would create/delete one:

$ git grep -i vrf | grep add_del
src/plugins/nat/nat64.c:nat64_add_del_pool_addr (ip4_address_t * addr,
u32 vrf_id, u8 is_add)
src/plugins/nat/nat64.c:nat64_add_del_prefix (ip6_address_t * prefix,
u8 plen, u32 vrf_id, u8 is_add)
src/plugins/nat/nat64.h:int nat64_add_del_pool_addr (ip4_address_t *
addr, u32 vrf_id, u8 is_add);
src/plugins/nat/nat64.h:int nat64_add_del_prefix (ip6_address_t *
prefix, u8 plen, u32 vrf_id,
src/plugins/nat/nat64_cli.c:  rv = nat64_add_del_pool_addr
(_addr, vrf_id, is_add);
src/plugins/nat/nat64_cli.c:  rv = nat64_add_del_prefix (, (u8)
plen, vrf_id, is_add);
src/plugins/nat/nat_api.c:  if ((rv = nat64_add_del_pool_addr
(_addr, vrf_id, mp->is_add)))
src/plugins/nat/nat_api.c:  s = format (0, "SCRIPT:
nat64_add_del_prefix %U/%u vrf_id %u %s\n",
src/vat/api_format.c:_(oam_add_del, "src  dst
 [vrf ] [del]")   \
src/vat/api_format.c:_(one_eid_table_add_del_map, "[del] vni  

Re: [vpp-dev] Packet loss on use of API & cmdline

[Neale Ranns (nranns)]

Hi Colin,

Your comments were not taken as criticism ☺ constructive comments are always 
greatly appreciated.

Apart from the non-MP safe APIs Florin mentioned, and the route add/del cases I 
covered, the consensus is certainly that packet loss should not occur during a 
‘typical’ update and we will do what we can to address it.
Could you give us* some specific examples of the operations you do where you 
see packet loss?

Thanks,
Neale

*I say us not me as I’m about to hit the beach for a couple of weeks.


From: Colin Tregenza Dancer <c...@metaswitch.com>
Date: Tuesday, 22 August 2017 at 14:24
To: "Neale Ranns (nranns)" <nra...@cisco.com>, Florin Coras 
<fcoras.li...@gmail.com>
Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] Packet loss on use of API & cmdline

Hi neale,

Thanks for the reply, and please don’t take my comments as a criticism of what 
I think is a great project.  I’m just trying to understand whether the packet 
loss I’m observing when I do thinks like add new tunnels, setup routes, etc, is 
generally viewed as acceptable, or whether it’s an area where there is an 
interest in changing.

Specifically I’m looking at a range of tunnel/gateway applications, and am 
finding that whilst static operation is great from a packet loss perspective, 
when I add/remove tunnels, routes, etc (something which in my application is to 
be expected on a regular basis) the existing flows undergo significant packet 
loss.  For comparison, with most hardware based router/gateway this doesn’t 
occur, and existing flows continue unaffected.

Cheers,

Colin.

From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: 22 August 2017 13:44
To: Colin Tregenza Dancer <c...@metaswitch.com>; Florin Coras 
<fcoras.li...@gmail.com>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Colin,

The instances of barrier syncs you have correctly identified, occur only in the 
exceptional cases of route addition/deletion and not in the typical case.

-  adj_last_lock_gone () is called when that adjacency is no longer 
required, i.e. we are removing the last route, or probably the ARP entry, for a 
neighbour we presumably no longer have
-  adj_nbr_update_rewrite_internal() is called when the adjacency 
transitions from incomplete (not associated MAC rewrite) to complete.
-  The fix for 892 occurs when a route is added that is the first to 
create a new edge/arc in the VLIB node graph. In the case of that JIRA ticket, 
it was the first recursive route. Edges are never removed, so this is a once 
per-reboot event.

But in the typical case of adding routes, e.g. a BGP/OSPF convergence event, 
the adjacencies are present and complete and the VLIB graph is already setup, 
so the routes will be added in a lock/barrier free manner.

Pre-building the VLIB graph of all possibilities is wasteful IMHO, and given 
the one-time only lock, an acceptable trade off.
Adjacencies are more complicated. The state of the adjacency, incomplete or 
complete, determines the VLIB node the packet should go to. So one needs to 
atomically change the state of the adjacency and the state of the routes that 
use it - hence the barrier. We could solve that with indirection, but it would 
be indirection in the data-path and that costs cycles. So, again, given the 
relatively rarity of such an adjacency state change, the trade-off was to 
barrier sync.

Hth,
neale


From: <vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of Colin Tregenza Dancer via vpp-dev 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Reply-To: Colin Tregenza Dancer 
<c...@metaswitch.com<mailto:c...@metaswitch.com>>
Date: Tuesday, 22 August 2017 at 12:25
To: Florin Coras <fcoras.li...@gmail.com<mailto:fcoras.li...@gmail.com>>
Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Florin,

Thanks for the quick, and very useful reply.

I’d been looking at the mp_safe flags, and had concluded that I’d need the 
calls I was interested in to be at least marked mp_safe.

However, I was thinking that wasn’t sufficient, as it appeared that some calls 
marked as mp_safe invoke barrier_sync lower down the call stacks.  For instance 
the internal functions adj_last_lock_gone(),  adj_nbr_update_rewrite_internal() 
and vlib_node_serialize() all seem to call vlib_worker_thread_barrier_sync(), 
and the fix for defect 892 
https://jira.fd.io/browse/VPP-892?gerritReviewStatus=All#gerrit-reviews-left-panel
 involves adding barrier calls in code related to the mp_safe ADD_DEL_ROUTE 
(which fits with packet loss I’d observed during testing of deleting routes).

I think the raw lossless packet processing which vpp has achieved on static 
config

Re: [vpp-dev] Packet loss on use of API & cmdline

[Neale Ranns (nranns)]

Hi Colin,

The instances of barrier syncs you have correctly identified, occur only in the 
exceptional cases of route addition/deletion and not in the typical case.


-  adj_last_lock_gone () is called when that adjacency is no longer 
required, i.e. we are removing the last route, or probably the ARP entry, for a 
neighbour we presumably no longer have

-  adj_nbr_update_rewrite_internal() is called when the adjacency 
transitions from incomplete (not associated MAC rewrite) to complete.

-  The fix for 892 occurs when a route is added that is the first to 
create a new edge/arc in the VLIB node graph. In the case of that JIRA ticket, 
it was the first recursive route. Edges are never removed, so this is a once 
per-reboot event.

But in the typical case of adding routes, e.g. a BGP/OSPF convergence event, 
the adjacencies are present and complete and the VLIB graph is already setup, 
so the routes will be added in a lock/barrier free manner.

Pre-building the VLIB graph of all possibilities is wasteful IMHO, and given 
the one-time only lock, an acceptable trade off.
Adjacencies are more complicated. The state of the adjacency, incomplete or 
complete, determines the VLIB node the packet should go to. So one needs to 
atomically change the state of the adjacency and the state of the routes that 
use it - hence the barrier. We could solve that with indirection, but it would 
be indirection in the data-path and that costs cycles. So, again, given the 
relatively rarity of such an adjacency state change, the trade-off was to 
barrier sync.

Hth,
neale


From:  on behalf of Colin Tregenza Dancer via 
vpp-dev 
Reply-To: Colin Tregenza Dancer 
Date: Tuesday, 22 August 2017 at 12:25
To: Florin Coras 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Florin,

Thanks for the quick, and very useful reply.

I’d been looking at the mp_safe flags, and had concluded that I’d need the 
calls I was interested in to be at least marked mp_safe.

However, I was thinking that wasn’t sufficient, as it appeared that some calls 
marked as mp_safe invoke barrier_sync lower down the call stacks.  For instance 
the internal functions adj_last_lock_gone(),  adj_nbr_update_rewrite_internal() 
and vlib_node_serialize() all seem to call vlib_worker_thread_barrier_sync(), 
and the fix for defect 892 
https://jira.fd.io/browse/VPP-892?gerritReviewStatus=All#gerrit-reviews-left-panel
 involves adding barrier calls in code related to the mp_safe ADD_DEL_ROUTE 
(which fits with packet loss I’d observed during testing of deleting routes).

I think the raw lossless packet processing which vpp has achieved on static 
configs is truly amazing, but I guess what I’m trying to understand is whether 
it is viewed as important to achieve similar behaviour when the system is being 
reconfigured.  Personally I think many of the potential uses of a software 
dataplane include the need to do limited impact dynamic reconfiguration, 
however, maybe the kind of applications I have in mind are in a minority?

More than anything,  given the number of areas which would likely be touched by 
the required changes, I wanted to understand if there is a consensus that such 
change was even needed?

Thanks in advance for any insight you (or others) can offer.

Cheers,

Colin.



From: Florin Coras [mailto:fcoras.li...@gmail.com]
Sent: 22 August 2017 09:40
To: Colin Tregenza Dancer 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Packet loss on use of API & cmdline

Hi Colin,

Your assumption was right. Most often than not, a binary API/CLI call results 
in a vlib_worker_thread_barrier_sync because most handlers and cli are not mp 
safe. As a consequence, vpp may experience packet loss.

One way around this issue, for binary APIs, is to make sure the handler you’re 
interested in is thread safe and then mark it is_mp_safe in api_main. See, for 
instance, VL_API_IP_ADD_DEL_ROUTE.

Hope this helps,
Florin

On Aug 22, 2017, at 1:11 AM, Colin Tregenza Dancer via vpp-dev 
> wrote:

I might have just missed it, but looking through the ongoing regression tests I 
can’t see anything that explicitly tests for packet loss during CLI/API 
commands, so I’m wondering whether minimization of packet loss during 
configuration is viewed as a goal for vpp?

Many/most of the real world applications I’ve been exploring require the 
ability to reconfigure live systems without impacting the existing flows 
related to stable elements (route updates, tunnel add/remove, VM 
addition/removal), and it would be great to understand how this fit with vpp 
use cases.

Thanks again,

Colin.

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Colin Tregenza Dancer via 
vpp-dev

Re: [vpp-dev] Set up MPLS via jvpp

[Neale Ranns (nranns)]

Hi Andrej,

Can you please show me exactly was data is passed across the API?

Thanks,
Neale


From: Andrej Mak <andrej@pantheon.tech>
Date: Monday, 21 August 2017 at 07:05
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "Marek Gradzki -X (mgradzki - 
PANTHEON TECHNOLOGIES at Cisco)" <mgrad...@cisco.com>, "vpp-dev@lists.fd.io" 
<vpp-dev@lists.fd.io>
Subject: RE: Set up MPLS via jvpp


Hi Neale,

I’ve tested it without Honeycomb, I’ve just created simple jvpp app with 
IpAddDelRoute request as stated bellow.

Here is the entry created via jvpp:

vpp# sh ip fib index 2 10.10.2.3/32 detail
ipv4-VRF:2, fib_index:2, flow hash:[src dst sport dport proto ] locks:1
10.10.2.3/32 fib:2 index:40 locks:2
  src:API  refs:1
index:42 locks:2 flags:shared, uPRF-list:44 len:1 itfs:[1, ]
  index:42 pl-index:42 MPLS weight=1 attached-nexthop:  oper-flags:resolved,
   10.10.1.2 host-veth11
  [@0]: arp-mpls: via 10.10.1.2 host-veth11
Extensions:
 path:-1 labels:2003
 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:44 buckets:1 uRPF:44 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.1.2 host-veth11
Delegates:
Children:

And here is the entry created via CLI:

vpp# sh ip fib index 1 10.10.2.3/32 detail
ipv4-VRF:1, fib_index:1, flow hash:[src dst sport dport proto ] locks:2
10.10.2.3/32 fib:1 index:24 locks:4
  src:CLI  refs:1
index:21 locks:4 flags:shared, uPRF-list:19 len:1 itfs:[1, ]
  index:21 pl-index:21 ipv4 weight=1 attached-nexthop:  oper-flags:resolved,
   10.10.1.2 host-veth11
  [@0]: arp-ipv4: via 10.10.1.2 host-veth11
Extensions:
 path:21 labels:1003
  src:recursive-resolution cover:-1 refs:1

forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:27 buckets:1 uRPF:19 to:[0:0]]
[0] [@10]: mpls-label:[1]:[1003:255:0:eos]
[@1]: arp-mpls: via 10.10.1.2 host-veth11
Delegates:
  mpls-neos-chain
  [@0]: dpo-load-balance: [proto:mpls index:32 buckets:1 uRPF:19 to:[0:0]]
[0] [@7]: mpls-label:[2]:[1003:255:0:neos]
[@1]: arp-mpls: via 10.10.1.2 host-veth11
Children:{path:31}

Thanks
Andrej
From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Friday, August 18, 2017 11:13 AM
To: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) 
<mgrad...@cisco.com>; Andrej Mak <andrej@pantheon.tech>; vpp-dev@lists.fd.io
Subject: Re: Set up MPLS via jvpp


Hi Marek,

I don’t see anything wrong with the construction of the request.

Can you please show me the HC logs of the message sent and also
  sh ip fib index 2 10.10.2.3/32 detail

this API is used a lot in the unit-tests so I have some confidence that works 
under normal circumstances

regards,
neale

From: "Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)" 
<mgrad...@cisco.com<mailto:mgrad...@cisco.com>>
Date: Friday, 18 August 2017 at 06:00
To: Andrej Mak <andrej@pantheon.tech<mailto:andrej@pantheon.tech>>, 
"vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Cc: "Neale Ranns (nranns)" <nra...@cisco.com<mailto:nra...@cisco.com>>
Subject: RE: Set up MPLS via jvpp

Hi,

So I was wrong. I haven’t noticed next_hop_n_out_labels is u8…
Neal: any idea why labels are not added?

Regards,
Marek

From: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)
Sent: 17 sierpnia 2017 12:17
To: 'Andrej Mak' <andrej@pantheon.tech<mailto:andrej@pantheon.tech>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: Neale Ranns (nranns) <nra...@cisco.com<mailto:nra...@cisco.com>>
Subject: RE: Set up MPLS via jvpp

Hi,

I think it is a bug in the C handler of the ip_add_del_route message.
Byte order for next_hop_n_out_labels is not flipped.

Please check if this fixes the issue:
https://gerrit.fd.io/r/#/c/8080/


Regards,
Marek


From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Andrej Mak
Sent: 17 sierpnia 2017 11:03
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] Set up MPLS via jvpp

Hi all,

I would like to set mpls via java api, but I have some problems with it.
I want to do java calls equal to this

ip route add 10.10.2.3/32 table 1 via 10.10.1.2 host-veth out-label 1003

which creates this entry in show ip fib index 1

10.10.2.3/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:27 buckets:1 uRPF:19 to:[0:0]]
[0] [@10]: mpls-label:[1]:[1003:255:0:eos]
[@1]: arp-mpls: via 10.10.1.2 host-veth11

so I create DTO, which sets fields matching parameters in CLI command:

IpAddDelRoute addRoute = new IpAddDelRoute();
addRoute.isAdd = 1;
addRoute.tableId = 2;
final Ipv4Prefix prefix = new Ipv4Prefix((„10.10.2.3/32“);
addR

Re: [vpp-dev] Set up MPLS via jvpp

[Neale Ranns (nranns)]

Hi Marek,

I don’t see anything wrong with the construction of the request.

Can you please show me the HC logs of the message sent and also
  sh ip fib index 2 10.10.2.3/32 detail

this API is used a lot in the unit-tests so I have some confidence that works 
under normal circumstances

regards,
neale

From: "Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)" 
<mgrad...@cisco.com>
Date: Friday, 18 August 2017 at 06:00
To: Andrej Mak <andrej@pantheon.tech>, "vpp-dev@lists.fd.io" 
<vpp-dev@lists.fd.io>
Cc: "Neale Ranns (nranns)" <nra...@cisco.com>
Subject: RE: Set up MPLS via jvpp

Hi,

So I was wrong. I haven’t noticed next_hop_n_out_labels is u8…
Neal: any idea why labels are not added?

Regards,
Marek

From: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)
Sent: 17 sierpnia 2017 12:17
To: 'Andrej Mak' <andrej....@pantheon.tech>; vpp-dev@lists.fd.io
Cc: Neale Ranns (nranns) <nra...@cisco.com>
Subject: RE: Set up MPLS via jvpp

Hi,

I think it is a bug in the C handler of the ip_add_del_route message.
Byte order for next_hop_n_out_labels is not flipped.

Please check if this fixes the issue:
https://gerrit.fd.io/r/#/c/8080/


Regards,
Marek


From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Andrej Mak
Sent: 17 sierpnia 2017 11:03
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] Set up MPLS via jvpp

Hi all,

I would like to set mpls via java api, but I have some problems with it.
I want to do java calls equal to this

ip route add 10.10.2.3/32 table 1 via 10.10.1.2 host-veth out-label 1003

which creates this entry in show ip fib index 1

10.10.2.3/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:27 buckets:1 uRPF:19 to:[0:0]]
[0] [@10]: mpls-label:[1]:[1003:255:0:eos]
[@1]: arp-mpls: via 10.10.1.2 host-veth11

so I create DTO, which sets fields matching parameters in CLI command:

IpAddDelRoute addRoute = new IpAddDelRoute();
addRoute.isAdd = 1;
addRoute.tableId = 2;
final Ipv4Prefix prefix = new Ipv4Prefix((„10.10.2.3/32“);
addRoute.dstAddress = 
Ipv4Translator.INSTANCE.ipv4AddressPrefixToArray(prefix);
addRoute.dstAddressLength = 
Ipv4Translator.INSTANCE.extractPrefix(prefix);
addRoute.nextHopAddress = 
Ipv4Translator.INSTANCE.ipv4AddressNoZoneToArray(„10.10.1.2“);
addRoute.nextHopSwIfIndex = 1;
int[] labels = new int[1];
labels[0] = 1003;
addRoute.nextHopNOutLabels = (byte) labels.length;
addRoute.nextHopOutLabelStack = labels;
api.ipAddDelRoute(addRoute).toCompletableFuture().get()

but show ip fib index 2 shows different result
10.10.2.3/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:44 buckets:1 uRPF:44 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.1.2 host-veth11

Is it a bug, or am I doing something wrong?

Another question I’d like to ask is whether is it possible to create MPLS 
local-label via jvpp. I could’t find local label API in mpls.api file.

Thanks
Andrej

Andrej Mak
Software Developer

PANTHEON technologies s.r.o.
Janka Kráľa 9, 974 01 Banská Bystrica
Slovakia
Tel / +421 220 665 111

MAIL / andrej@pantheon.tech<mailto:andrej@pantheon.tech>
WEB / https://pantheon.tech


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

Re: [vpp-dev] VPP Packet Generator and pg0 IP address

[Neale Ranns (nranns)]

Hi Michael,

Yes you do have to give the pg interface an IP address before it will accept IP 
packets.
We use pg interfaces in the unit-tests so they have to act like real interfaces 
for us to be able to test all the features.

Regards,
Neale


From:  on behalf of Michael Borokhovich 

Date: Monday, 14 August 2017 at 23:03
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] VPP Packet Generator and pg0 IP address

Hi,

Is it true that in VPP 1707 we have to give IP to the pg0 interface?

In the previous VPP version (1609), the packet generator worked without IP 
address on pg0, but in 1707 it gives "ip4 adjacency drop" and no packets come 
out. Configuring pg0 with some fake IP worked.

Thanks,
Michael.


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

Re: [vpp-dev] MPLS labels question

[Neale Ranns (nranns)]

VPP does not have MPLS trace-route support. I’d suggest using the packet trace;
   trace add  50
   show trace

/neale

From: Алексей Болдырев <devel-net-ne-vleza...@yandex.ru>
Date: Monday, 14 August 2017 at 23:52
To: Michael Borokhovich <michael...@gmail.com>, "Neale Ranns (nranns)" 
<nra...@cisco.com>
Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] MPLS labels question

Скажите пожалуйста, умеет ли vpp отображать процесс в трассировке о надивании и 
снятии MPLS-меток?

Как например тут:
traceroute to kernel.org (198.145.29.83), 30 hops max, 60 byte packets
 1  10.247.1.1 (10.247.1.1)  0.095 ms  0.127 ms  0.122 ms
 2  100.64.0.1 (100.64.0.1)  0.765 ms  0.753 ms  0.893 ms
 3  192.168.192.193 (192.168.192.193)  5.333 ms  5.334 ms  5.329 ms
 4  192.168.192.1 (192.168.192.1)  4.476 ms * *
 5  kiev-r0.w-ix.net (193.106.112.4)  31.109 ms  28.508 ms  28.508 ms
 6  * * *
 7  10ge1-8.core1.vie1.he.net (184.105.222.25)  61.858 ms  61.844 ms  59.284 ms
 8  100ge13-1.core1.par2.he.net (184.105.65.5)  70.435 ms  70.443 ms  70.592 ms
 9  100ge14-1.core1.nyc4.he.net (184.105.81.77)  150.720 ms  150.975 ms  
151.391 ms
10  100ge14-1.core1.tor1.he.net (184.105.80.10) 

Re: [vpp-dev] MPLS labels question

[Neale Ranns (nranns)]

No, not quite. There’s a need to add ‘eos’ if you want the label entry to match 
against that label AND against the set EOS bit. An MPLS lookup is really a 21 
bit match; 20 bits of label value and 1 bit EOS.
It only makes sense to send EOS traffic to IP lookup. Sending non-EOS traffic 
to a IP lookup would not result in something good.

If label 222 has been dedicated to 10.100.2.0/24 (i.e. when we the receiver 
gets traffic with label 222, it must be for 10.100.2.0/24) then the command you 
are looking for is;
   mpls local-label 222 10.100.2.0/24
this does what the API refers to as a ‘bind’. It says, whatever IP does for 
10.100.2.0/24, MPLS should do for label 222. It will add the eos and non-eos 
entries appropriately.

/neale


From: Michael Borokhovich <michael...@gmail.com>
Date: Monday, 14 August 2017 at 18:20
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] MPLS labels question

I see.. so there is a need to add the "add eos" to the "mpls local-label" 
command if I want to send the packet to the IP lookup after popping a single 
(the only) label.

Thanks, Neale!

On Mon, Aug 14, 2017 at 1:01 PM, Neale Ranns (nranns) 
<nra...@cisco.com<mailto:nra...@cisco.com>> wrote:

Hi Michael,

‘add’ is the default.
It’s necessary to specify ‘eos’ because it I the end-of-stack entry you are 
adding and the default (i.e. without ‘eos’) is to add the non-end-of-stack 
entry.

Regards,
neale

From: <vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of Michael Borokhovich 
<michael...@gmail.com<mailto:michael...@gmail.com>>
Date: Monday, 14 August 2017 at 16:58
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 labels question

Hi,

I'm adding a label using the following command:

ip route add 10.100.2.0/24<http://10.100.2.0/24> table 1 via 10.100.4.12 
GigabitEthernet0/6/0 out-label 222

And on the receiving side poping it with:

set interface mpls GigabitEthernet0/6/0 enable
mpls local-label 222 ip4-lookup-in-table 1

However, this didn't work until I added "add eos" to the last command, i.e., 
the following worked:

mpls local-label add eos 222 ip4-lookup-in-table 1

Why is it necessary to specify "add eos" at the receiving side? Or maybe my 
configuration of the sender's side is wrong?

Thanks,
Michael.

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

Re: [vpp-dev] MPLS labels question

[Neale Ranns (nranns)]

On master branch the CLI has changed subtlety to allow one to specify multiple 
output-labels:
  ip route add 10.100.2.0/24 table 1 via 10.100.4.12 
GigabitEthernet0/6/0 out-labels 222 333

note the change from ‘out-label’ to ‘out-labels’. In older versions passing 
multiple out-labels is only possible via the API.

/neale


From:  on behalf of Алексей Болдырев 

Date: Monday, 14 August 2017 at 17:08
To: Michael Borokhovich , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] MPLS labels question

А как можно навесить несколько меток на маршрут?


14.08.2017, 18:58, "Michael Borokhovich" :
Hi,

I'm adding a label using the following command:

ip route add 10.100.2.0/24 table 1 via 10.100.4.12 
GigabitEthernet0/6/0 out-label 222

And on the receiving side poping it with:

set interface mpls GigabitEthernet0/6/0 enable
mpls local-label 222 ip4-lookup-in-table 1

However, this didn't work until I added "add eos" to the last command, i.e., 
the following worked:

mpls local-label add eos 222 ip4-lookup-in-table 1

Why is it necessary to specify "add eos" at the receiving side? Or maybe my 
configuration of the sender's side is wrong?

Thanks,
Michael.
,

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

Re: [vpp-dev] MPLS labels question

[Neale Ranns (nranns)]

Hi Michael,

‘add’ is the default.
It’s necessary to specify ‘eos’ because it I the end-of-stack entry you are 
adding and the default (i.e. without ‘eos’) is to add the non-end-of-stack 
entry.

Regards,
neale

From:  on behalf of Michael Borokhovich 

Date: Monday, 14 August 2017 at 16:58
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] MPLS labels question

Hi,

I'm adding a label using the following command:

ip route add 10.100.2.0/24 table 1 via 10.100.4.12 
GigabitEthernet0/6/0 out-label 222

And on the receiving side poping it with:

set interface mpls GigabitEthernet0/6/0 enable
mpls local-label 222 ip4-lookup-in-table 1

However, this didn't work until I added "add eos" to the last command, i.e., 
the following worked:

mpls local-label add eos 222 ip4-lookup-in-table 1

Why is it necessary to specify "add eos" at the receiving side? Or maybe my 
configuration of the sender's side is wrong?

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

Re: [vpp-dev] Spurious make test failure (container POC)

[Neale Ranns (nranns)]

Hi,

I think I’ve fixed this with;
  https://gerrit.fd.io/r/#/c/8007/
it was a genuine bug.

/neale

From:  on behalf of "Ed Kern (ejk)" 

Date: Thursday, 10 August 2017 at 17:59
To: "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" 

Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Spurious make test failure (container POC)

these are NOT with verify…

specifically with test-debug that I added as a separate run at someones 
request..(sorry can’t remember who at this moment)

Ed


On Aug 10, 2017, at 1:07 AM, Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES 
at Cisco) > wrote:

The 2 minute timeout is the result of my recent change. The framework
now forks and runs the test in a child process, and if the child process
fails to send a keep-alive (sent when a test case starts), then it's
killed. Otherwise there'd be no way to recover from stuck mutex or
deadlock..

Are you running the extended tests or the stock verify?

Quoting Ed Kern (ejk) (2017-08-10 00:08:19)

  klement,
  ok…ill think about how to do that without too much trouble in its current
  state..
  in the meantime…blowing out the cpu and memory a bit changed the error……

21:49:42 create 1k of p2p subifs
  OK
21:49:42 
==
21:51:52 21:53:13,610 Timeout while waiting for child test runner process (last 
test running was `drop rx packet not matching p2p subinterface' in 
`/tmp/vpp-unittest-P2PEthernetIPV6-GDHSDK')!
21:51:52 Killing possible remaining process IDs:  19954 19962 19964

21:45:05 PPPoE Test Case
21:45:05 ===21:48:13,778 Timeout while waiting 
for child test runner process (last test running was `drop rx packet not 
matching p2p subinterface' in `/tmp/vpp-unittest-P2PEthernetIPV6-I0REOQ')!
21:47:45 Killing possible remaining process IDs:  20017 20025 20027

20:48:46 PPPoE Test Case
20:48:46 ===20:51:34,082 Timeout while waiting 
for child test runner process (last test running was `drop rx packet not 
matching p2p subinterface' in `/tmp/vpp-unittest-P2PEthernetIPV6-tQ5sP0')!
20:51:05 Killing possible remaining process IDs:  19919 19927 19929

  anything new/different/exciting in here?
  Also the memory/cpu expansion (by roughly a third) these failures happen
  in the order of 2/3 minutes as opposed to a 90 leading to timeout failure.
  Since the verifies are still happily chugging along I ASSuME that this
  drop packet check isn’t happening in that suite?
  Ed

On Aug 9, 2017, at 1:04 PM, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco) <[1]ksek...@cisco.com> 
wrote:
Ed,

it'd help if you could collect log.txt from a failed run so we could
peek under the hood... please see my other email in this thread...

Thanks,
Klement

Quoting Ed Kern (ejk) (2017-08-09 20:48:46)

this is not you…or this patch…
the make test-debug has had a 90+% failure rate (read not 100%) for
  at
least the last 100 builds
(far back as my current logs go but will probably blow that out a
  bit now)
you hit the one that is seen most often… on that create 1k of p2p
  subifs
the other much less frequent is

  13:40:24 CGNAT TCP session close initiated from outside network
OK
  13:40:24 =Build timed
  out (after 120 minutes). Marking the build as failed.

so currently I’m allocating 1 MHz in cpu and 8G in memory for
  verify
and also for test-debug runs…
Im not obviously getting (as you can see) errors about it running
  out of
memory but I wonder if thats possibly whats happening..
its easy enough to blow my allocations out a bit and see if that
  makes a
difference..
If anyone has other ideas to try and happy to give them a shot..
appreciate the heads up
Ed

  On Aug 9, 2017, at 12:07 PM, Dave Barach (dbarach)
  <[1][2]dbar...@cisco.com> wrote:
  Please see [2][3]https://gerrit.fd.io/r/#/c/7927, and

  
[3][4]http://jenkins.ejkern.net:8080/job/vpp-test-debug-master-ubuntu1604/1056/console

  The patch in question is highly unlikely to cause this failure...


  14:37:11
  
==
  14:37:11 P2P Ethernet tests
  14:37:11
  
==
  14:37:11 delete/create p2p
  subif  OK
  14:37:11 create 100k of p2p
  subifs   

[vpp-dev] Verify jobs failing - opensuse

[Neale Ranns (nranns)]

Hi All,

The verify jobs are failing due to the new opensuse job, e.g. from:
  https://gerrit.fd.io/r/#/c/8001/
error is below.

Can we please fix ASAP or disable them.

Thanks,
Neale


 18:49:56 [vpp-verify-master-opensuse] $ /bin/bash 
/tmp/hudson7746568270930707597.sh
18:49:56 make[1]: Entering directory 
'/w/workspace/vpp-verify-master-opensuse/test'
18:49:56 make[1]: virtualenv: Command not found
18:49:56 Makefile:159: recipe for target 'checkstyle' failed
18:49:56 make[1]: *** [checkstyle] Error 127
18:49:56 make[1]: Leaving directory 
'/w/workspace/vpp-verify-master-opensuse/test'
18:49:56 Makefile:379: recipe for target 'test-checkstyle' failed
18:49:56 make: *** [test-checkstyle] Error 2
18:49:56 Build step 'Execute shell' marked build as failure


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

Re: [vpp-dev] ip6 route add bug

[Neale Ranns (nranns)]

Hi Pragash,

Yes that’s a bug.
Could you submit a patch for it – we need to flip the order the ‘add’ string is 
parsed from the options so that it comes after parsing the IPv6 address.

Thanks,
neale

From: Pragash Vijayaragavan <pxv3...@rit.edu>
Reply-To: "pxv3...@rit.edu" <pxv3...@rit.edu>
Date: Thursday, 10 August 2017 at 14:47
To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Cc: "Neale Ranns (nranns)" <nra...@cisco.com>, "John Marshall (jwm)" 
<j...@cisco.com>, Minseok Kwon <mxk...@rit.edu>
Subject: ip6 route add bug

Hi,

When i add the following ip6 route, which starts with "add", the "add" is 
ignored and the rest of the ip is added.

Is this a bug?

You can check the outputs below.

This is in 17.07-rc0.


vpp# ip route add add:9538:44f8::/45 via 9000::1

vpp# sh ip6 fib
ipv6-VRF:0, fib_index 0, flow hash:
::/0
  unicast-ip6-chain
  [@0]: dpo-load-balance: [index:5 buckets:1 uRPF:5 to:[0:0]]
[0] [@0]: dpo-drop ip6
9000::1/128
  unicast-ip6-chain
  [@0]: dpo-load-balance: [index:8 buckets:1 uRPF:5 to:[0:0]]
[0] [@0]: dpo-drop ip6
9538:44f8::/45
  unicast-ip6-chain
  [@0]: dpo-load-balance: [index:9 buckets:1 uRPF:7 to:[0:0]]
  load-balance-map: index:0 buckets:1
 index:0
   map:0
[0] [@6]: dpo-load-balance: [index:8 buckets:1 uRPF:5 to:[0:0]]
  [0] [@0]: dpo-drop ip6
fe80::/10
  unicast-ip6-chain
  [@0]: dpo-load-balance: [index:6 buckets:1 uRPF:6 to:[0:0]]
[0] [@2]: dpo-receive


Is this fixed in 17.10.



Thanks,

Pragash Vijayaragavan
Grad Student at Rochester Institute of Technology
email : pxv3...@rit.edu<mailto:pxv3...@rit.edu>
ph : 585 764 4662

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

Re: [vpp-dev] Configuring multiple VFRs

[Neale Ranns (nranns)]

Hi Michael,

Those configs will work with newer versions of VPP. Are you able to upgrade to 
17.07?

Thanks,
neale

From:  on behalf of Michael Borokhovich 

Date: Wednesday, 9 August 2017 at 18:50
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Configuring multiple VFRs

Hi,

We have 3 interfaces. First two belong to different VRFs and the third one is a 
global interface (GigabitEthernet0/6/0).
How we can configure VPP so that the packets received through any of the first 
two interfaces will be sent to the global interface (GigabitEthernet0/6/0).

The default GW is 10.100.4.11, and we tried adding it to the tables but nothing 
worked. Specifically, if we do
"vppctl ip route add 10.100.4.0/24 table 1 via 
GigabitEthernet0/6/0"
the packets are forwarded but without the Ethernet header.

Any help is appreciated. Our config is below.

Thanks,
Michael.

Interfaces config:

vppctl set interface ip table GigabitEthernet0/5/0 1
vppctl set int ip address GigabitEthernet0/5/0 
10.100.3.11/24
vppctl set int state GigabitEthernet0/5/0 up

vppctl set interface ip table GigabitEthernet0/4/0 2
vppctl set int ip address GigabitEthernet0/4/0 
10.100.1.11/24
vppctl set int state GigabitEthernet0/4/0 up

vppctl set int ip address GigabitEthernet0/6/0 
10.100.4.11/24
vppctl set int state GigabitEthernet0/6/0 up


FIB:

Table 0, fib_index 0, flow hash: src dst sport dport proto
 Destination Packets  Bytes Adjacency
10.100.4.0/24  0   0 
weight 1, index 3
  
10.100.4.11/24
10.100.4.11/32 0   0 
weight 1, index 4
  
10.100.4.11/24

Table 1, fib_index 1, flow hash: src dst sport dport proto
 Destination Packets  Bytes Adjacency
10.100.3.0/24  0   0 
weight 1, index 5
  
10.100.3.11/24
10.100.3.11/32 0   0 
weight 1, index 6
  
10.100.3.11/24

Table 2, fib_index 2, flow hash: src dst sport dport proto
 Destination Packets  Bytes Adjacency
10.100.1.0/24  0   0 
weight 1, index 7
  
10.100.1.11/24
10.100.1.11/32 0   0 
weight 1, index 8
  
10.100.1.11/24

IP addresses:
GigabitEthernet0/4/0 (up):
  10.100.1.11/24 table 2
GigabitEthernet0/5/0 (up):
  10.100.3.11/24 table 1
GigabitEthernet0/6/0 (up):
  10.100.4.11/24
local0 (dn):

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

Re: [vpp-dev] [csit-dev] API Change: Dedicated SW interface Event

[Neale Ranns (nranns)]

Hi Chris,

I don’t know the history. Convenience probably. In the absence of our attempt 
at auto-generating/auto-detecting event-notify pairs, the message re-use is 
understandable. I’m just trying to avoid the special cases in those generators 
(like-wise with the recent ACL dump addition).

I’ll give it till the end of the week, then press the button if there are no 
objections.

Thanks,
neale

-Original Message-
From: "Luke, Chris" <chris_l...@comcast.com>
Date: Wednesday, 9 August 2017 at 14:25
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "vpp-dev@lists.fd.io" 
<vpp-dev@lists.fd.io>, "csit-...@lists.fd.io" <csit-...@lists.fd.io>, 
"honeycomb-...@lists.fd.io" <honeycomb-...@lists.fd.io>
Subject: RE: [csit-dev] API Change: Dedicated SW interface Event

No specific objection, though I don't think I understand why it was done 
this way in the first place. Laziness, perhaps?

Chris.

> -Original Message-
> From: csit-dev-boun...@lists.fd.io [mailto:csit-dev-boun...@lists.fd.io] 
On
> Behalf Of Neale Ranns (nranns)
> Sent: Wednesday, August 9, 2017 8:51
> To: vpp-dev@lists.fd.io; csit-...@lists.fd.io; honeycomb-...@lists.fd.io
> Subject: Re: [csit-dev] API Change: Dedicated SW interface Event
> 
> 
> Hi All,
> 
> Any objections or support for this proposal?
> 
> Thanks,
    > neale
> 
> -Original Message-
> From: <csit-dev-boun...@lists.fd.io> on behalf of "Neale Ranns (nranns)"
> <nra...@cisco.com>
> Date: Monday, 7 August 2017 at 16:02
> To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, "csit-...@lists.fd.io" 
 d...@lists.fd.io>, "honeycomb-...@lists.fd.io"  d...@lists.fd.io>
> Subject: [csit-dev] API Change: Dedicated SW interface Event
> 
> 
> Hi All,
> 
> I would like to propose the addition of a dedicated SW interface event
> message type rather than overload the set flags request. The over-loading 
of
> types causes problems for the automatic API generation tools.
> 
> https://gerrit.fd.io/r/#/c/7925/
> 
> regards,
> neale
> 
> 
> ___
> csit-dev mailing list
> csit-...@lists.fd.io
> https://lists.fd.io/mailman/listinfo/csit-dev
> 
> 
> ___
> csit-dev mailing list
> csit-...@lists.fd.io
> https://lists.fd.io/mailman/listinfo/csit-dev



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

Re: [vpp-dev] [csit-dev] API Change: Dedicated SW interface Event

[Neale Ranns (nranns)]

Hi All,

Any objections or support for this proposal?

Thanks,
neale

-Original Message-
From: <csit-dev-boun...@lists.fd.io> on behalf of "Neale Ranns (nranns)" 
<nra...@cisco.com>
Date: Monday, 7 August 2017 at 16:02
To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, "csit-...@lists.fd.io" 
<csit-...@lists.fd.io>, "honeycomb-...@lists.fd.io" <honeycomb-...@lists.fd.io>
Subject: [csit-dev] API Change: Dedicated SW interface Event


Hi All,

I would like to propose the addition of a dedicated SW interface event 
message type rather than overload the set flags request. The over-loading of 
types causes problems for the automatic API generation tools.

https://gerrit.fd.io/r/#/c/7925/

regards,
neale


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


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

Re: [vpp-dev] vpp v17.07 ping assert

[Neale Ranns (nranns)]

Hi Steve,

No worries.

We use gerrit for our git interactions. In the gerrit link for that patch:
  https://gerrit.fd.io/r/#/c/7661/

you’ll see a button for cherry pick, select it and enter the branch 
stable/1707. That’s it ☺ When the CI jobs finish I can merge.

Thanks,
neale



From: Steve Heckman <steve.heck...@arris.com>
Date: Tuesday, 8 August 2017 at 19:16
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "vpp-dev@lists.fd.io" 
<vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] vpp v17.07 ping assert


Neale,

Sorry, I'm a bit new to this.

I'm working with git cli. What GUI are you referring to? Eclipse/EGit?

This is the change:

[mage removed by sender.]
Mohammed Hawari <mhaw...@cisco.com<mailto:mhaw...@cisco.com>>
07/18/2017 09:25:01 AM +0200
Committed by: John Lo <l...@cisco.com<mailto:l...@cisco.com>>
07/27/2017 10:10:26 PM +

ping: fixing wrong value when there are worker threads - the echo_reply_node is 
now notifying the cli process on the main thread/vlib_main - the timestamp for 
the icmp reply is now acquired in the echo_reply_node and not in the cli 
process to avoid an off by 10ms error (see 【vpp-dev】delay is error in ping with 
multi worker thread) Change-Id: I21d37002b0376b4f2ccab08d8f04c2f2944b9b39 
Signed-off-by: Mohammed Hawari

I've seen references to gerrit-cherry-pick. Should I use that?

Thanks,

-Steve
On 08/08/2017 01:00 PM, Neale Ranns (nranns) wrote:

Hi Steve,



Could you please press the cherry pick button on those review[s] to get them 
into stable/1707.



Thanks,

neale



-Original Message-

From: <vpp-dev-boun...@lists.fd.io><mailto:vpp-dev-boun...@lists.fd.io> on 
behalf of "Heckman, Steve" 
<steve.heck...@arris.com><mailto:steve.heck...@arris.com>

Date: Tuesday, 8 August 2017 at 17:01

To: "vpp-dev@lists.fd.io"<mailto:vpp-dev@lists.fd.io> 
<vpp-dev@lists.fd.io><mailto:vpp-dev@lists.fd.io>

Subject: Re: [vpp-dev] vpp v17.07 ping assert



FWIW...I back-merged the changes to ping.[ch] from master to 17.07 locally 
and now it works.



-Steve



-Original Message-

From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Steve Heckman

Sent: Tuesday, August 8, 2017 10:56 AM

To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>

Subject: [vpp-dev] vpp v17.07 ping assert



I've been running into issues on certain servers where I get an assert:



Aug 08 09:51:52 p5s3 systemd[1]: vpp.service: Main process exited, 
code=killed, status=6/ABRT Aug 08 09:51:52 p5s3 systemd[1]: vpp.service: Unit 
entered failed state.

Aug 08 09:51:52 p5s3 systemd[1]: vpp.service: Failed with result 'signal'.



here in ping.c



   vlib_process_signal_event (vm, pr->cli_process_id, event_type, bi0_copy);



which calls vec_elt, where the assert actually occurs.



/** \brief Get vector value at index i checking that i is in bounds. */

#define vec_elt_at_index(v,i)   \

({  \

   ASSERT ((i) < vec_len (v));   \

   (v) + (i);\

})



/** \brief Get vector value at index i */ #define vec_elt(v,i) 
(vec_elt_at_index(v,i))[0]



pr->cli_process_id is set in run_ping_ip46_address() and always seems to

be 344.



   uword curr_proc = vlib_current_process (vm);



:



   pr->cli_process_id = curr_proc;



vec_len(v) seems to be 32 (Does that make sense?).



Everything else seems to work OK. I can do "show interface (addr)", "show 
ip arp".



Any ideas?



This is stock apt install on Ubuntu 16.04 LTS on HPG9 and SMC servers with 
Intel 82599 NICs.



Thanks,



Steve Heckman



Principal Software Engineer



Arris



___

vpp-dev mailing list

vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>


https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fd.io%2Fmailman%2Flistinfo%2Fvpp-dev=01%7C01%7CSteve.Heckman%40arris.com%7C07ca668477d64175ab0308d4de6db8ee%7Cf27929ade5544d55837ac561519c3091%7C1=vc%2Flg81kKLNwVjxd6n33tzkL5%2B%2BObfEhpnCg7y16zRA%3D=0

___

vpp-dev mailing list

vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>


https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fd.io%2Fmailman%2Flistinfo%2Fvpp-dev=01%7C01%7CSteve.Heckman%40arris.com%7C003ce87b5bd647d251da08d4de7eecee%7Cf27929ade5544d55837ac561519c3091%7C1=5W8hRzZRZazYdt1RnrpYkxhQOH7Ho0ABq%2FEQsN%2BqofU%3D=0





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

Re: [vpp-dev] vpp v17.07 ping assert

[Neale Ranns (nranns)]

Hi Steve,

Could you please press the cherry pick button on those review[s] to get them 
into stable/1707.

Thanks,
neale

-Original Message-
From:  on behalf of "Heckman, Steve" 

Date: Tuesday, 8 August 2017 at 17:01
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] vpp v17.07 ping assert

FWIW...I back-merged the changes to ping.[ch] from master to 17.07 locally 
and now it works.

-Steve

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Steve Heckman
Sent: Tuesday, August 8, 2017 10:56 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vpp v17.07 ping assert

I've been running into issues on certain servers where I get an assert:

Aug 08 09:51:52 p5s3 systemd[1]: vpp.service: Main process exited, 
code=killed, status=6/ABRT Aug 08 09:51:52 p5s3 systemd[1]: vpp.service: Unit 
entered failed state.
Aug 08 09:51:52 p5s3 systemd[1]: vpp.service: Failed with result 'signal'.

here in ping.c

   vlib_process_signal_event (vm, pr->cli_process_id, event_type, bi0_copy);

which calls vec_elt, where the assert actually occurs.

/** \brief Get vector value at index i checking that i is in bounds. */
#define vec_elt_at_index(v,i)   \
({  \
   ASSERT ((i) < vec_len (v));   \
   (v) + (i);\
})

/** \brief Get vector value at index i */ #define vec_elt(v,i) 
(vec_elt_at_index(v,i))[0]

pr->cli_process_id is set in run_ping_ip46_address() and always seems to
be 344.

   uword curr_proc = vlib_current_process (vm);

:

   pr->cli_process_id = curr_proc;

vec_len(v) seems to be 32 (Does that make sense?).

Everything else seems to work OK. I can do "show interface (addr)", "show 
ip arp".

Any ideas?

This is stock apt install on Ubuntu 16.04 LTS on HPG9 and SMC servers with 
Intel 82599 NICs.

Thanks,

Steve Heckman

Principal Software Engineer

Arris

___
vpp-dev mailing list
vpp-dev@lists.fd.io

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fd.io%2Fmailman%2Flistinfo%2Fvpp-dev=01%7C01%7CSteve.Heckman%40arris.com%7C07ca668477d64175ab0308d4de6db8ee%7Cf27929ade5544d55837ac561519c3091%7C1=vc%2Flg81kKLNwVjxd6n33tzkL5%2B%2BObfEhpnCg7y16zRA%3D=0
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


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

Re: [vpp-dev] https://gerrit.fd.io/r/#/c/7856/ Review gerrit please

[Neale Ranns (nranns)]

Merged.

Thanks,
neale

From:  on behalf of Thomas F Herbert 

Date: Tuesday, 8 August 2017 at 16:05
To: vpp-dev 
Subject: [vpp-dev] https://gerrit.fd.io/r/#/c/7856/ Review gerrit please


All:

Could someone please review this patch?

https://gerrit.fd.io/r/#/c/7856/

I have some additional dependent patches on this patch to submit.

--TFH

--
Thomas F Herbert
NFV and Fast Data Planes
Office of Technology
Red Hat
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [csit-dev] API Change Proposal: explicit FIB table create and delete

[Neale Ranns (nranns)]

Hi All,

In the absence of any objections I have done:
  https://gerrit.fd.io/r/#/c/7819/

I’ll have a crack at the necessary CSIT changes. Is this:
  https://wiki.fd.io/view/CSIT/Tutorials/Vagrant/Virtualbox/Ubuntu
still the recommended way to test CSIT code changes?

Thanks,
neale


From: Dave Wallace <dwallac...@gmail.com>
Date: Thursday, 3 August 2017 at 22:19
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "vpp-dev@lists.fd.io" 
<vpp-dev@lists.fd.io>, "csit-...@lists.fd.io" <csit-...@lists.fd.io>, 
"honeycomb-...@lists.fd.io" <honeycomb-...@lists.fd.io>
Subject: Re: [csit-dev] API Change Proposal: explicit FIB table create and 
delete

+1

Dave
On 8/3/17 3:56 AM, Neale Ranns (nranns) wrote:

Dear All,



I would like to propose the addition of a new API to explicitly create and 
delete FIB tables. At present the only way to create FIB tables (for e.g. VRFs) 
is to:

1) Bind an interface to a new table index; ‘set int ip table Eth0 

2) Add a route in a new table and set the create_vrf_if_needed flag



With the addition of an explicit create we have the possibility to set 
per-table properties, like the flow-hash and (potentially) the mtrie stride (to 
favour memory over performance for small VRFs). With an explicit delete VPP is 
aware when it is safe to delete the table.



An explicit API makes the management of FIB tables by the agent/client the same 
as managing any other table resource, like Bridge-Domains or classify tables.



Regards,

neale



___

csit-dev mailing list

csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>

https://lists.fd.io/mailman/listinfo/csit-dev

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

[vpp-dev] API Change: Dedicated SW interface Event

[Neale Ranns (nranns)]

Hi All,

I would like to propose the addition of a dedicated SW interface event message 
type rather than overload the set flags request. The over-loading of types 
causes problems for the automatic API generation tools.

https://gerrit.fd.io/r/#/c/7925/

regards,
neale


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

Re: [vpp-dev] 17.07 Release

[Neale Ranns (nranns)]

In general, there is no limit to the number of MPLS labels. If you can be more 
specific about what you are referring to (i.e. how many labels can be pushed 
per LSP, or how many MPLS lookups/pops per packet) then I can give you a more 
definitive answer.

/neale

-Original Message-
From: Алексей Болдырев <devel-net-ne-vleza...@yandex.ru>
Date: Monday, 7 August 2017 at 10:30
To: "Kinsella, Ray" <ray.kinse...@intel.com>, "Neale Ranns (nranns)" 
<nra...@cisco.com>, "Luke, Chris" <chris_l...@comcast.com>, 
"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] 17.07 Release

Tell me please, how many MPLS-labels on the stack supports VPP?

07.08.2017, 07:25, "Kinsella, Ray" <ray.kinse...@intel.com>:
> Thanks !
>
> On 31/07/2017 13:51, Neale Ranns (nranns) wrote:
>>  Hi Chris,
>>
>>  Thanks for fixing it!
>>  Release notes now available at:
>>https://docs.fd.io/vpp/17.07/release_notes_1707.html
>>
>>  regards,
>>  neale
>>
    >>  -Original Message-
>>  From: "Luke, Chris" <chris_l...@comcast.com>
>>  Date: Monday, 31 July 2017 at 18:01
>>  To: "Neale Ranns (nranns)" <nra...@cisco.com>, "Kinsella, Ray" 
<ray.kinse...@intel.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
>>  Subject: Re: [vpp-dev] 17.07 Release
>>
>>  The next merge job to run on each branch will trigger it; or at 
least I hope it does.
>>
>>  I’ll do a ‘remerge’ on the current HEAD commit to see if that will 
do the needful
>>
>>  Chris.
>>
>>  On 7/31/17, 10:34, "vpp-dev-boun...@lists.fd.io on behalf of Neale 
Ranns (nranns)" <vpp-dev-boun...@lists.fd.io on behalf of nra...@cisco.com> 
wrote:
>>
>>  Hi Ray,
>>
>>  The release notes will appear here eventually:
>>   https://docs.fd.io/vpp/17.07/release_notes.html
>>
>>  there was a breakage in the generation of the docs, which Chris 
fixed, and was recently merged:
>>https://gerrit.fd.io/r/#/c/7818/
>>
>>  hopefully we will get the docs updated when the next patched is 
merged.
>>
>>  Regards,
>>  neale
>>
>>  -Original Message-
>>  From: <vpp-dev-boun...@lists.fd.io> on behalf of "Kinsella, 
Ray" <ray.kinse...@intel.com>
    >>  Date: Monday, 31 July 2017 at 15:42
>>  To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
>>  Subject: Re: [vpp-dev] 17.07 Release
>>
>>  Hi Neale,
>>
>>  Thanks for this - great work.
>>  Are there release notes archived anywhere?
>>
>>  Ray K
>>
>>  On 20/07/2017 16:56, Neale Ranns (nranns) wrote:
>>  >
>>  > Dear VPP community,
>>  >
>>  > The VPP 17.07 release is complete. The release artefacts 
are now available on the nexus server.
>>  >
>>  > I’d like to take this opportunity to thank you all for 
your continued support for VPP.
>>  >
>>  > Best regards,
>>  > Neale
>>  >
>>  >
>>  > ___
>>  > vpp-dev mailing list
>>  > vpp-dev@lists.fd.io
>>  > https://lists.fd.io/mailman/listinfo/vpp-dev
>>  >
>>  ___
>>  vpp-dev mailing list
>>  vpp-dev@lists.fd.io
>>  https://lists.fd.io/mailman/listinfo/vpp-dev
>>
>>  ___
>>  vpp-dev mailing list
>>  vpp-dev@lists.fd.io
>>  https://lists.fd.io/mailman/listinfo/vpp-dev
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev


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

Re: [vpp-dev] Million prefixes - FIB test

[Neale Ranns (nranns)]

Hi Vitaly,

Can you explain to me what you mean by ‘stops responding’? If you can execute 
‘sh fib mem’ that implies it’s still responsive?

Are you sure you are adding 1 million unique addresses at step 2?

Regards,
neale

From:  on behalf of Vitaly I 
Date: Friday, 4 August 2017 at 14:56
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Million prefixes - FIB test

Hi,
Vpp 17.04. I am trying to add 1 million prefix.
1) up interface
vpp# set int state GigabitEthernet82/0/3 up
vpp# set int l3 GigabitEthernet82/0/3
vpp# set int ip addr GigabitEthernet82/0/3 1.1.1.10/24
vpp# set ip arp GigabitEthernet82/0/3 1.1.1.1 11:22:33:44:55:66 static
2) and repeat vppctl with cmd like
vppctl ip route add 10.x.x.x/32 via 1.1.1.1
3) check fib
vpp# show fib mem

My tests always end at ~162k prefixes and vpp stops responding.
FIB memory
 Name   Size  in-use /allocated   totals
 Entry   72   161883 /  16188311655576/11655576
 Entry Source32   161884 /  1618845180288/5180288
 Entry Path-Extensions   56  0   /0   0/0
multicast-Entry 192  6   /6   1152/1152
   Path-list 40 15   /16  600/640
   uRPF-list 16 11   /11  176/176
 Path80 15   /16  1200/1280
  Node-list elements 20   161889 /  1618893237780/3237780
Node-list heads  8  18   /18  144/144

What do I need to do to increase the number of FIB entries?

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