Re: [vpp-dev] Different available feature paths in VPP

[Ni, Hongjun]

Hi Burt,

It is fixed. Thank you!

Regards,
Hongjun

From: Burt Silverman [mailto:bur...@gmail.com]
Sent: Saturday, June 10, 2017 6:34 AM
To: Ni, Hongjun 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Different available feature paths in VPP

I cannot begin to imagine how you got the unexpected result. I tried with my 
output from "make build-release" and I obtained your make test results.
Burt

On Wed, Jun 7, 2017 at 2:42 AM, Ni, Hongjun 
mailto:hongjun...@intel.com>> wrote:
Hey all,

When I start vpp using latest code and enter “show features” in CLI in my 
server, I got below output,
which is different from the log output by doing “make test”.
Is there something I missed?

vpp# sh feat
Available feature paths
nsh-output:
mpls-output:
mpls-input:
ip6-output:
ip6-multicast:
ip6-unicast:
ip4-local:
ip4-output:
  nsh-md2-ioam-encap-transit
ip4-multicast:
ip4-unicast:
  snat-in2out
  snat-out2in
  snat-det-in2out
  snat-det-out2in
  snat-in2out-worker-handoff
  snat-out2in-worker-handoff
  snat-in2out-fast
  snat-out2in-fast
ethernet-output:
interface-output:
device-input:

Below is the log output by doing “make test”.  I think below output is correct 
and expected.
22:29:25,908 CLI: show features
22:29:25,908 Available feature paths
nsh-output:
  adj-midchain-tx
  adj-midchain-tx-no-count
  error-drop
mpls-output:
  interface-output
  adj-midchain-tx
  adj-midchain-tx-no-count
mpls-input:
  mpls-not-enabled
  mpls-lookup
ip6-output:
  ipsec-output-ip6
  interface-output
  adj-midchain-tx
  adj-midchain-tx-no-count
  acl-plugin-out-ip6-fa
  flowprobe-ip6
ip6-multicast:
  vpath-input-ip6
  ip6-drop
  ip6-mfib-forward-lookup
ip6-unicast:
  ip6-flow-classify
  ip6-inacl
  ip6-policer-classify
  ipsec-input-ip6
  l2tp-decap
  vpath-input-ip6
  ip6-vxlan-bypass
  ip6-drop
  ip6-lookup
  acl-plugin-in-ip6-fa
  sir-to-ila
ip4-local:
  ip4-local-end-of-arc
  syn-filter-4
ip4-output:
  ip4-source-and-port-range-check-tx
  ipsec-output-ip4
  interface-output
  adj-midchain-tx
  adj-midchain-tx-no-count
  acl-plugin-out-ip4-fa
  flowprobe-ip4
  vxlan-gpe-transit-ioam
ip4-multicast:
  vpath-input-ip4
  ip4-drop
  ip4-mfib-forward-lookup
ip4-unicast:
  ip4-flow-classify
  ip4-inacl
  ip4-source-check-via-rx
  ip4-source-check-via-any
  ip4-source-and-port-range-check-rx
  ip4-policer-classify
  ipsec-input-ip4
  vpath-input-ip4
  ip4-vxlan-bypass
  ip4-drop
  ip4-lookup
  acl-plugin-in-ip4-fa
  snat-in2out
  snat-out2in
  snat-det-in2out
  snat-det-out2in
  snat-in2out-worker-handoff
  snat-out2in-worker-handoff
  snat-in2out-fast
  snat-out2in-fast
ethernet-output:
  error-drop
  adj-midchain-tx
  adj-midchain-tx-no-count
interface-output:
  span-output
  interface-tx
  flowprobe-l2
device-input:
  l2-patch
  worker-handoff
  span-input
  ethernet-input
  sr-pl-rewrite-encaps-l2

Thanks a lot,
Hongjun

___
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] problem getting udp_register_dst_port interface to work.

[Neale Ranns (nranns)]

Hi Guy,

Your cofing looks fine. But since you’ve programmed an (S,G) can I please see:
  sh ip mfib 10.10.10.34 232.0.0.1

since this is ‘for-us’ traffic you still have to abide by the ‘need a route 
back to the sender’ rule. So please;
  sh ip fib 10.10.10.34

also;
sh error
is helpful in the game of who-dropped-my-packet.

Thanks,
neale

From: "Guy Doucet -X (gudoucet - FLEXTRONICS CANADA DESIGN SERVICES INC at 
Cisco)" 
Date: Tuesday, 13 June 2017 at 20:55
To: "Neale Ranns (nranns)" , vpp-dev 
Subject: RE: [vpp-dev] problem getting udp_register_dst_port interface to work.

I configured mroute as follows:

vppctl ip mroute 10.10.10.34 232.0.0.1 via TenGigabitEthernet81/0/0 Accept
vppctl ip mroute 10.10.10.34 232.0.0.1 via local Forward

Is this correct?

I get the following output for vppclt sh ip mfib 232.0.0.1
ipv4-VRF:0, fib_index 0
(*, 0.0.0.0/0):  flags:D,
fib:0 index:0 locks:1
  src:Default Route:  flags:D,
Extensions:
Interface-Forwarding:

  Interfaces:
  RPF-ID:0
  multicast-ip4-chain
  [@0]: dpo-drop ip4

The full trace back is as follows:

01:22:29:244227: dpdk-input
  TenGigabitEthernet81/0/0 rx queue 0
  buffer 0xdc70d0: current data 14, length 1428, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x9
  PKT MBUF: port 0, nb_segs 1, pkt_len 1442
buf_len 2176, data_len 1442, ol_flags 0x88, data_off 128, phys_addr 
0x89bd940
packet_type 0x0
Packet Offload Flags
  PKT_RX_L4_CKSUM_BAD (0x0008) L4 cksum of RX pkt. is not OK
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  IP4: 00:02:c5:1b:51:08 -> 01:00:5e:00:00:01
  UDP: 10.10.10.34 -> 232.0.0.1
tos 0x00, ttl 0, length 1428, checksum 0x792c
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1234 -> 5001
length 1408, checksum 0x
01:22:29:244229: ip4-input-no-checksum
  UDP: 10.10.10.34 -> 232.0.0.1
tos 0x00, ttl 0, length 1428, checksum 0x792c
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1234 -> 5001
length 1408, checksum 0x
01:22:29:244231: ip4-mfib-forward-lookup
  fib 0 entry 6
01:22:29:244231: ip4-mfib-forward-rpf
  entry 6 1 Accept,

Thanks,

Guy

From: Neale Ranns (nranns)
Sent: Tuesday, June 13, 2017 12:20 PM
To: Guy Doucet -X (gudoucet - FLEXTRONICS CANADA DESIGN SERVICES INC at Cisco); 
vpp-dev
Subject: Re: [vpp-dev] problem getting udp_register_dst_port interface to work.


Hi Guy,

If that’s the full packet trace, then it looks like the packet was dropped by 
an input feature. Use:
  sh int feat 
To see what’s configured. Do you have an IP address configured on the input 
interface? You’ll need one.

If it’s not that, do you have a route for 232.0.0.1 in the multicast FIB? If so 
what is it:
  sh ip mfib 232.0.0.1

Regards,
Neale


From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of "Guy Doucet -X (gudoucet - FLEXTRONICS CANADA DESIGN SERVICES INC at 
Cisco)" mailto:gudou...@cisco.com>>
Date: Tuesday, 13 June 2017 at 16:56
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] problem getting udp_register_dst_port interface to work.

I am trying to process the following packets using the udp_register_dst_port 
interface:

  UDP: 10.10.10.34 -> 232.0.0.1
tos 0x00, ttl 0, length 1428, checksum 0x792c
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1234 -> 5001
length 1408, checksum 0x
01:22:29:244229: ip4-input-no-checksum
  UDP: 10.10.10.34 -> 232.0.0.1
tos 0x00, ttl 0, length 1428, checksum 0x792c
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1234 -> 5001

My registration function below is getting called:

#define UDP_DST_PORT_stream 5001
  udp_register_dst_port (vm, UDP_DST_PORT_stream,
 udp4_test_node.index, 1 /* is_ip4 */);

But I never get a call when packets are received. Any idea what could be going 
wrong or how to debug this?

Thanks,

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

Re: [vpp-dev] VPP API improvements - community discussion.

[otroan]

Jon,

> I don't know about user friendly; I can wade through the technical details.
> 
> I think one thing that is annoying about the API is a lack of consistency.
> Here are some examples:
> 
>- Sometimes the flag is "u8 is_ipv4", other times it is "u8 is_ipv6".
>- Sometimes the flag is "u8 is_ip4", other times it is "u8 is_ip6".

Annoying indeed.
For these one suggestion has been to remove them and instead use address/prefix 
types that have address-family included.

>- Sometimes the flag is "u8 is_add", or "u8 is_del", or "u32 is_add".

if we want something like a CRUD API, it might be better to have separate 
_delete messages.
Often they don't have same parameters like the _add. Opinions?

>- "is_enable" vs "is_enabled"
>- Some API calls are "foo_add_del", some are "foo_add_replace",
>  and some are "foo_add" and "foo_del"

Yep. Good if we could agree on one convention here.

> I know that sounds trivial.  I get that.  But it makes for tough anticipation
> and violates some principle of least-surprise-or-another.

Agree. I think this inconsistency just adds confusion and irritation too.

> 
> I get that different people work on different areas, but there needs to
> be some consistency both in the names of the API calls and within
> the API fields themselves.
> 
> It would be documentationally nice for the API comment blocks to
> explicitly denote what default values pertain to the fields of an API call.
> Similarly, denote what the values of the "invalid" entry are.  Is it 0?
> Or is it -1 or is it ~0?

Yes, I have also seen people want to add enums and perhaps do constants for 
these.

Cheers,
Ole



signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] problem getting udp_register_dst_port interface to work.

[Guy Doucet -X (gudoucet - FLEXTRONICS CANADA DESIGN SERVICES INC at Cisco)]

I configured mroute as follows:

vppctl ip mroute 10.10.10.34 232.0.0.1 via TenGigabitEthernet81/0/0 Accept
vppctl ip mroute 10.10.10.34 232.0.0.1 via local Forward

Is this correct?

I get the following output for vppclt sh ip mfib 232.0.0.1
ipv4-VRF:0, fib_index 0
(*, 0.0.0.0/0):  flags:D,
fib:0 index:0 locks:1
  src:Default Route:  flags:D,
Extensions:
Interface-Forwarding:

  Interfaces:
  RPF-ID:0
  multicast-ip4-chain
  [@0]: dpo-drop ip4

The full trace back is as follows:

01:22:29:244227: dpdk-input
  TenGigabitEthernet81/0/0 rx queue 0
  buffer 0xdc70d0: current data 14, length 1428, free-list 0, clone-count 0, 
totlen-nifb 0, trace 0x9
  PKT MBUF: port 0, nb_segs 1, pkt_len 1442
buf_len 2176, data_len 1442, ol_flags 0x88, data_off 128, phys_addr 
0x89bd940
packet_type 0x0
Packet Offload Flags
  PKT_RX_L4_CKSUM_BAD (0x0008) L4 cksum of RX pkt. is not OK
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  IP4: 00:02:c5:1b:51:08 -> 01:00:5e:00:00:01
  UDP: 10.10.10.34 -> 232.0.0.1
tos 0x00, ttl 0, length 1428, checksum 0x792c
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1234 -> 5001
length 1408, checksum 0x
01:22:29:244229: ip4-input-no-checksum
  UDP: 10.10.10.34 -> 232.0.0.1
tos 0x00, ttl 0, length 1428, checksum 0x792c
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1234 -> 5001
length 1408, checksum 0x
01:22:29:244231: ip4-mfib-forward-lookup
  fib 0 entry 6
01:22:29:244231: ip4-mfib-forward-rpf
  entry 6 1 Accept,

Thanks,

Guy

From: Neale Ranns (nranns)
Sent: Tuesday, June 13, 2017 12:20 PM
To: Guy Doucet -X (gudoucet - FLEXTRONICS CANADA DESIGN SERVICES INC at Cisco); 
vpp-dev
Subject: Re: [vpp-dev] problem getting udp_register_dst_port interface to work.


Hi Guy,

If that’s the full packet trace, then it looks like the packet was dropped by 
an input feature. Use:
  sh int feat 
To see what’s configured. Do you have an IP address configured on the input 
interface? You’ll need one.

If it’s not that, do you have a route for 232.0.0.1 in the multicast FIB? If so 
what is it:
  sh ip mfib 232.0.0.1

Regards,
Neale


From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of "Guy Doucet -X (gudoucet - FLEXTRONICS CANADA DESIGN SERVICES INC at 
Cisco)" mailto:gudou...@cisco.com>>
Date: Tuesday, 13 June 2017 at 16:56
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] problem getting udp_register_dst_port interface to work.

I am trying to process the following packets using the udp_register_dst_port 
interface:

  UDP: 10.10.10.34 -> 232.0.0.1
tos 0x00, ttl 0, length 1428, checksum 0x792c
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1234 -> 5001
length 1408, checksum 0x
01:22:29:244229: ip4-input-no-checksum
  UDP: 10.10.10.34 -> 232.0.0.1
tos 0x00, ttl 0, length 1428, checksum 0x792c
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1234 -> 5001

My registration function below is getting called:

#define UDP_DST_PORT_stream 5001
  udp_register_dst_port (vm, UDP_DST_PORT_stream,
 udp4_test_node.index, 1 /* is_ip4 */);

But I never get a call when packets are received. Any idea what could be going 
wrong or how to debug this?

Thanks,

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

Re: [vpp-dev] VPP API improvements - community discussion.

[Jon Loeliger]

On Mon, Jun 5, 2017 at 5:24 AM, Neale Ranns (nranns)  wrote:
>
> Dear VPP community,
>
> Some of the feedback we get from users of VPP is that the client-side API is 
> not particularly user-friendly – we would like to address this.

I don't know about user friendly; I can wade through the technical details.

I think one thing that is annoying about the API is a lack of consistency.
Here are some examples:

- Sometimes the flag is "u8 is_ipv4", other times it is "u8 is_ipv6".
- Sometimes the flag is "u8 is_ip4", other times it is "u8 is_ip6".

- Sometimes the flag is "u8 is_add", or "u8 is_del", or "u32 is_add".
- "is_enable" vs "is_enabled"
- Some API calls are "foo_add_del", some are "foo_add_replace",
  and some are "foo_add" and "foo_del"

I know that sounds trivial.  I get that.  But it makes for tough anticipation
and violates some principle of least-surprise-or-another.

I get that different people work on different areas, but there needs to
be some consistency both in the names of the API calls and within
the API fields themselves.

It would be documentationally nice for the API comment blocks to
explicitly denote what default values pertain to the fields of an API call.
Similarly, denote what the values of the "invalid" entry are.  Is it 0?
Or is it -1 or is it ~0?


> Naturally ☺ In order to create an API that the user community considers 
> effective, easy and intuitive to use, it must be a community wide discussion. 
> To kick-start that discussion, and to provide some initial focus on the 
> specific topics, the document below outlines a set of proposals that we hope 
> moves us in this direction.

Is there an explicit list of common complaints that we could work against?
As we all know "It sucks." is pretty generic and hard to fix... :-)

>
> please let us know any opinions you have on this topic, or feedback, 
> suggestions, additions, etc to the document, either by replying to this 
> thread, unicasting me, or by adding comments directly to the document.
>
> Thanks in advance,
>
> Neale

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

Re: [vpp-dev] ALG

[Denis Lotarev via vpp-dev]

And so for a "joke", we would like to replace six servers with double 10G NICs 
running on Linux Iptables by VPP (dpdk) solution, because linux netfilter is so 
old, and deprecated (but this supported ALG).

--
Yours sincerely,
Denis Lotarev


On Tuesday, June 13, 2017, 6:23:14 PM GMT+5,  wrote:

Denis,

> Hi! Im working on Internet service provider, and ALG require for clients 
> which connected to their offices via pptp, sip, etc.
> But current SNAT plugin in master (build #2482) doesnt support pptp proto 
> inside (maybe sip also).

Yeah, don't use PPTP. Insecure and broken.
SIP applications must use ICE.

I'm sure whomever is using PPTP is looking for an excuse to move away from that 
protocol. ;-)

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

Re: [vpp-dev] problem getting udp_register_dst_port interface to work.

[Neale Ranns (nranns)]

Hi Guy,

If that’s the full packet trace, then it looks like the packet was dropped by 
an input feature. Use:
  sh int feat 
To see what’s configured. Do you have an IP address configured on the input 
interface? You’ll need one.

If it’s not that, do you have a route for 232.0.0.1 in the multicast FIB? If so 
what is it:
  sh ip mfib 232.0.0.1

Regards,
Neale


From:  on behalf of "Guy Doucet -X (gudoucet - 
FLEXTRONICS CANADA DESIGN SERVICES INC at Cisco)" 
Date: Tuesday, 13 June 2017 at 16:56
To: vpp-dev 
Subject: [vpp-dev] problem getting udp_register_dst_port interface to work.

I am trying to process the following packets using the udp_register_dst_port 
interface:

  UDP: 10.10.10.34 -> 232.0.0.1
tos 0x00, ttl 0, length 1428, checksum 0x792c
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1234 -> 5001
length 1408, checksum 0x
01:22:29:244229: ip4-input-no-checksum
  UDP: 10.10.10.34 -> 232.0.0.1
tos 0x00, ttl 0, length 1428, checksum 0x792c
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1234 -> 5001

My registration function below is getting called:

#define UDP_DST_PORT_stream 5001
  udp_register_dst_port (vm, UDP_DST_PORT_stream,
 udp4_test_node.index, 1 /* is_ip4 */);

But I never get a call when packets are received. Any idea what could be going 
wrong or how to debug this?

Thanks,

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

[vpp-dev] problem getting udp_register_dst_port interface to work.

[Guy Doucet -X (gudoucet - FLEXTRONICS CANADA DESIGN SERVICES INC at Cisco)]

I am trying to process the following packets using the udp_register_dst_port 
interface:

  UDP: 10.10.10.34 -> 232.0.0.1
tos 0x00, ttl 0, length 1428, checksum 0x792c
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1234 -> 5001
length 1408, checksum 0x
01:22:29:244229: ip4-input-no-checksum
  UDP: 10.10.10.34 -> 232.0.0.1
tos 0x00, ttl 0, length 1428, checksum 0x792c
fragment id 0x, flags DONT_FRAGMENT
  UDP: 1234 -> 5001

My registration function below is getting called:

#define UDP_DST_PORT_stream 5001
  udp_register_dst_port (vm, UDP_DST_PORT_stream,
 udp4_test_node.index, 1 /* is_ip4 */);

But I never get a call when packets are received. Any idea what could be going 
wrong or how to debug this?

Thanks,

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

Re: [vpp-dev] Interfaces not found with VPP under VMWare Workstation and CentOS guest

[Burt Silverman]

It was a VMWare Workstation bug, but I forgot, I have a 2 year old version
of that product. Bad e1000 emulation.

On Mon, Jun 12, 2017 at 2:34 PM, Burt Silverman  wrote:

> I have no problem building and running VPP using openSUSE and VirtualBox.
> I created a network interface and it shows as down after I start openSUSE.
> And after I start VPP, "show int" shows the interface.
>
> I can likewise create an e1000 interface [VMWare doesn't tell me it is
> e1000, but the kernel does] on VMWare. It is down with no addresses when I
> start CentOS. It has a PCI bus address.
>
> One thing that is similar in both working and non-working environments:
> the interface disappears from ifconfig -a after VPP starts running.
>
> But this interface does not produce any messages from DPDK, and I get the
> 0 ports problem.
>
> I don't know where to start trying to debug what DPDK is up to. Maybe
> someone knows quickly what it is about VMWare Workstation that requires
> extra TLC? Or how to debug? Even the build system is hairy in this DPDK
> area.
>
> Thanks.
>
> Burt
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] ALG

[Denis Lotarev via vpp-dev]

Im agree with you as the end user, that this protocols are insecure and 
deprecated, but so on the other hand, as service provider we are should 
transmit all client traffic to another point :)Service provider shouldnt tell 
the client what protocols to use or not use.And if ISP have about 1 clients 
with pptp or sip protocols (only for forward this traffic to another point), 
what should do service provider without supporting ALG?

--
Yours sincerely,
Denis Lotarev


On Tuesday, June 13, 2017, 6:23:14 PM GMT+5,  wrote:

Denis,

> Hi! Im working on Internet service provider, and ALG require for clients 
> which connected to their offices via pptp, sip, etc.
> But current SNAT plugin in master (build #2482) doesnt support pptp proto 
> inside (maybe sip also).

Yeah, don't use PPTP. Insecure and broken.
SIP applications must use ICE.

I'm sure whomever is using PPTP is looking for an excuse to move away from that 
protocol. ;-)

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

Re: [vpp-dev] ALG

[otroan]

Denis,

> Hi! Im working on Internet service provider, and ALG require for clients 
> which connected to their offices via pptp, sip, etc.
> But current SNAT plugin in master (build #2482) doesnt support pptp proto 
> inside (maybe sip also).

Yeah, don't use PPTP. Insecure and broken.
SIP applications must use ICE.

I'm sure whomever is using PPTP is looking for an excuse to move away from that 
protocol. ;-)

Best regards,
Ole



signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] ALG

[Denis Lotarev via vpp-dev]

Hi! Im working on Internet service provider, and ALG require for clients which 
connected to their offices via pptp, sip, etc.But current SNAT plugin in master 
(build #2482) doesnt support pptp proto inside (maybe sip also).
 

--
Yours sincerely,
Denis Lotarev___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] How to get interface stats using python api?

[otroan]

Weitao,

> I noticed that in interface.api.
> 
> manual_print manual_endian define vnet_interface_combined_counters
> {
>   /* enums - plural - in vnet/interface.h */
>   u8 vnet_counter_type;
>   u32 first_sw_if_index;
>   u32 count;
>   vl_api_vlib_counter_t data[count];
> };
> 
> 
> Should vl_api_vlib_counter_t be u64? Is that right?

interface.api:
typeonly manual_print manual_endian define vlib_counter
{
  u64 packets;  /**< packet counter */
  u64 bytes;/**< byte counter  */
};

Cheers,
Ole


> 2017-06-13 18:56 GMT+08:00 :
> Hi again,
> 
> > I tried the method you told me, but the data that I got is '\x00'.
> >
> > Like this, vnet_interface_counters(_0=49, vnet_counter_type=1, 
> > is_combined=1, first_sw_if_index=0, count=7, 
> > data='\x00\x00\x00\x00\x00\x00\x00')
> >
> > I don't why this happened.
> 
> Ah, yes sorry. Forgot to tell you that it was broken prior to below commit.
> 
> You need:
> 
> commit ee551988bcce08ad7a15f71fb9d2239b4239ab08
> Author: Aloys Augustin 
> Date:   Fri Feb 17 14:55:29 2017 +0100
> 
> Fix vnet_interface_counters API definition
> 
> The api specification had u8 as data type, which caused the python
> binding to fail.
> Fixes VPP-642
> 
> Change-Id: I9ba97959740d44c8f4a12db9356d0d1bcd709a73
> Signed-off-by: Aloys Augustin 
> Signed-off-by: Ole Troan 
> 
> 
> And that changes vnet_interface_counters to a simple and a combined counters 
> version.
> 
> Sorry, for trickle feeding you information, my brain trashed in the middle of 
> the context switch. ;-)
> 
> Feel free to put something on the wiki as you go along.
> 
> Best regards,
> Ole
> 



signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] A few questions regarding mcast fib

[Neale Ranns (nranns)]

Quite a few of the multicast related options are not available via the CLI. I 
don’t use the debug CLI much for testing, it’s all done in the python UT 
through the API. If you can see your way to adding CLI options, I’d be grateful.

Thanks,
neale

From: Nagaprabhanjan Bellari 
Date: Tuesday, 13 June 2017 at 12:37
To: "Neale Ranns (nranns)" 
Cc: vpp-dev 
Subject: Re: [vpp-dev] A few questions regarding mcast fib

One question: I dont see a "multicast" option with the "mpls local-label" 
command with latest VPP - am I missing something?
Thanks,
-nagp

On Tue, Jun 13, 2017 at 4:40 PM, Nagaprabhanjan Bellari 
mailto:nagp.li...@gmail.com>> wrote:
Thank you! As always, a great answer!
This itself is good enough a documentation to get going. :-)
-nagp

On Tue, Jun 13, 2017 at 4:34 PM, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:
Hi nagp,

VPP does support those scenarios. I’ve not written any documentation sadly, so 
I’ll write some instructions here… When I wrote the mfib/mpls code I did little 
testing via the debug CLI, so some of the options below are not be available 
via the CLI, I’ve put those options is []. I’ll be cheeky and leave the 
implementation as an exercise to the reader…. but see test_mpls.py and the 
test_mcast* functions therein for the various head, midpoint and tail 
programming via the API. There are also examples of how to setup the 
fib_route_path_t for each scenario in [m]fib_test.c.

IP-to-IP:

Adding routes to the mfib, and adding replications for those routes, is similar 
to adding ECMP paths to routes in the unicast-fib (they even share the sme 
fib_path[_list] code).
The prefix in the mFIB can be:

1)(*,G/m)
ip mroute add 232.1.0.0/16 via Eth0 Forward

2)   (*,G)

ip mroute add 232.1.1.1 via Eth0 Forward

3)   (S,G)

   ip mroute add 1.1.1.1 239.1.1.1 via Eth0 Forward

adding more replications is achieved by adding more paths:

ip mroute add 1.1.1.1 239.1.1.1 via Eth1 Forward

ip mroute add 1.1.1.1 239.1.1.1 via Eth2 Forward

ip mroute add 1.1.1.1 239.1.1.1 via Eth3 Forward

You’ll note the path is “attached”, i.e. only the interface is given and not 
the next-hop. For mcast routes this is the expected case. The path will resolve 
via the special multicast adjacency on the interface, which will perform the 
MAC address fixup at switch time. If you want to specify a next-hop in the 
path, and so have a unicast MAC address applied, then you’ll need: 
https://gerrit.fd.io/r/#/c/6974/

The flag ‘Forward’ is required to specify this is as a replication, i.e. a path 
used for forwarding. This distinction is required because for multicast one 
must also specify the RPF constraints. RPF can be specified in several ways:

1)   a particular [set of] interfaces;

  ip mroute add 1.1.1.1 239.1.1.1 via Eth10 Accept

2)   An RPF-ID (more on this later). No CLI for this

3)   Accept from any interface – this can be thought of as an RPF ‘don’t 
care’ – there are no loops, I personally guarantee it :/
   ip mroute 1.1.1.1 239.1.1.1 AA
the AA stands for accept-any-interface – it is a property of the mFIB entry, 
not one of its paths

At this point we do not support PIM register tunnels.

IP-to-MPLS: the head-end

VPP supports point-2-multi-point (P2MP) MPLS tunnels (the sort of tunnels that 
one gets via e.g. RSVP P2MP-TE) and P2MP LSPs (e.g. those one gets from mLDP) – 
the difference is essentially the presence (for the former) and lack of (for 
the latter) an interface associated with the LSP.

At the head end one has choices:

1)   Add replications to the mroute over multiple unicast tunnels, e.g.

ip mroute add 1.1.1.1 239.1.1.1 via mpls-tunnel1 Forward

ip mroute add 1.1.1.1 239.1.1.1 via mpls-tunnel2 Forward

ip mroute add 1.1.1.1 239.1.1.1 via mpls-tunnel3 Forward

but note that we do not support having an ‘out-label’ specification here, hence 
the tunnels must be dedicated to the mroute – which is not so scalable.

2)   Define one MPLS P2MP tunnel with replications
  mpls tunnel [multicast] add via 10.10.10.10 Eth0 out-label 55
  mpls tunnel  add via 11.11.11.11 Eth1 out-label 66
and then point the mroute via this tunnel
  ip mroute 1.1.1.1 239.1.1.1 via mpls-tunnelXXX Forward
the tunnel can be shared or dedicated to the mroute (i.e. a default or data 
MDT).

option 2 is the typical/recommended way, since it reflects the control plane 
model; BGP gives paths via the core-tress (i.e. replications for the mroute via 
tunnels) and mLDP/RSVP-TE builds the LSPs (add/removes replications for the 
P2MP MPLS tunnel).

If there are also IP replications to make, then combinations can be used, e.g.;
ip mroute 1.1.1.1 239.1.1.1 via mpls-tunnelXXX
ip mroute 1.1.1.1 239.1.1.1 via Eth0 Forward
2-stage replication; first via all tunnels and all attached peers, then via 
each next-hop in the tunnel.


MPLS-to-MPLS: the mid-point.


At the mid-point we build MPLS entries that perform replication:
   mpls local-label 

Re: [vpp-dev] A few questions regarding mcast fib

[Nagaprabhanjan Bellari]

One question: I dont see a "multicast" option with the "mpls local-label"
command with latest VPP - am I missing something?

Thanks,
-nagp

On Tue, Jun 13, 2017 at 4:40 PM, Nagaprabhanjan Bellari <
nagp.li...@gmail.com> wrote:

> Thank you! As always, a great answer!
>
> This itself is good enough a documentation to get going. :-)
>
> -nagp
>
> On Tue, Jun 13, 2017 at 4:34 PM, Neale Ranns (nranns) 
> wrote:
>
>> Hi nagp,
>>
>>
>>
>> VPP does support those scenarios. I’ve not written any documentation
>> sadly, so I’ll write some instructions here… When I wrote the mfib/mpls
>> code I did little testing via the debug CLI, so some of the options below
>> are not be available via the CLI, I’ve put those options is []. I’ll be
>> cheeky and leave the implementation as an exercise to the reader…. but see
>> test_mpls.py and the test_mcast* functions therein for the various head,
>> midpoint and tail programming via the API. There are also examples of how
>> to setup the fib_route_path_t for each scenario in [m]fib_test.c.
>>
>>
>>
>> IP-to-IP:
>>
>>
>>
>> Adding routes to the mfib, and adding replications for those routes, is
>> similar to adding ECMP paths to routes in the unicast-fib (they even share
>> the sme fib_path[_list] code).
>>
>> The prefix in the mFIB can be:
>>
>> 1)(*,G/m)
>>
>> ip mroute add 232.1.0.0/16 via Eth0 Forward
>>
>> 2)   (*,G)
>>
>> ip mroute add 232.1.1.1 via Eth0 Forward
>>
>> 3)   (S,G)
>>
>>ip mroute add 1.1.1.1 239.1.1.1 via Eth0 Forward
>>
>>
>>
>> adding more replications is achieved by adding more paths:
>>
>> ip mroute add 1.1.1.1 239.1.1.1 via Eth1 Forward
>>
>> ip mroute add 1.1.1.1 239.1.1.1 via Eth2 Forward
>>
>> ip mroute add 1.1.1.1 239.1.1.1 via Eth3 Forward
>>
>>
>>
>> You’ll note the path is “attached”, i.e. only the interface is given and
>> not the next-hop. For mcast routes this is the expected case. The path will
>> resolve via the special multicast adjacency on the interface, which will
>> perform the MAC address fixup at switch time. If you want to specify a
>> next-hop in the path, and so have a unicast MAC address applied, then
>> you’ll need: https://gerrit.fd.io/r/#/c/6974/
>>
>>
>>
>> The flag ‘Forward’ is required to specify this is as a replication, i.e.
>> a path used for forwarding. This distinction is required because for
>> multicast one must also specify the RPF constraints. RPF can be specified
>> in several ways:
>>
>> 1)   a particular [set of] interfaces;
>>
>>   ip mroute add 1.1.1.1 239.1.1.1 via Eth10 Accept
>>
>> 2)   An RPF-ID (more on this later). No CLI for this
>>
>> 3)   Accept from any interface – this can be thought of as an RPF
>> ‘don’t care’ – there are no loops, I personally guarantee it :/
>>
>>ip mroute 1.1.1.1 239.1.1.1 AA
>>
>> the AA stands for accept-any-interface – it is a property of the mFIB
>> entry, not one of its paths
>>
>>
>>
>> At this point we do not support PIM register tunnels.
>>
>>
>>
>> IP-to-MPLS: the head-end
>>
>>
>>
>> VPP supports point-2-multi-point (P2MP) MPLS tunnels (the sort of tunnels
>> that one gets via e.g. RSVP P2MP-TE) and P2MP LSPs (e.g. those one gets
>> from mLDP) – the difference is essentially the presence (for the former)
>> and lack of (for the latter) an interface associated with the LSP.
>>
>>
>>
>> At the head end one has choices:
>>
>> 1)   Add replications to the mroute over multiple unicast tunnels,
>> e.g.
>>
>> ip mroute add 1.1.1.1 239.1.1.1 via mpls-tunnel1 Forward
>>
>> ip mroute add 1.1.1.1 239.1.1.1 via mpls-tunnel2 Forward
>>
>> ip mroute add 1.1.1.1 239.1.1.1 via mpls-tunnel3 Forward
>>
>> but note that we do not support having an ‘out-label’ specification here,
>> hence the tunnels must be dedicated to the mroute – which is not so
>> scalable.
>>
>> 2)   Define one MPLS P2MP tunnel with replications
>>
>>   mpls tunnel [multicast] add via 10.10.10.10 Eth0 out-label 55
>>
>>   mpls tunnel  add via 11.11.11.11 Eth1 out-label 66
>>
>> and then point the mroute via this tunnel
>>
>>   ip mroute 1.1.1.1 239.1.1.1 via mpls-tunnelXXX Forward
>>
>> the tunnel can be shared or dedicated to the mroute (i.e. a default or
>> data MDT).
>>
>>
>>
>> option 2 is the typical/recommended way, since it reflects the control
>> plane model; BGP gives paths via the core-tress (i.e. replications for the
>> mroute via tunnels) and mLDP/RSVP-TE builds the LSPs (add/removes
>> replications for the P2MP MPLS tunnel).
>>
>>
>>
>> If there are also IP replications to make, then combinations can be used,
>> e.g.;
>>
>> ip mroute 1.1.1.1 239.1.1.1 via mpls-tunnelXXX
>>
>> ip mroute 1.1.1.1 239.1.1.1 via Eth0 Forward
>>
>> 2-stage replication; first via all tunnels and all attached peers, then
>> via each next-hop in the tunnel.
>>
>>
>>
>>
>>
>> MPLS-to-MPLS: the mid-point.
>>
>>
>>
>>
>>
>> At the mid-point we build MPLS entries that perform replication:
>>
>>mpls local-label [multicast] 33 eos via 10.10.10.10 eth0 out-label 77
>

Re: [vpp-dev] How to get interface stats using python api?

[Weitao Han]

I noticed that in interface.api.

manual_print manual_endian define vnet_interface_combined_counters
{
  /* enums - plural - in vnet/interface.h */
  u8 vnet_counter_type;
  u32 first_sw_if_index;
  u32 count;
  vl_api_vlib_counter_t data[count];
};


Should vl_api_vlib_counter_t be u64? Is that right?

2017-06-13 18:56 GMT+08:00 :

> Hi again,
>
> > I tried the method you told me, but the data that I got is '\x00'.
> >
> > Like this, vnet_interface_counters(_0=49, vnet_counter_type=1,
> is_combined=1, first_sw_if_index=0, count=7, data='\x00\x00\x00\x00\x00\
> x00\x00')
> >
> > I don't why this happened.
>
> Ah, yes sorry. Forgot to tell you that it was broken prior to below commit.
>
> You need:
>
> commit ee551988bcce08ad7a15f71fb9d2239b4239ab08
> Author: Aloys Augustin 
> Date:   Fri Feb 17 14:55:29 2017 +0100
>
> Fix vnet_interface_counters API definition
>
> The api specification had u8 as data type, which caused the python
> binding to fail.
> Fixes VPP-642
>
> Change-Id: I9ba97959740d44c8f4a12db9356d0d1bcd709a73
> Signed-off-by: Aloys Augustin 
> Signed-off-by: Ole Troan 
>
>
> And that changes vnet_interface_counters to a simple and a combined
> counters version.
>
> Sorry, for trickle feeding you information, my brain trashed in the middle
> of the context switch. ;-)
>
> Feel free to put something on the wiki as you go along.
>
> Best regards,
> Ole
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] A few questions regarding mcast fib

[Nagaprabhanjan Bellari]

Thank you! As always, a great answer!

This itself is good enough a documentation to get going. :-)

-nagp

On Tue, Jun 13, 2017 at 4:34 PM, Neale Ranns (nranns) 
wrote:

> Hi nagp,
>
>
>
> VPP does support those scenarios. I’ve not written any documentation
> sadly, so I’ll write some instructions here… When I wrote the mfib/mpls
> code I did little testing via the debug CLI, so some of the options below
> are not be available via the CLI, I’ve put those options is []. I’ll be
> cheeky and leave the implementation as an exercise to the reader…. but see
> test_mpls.py and the test_mcast* functions therein for the various head,
> midpoint and tail programming via the API. There are also examples of how
> to setup the fib_route_path_t for each scenario in [m]fib_test.c.
>
>
>
> IP-to-IP:
>
>
>
> Adding routes to the mfib, and adding replications for those routes, is
> similar to adding ECMP paths to routes in the unicast-fib (they even share
> the sme fib_path[_list] code).
>
> The prefix in the mFIB can be:
>
> 1)(*,G/m)
>
> ip mroute add 232.1.0.0/16 via Eth0 Forward
>
> 2)   (*,G)
>
> ip mroute add 232.1.1.1 via Eth0 Forward
>
> 3)   (S,G)
>
>ip mroute add 1.1.1.1 239.1.1.1 via Eth0 Forward
>
>
>
> adding more replications is achieved by adding more paths:
>
> ip mroute add 1.1.1.1 239.1.1.1 via Eth1 Forward
>
> ip mroute add 1.1.1.1 239.1.1.1 via Eth2 Forward
>
> ip mroute add 1.1.1.1 239.1.1.1 via Eth3 Forward
>
>
>
> You’ll note the path is “attached”, i.e. only the interface is given and
> not the next-hop. For mcast routes this is the expected case. The path will
> resolve via the special multicast adjacency on the interface, which will
> perform the MAC address fixup at switch time. If you want to specify a
> next-hop in the path, and so have a unicast MAC address applied, then
> you’ll need: https://gerrit.fd.io/r/#/c/6974/
>
>
>
> The flag ‘Forward’ is required to specify this is as a replication, i.e. a
> path used for forwarding. This distinction is required because for
> multicast one must also specify the RPF constraints. RPF can be specified
> in several ways:
>
> 1)   a particular [set of] interfaces;
>
>   ip mroute add 1.1.1.1 239.1.1.1 via Eth10 Accept
>
> 2)   An RPF-ID (more on this later). No CLI for this
>
> 3)   Accept from any interface – this can be thought of as an RPF
> ‘don’t care’ – there are no loops, I personally guarantee it :/
>
>ip mroute 1.1.1.1 239.1.1.1 AA
>
> the AA stands for accept-any-interface – it is a property of the mFIB
> entry, not one of its paths
>
>
>
> At this point we do not support PIM register tunnels.
>
>
>
> IP-to-MPLS: the head-end
>
>
>
> VPP supports point-2-multi-point (P2MP) MPLS tunnels (the sort of tunnels
> that one gets via e.g. RSVP P2MP-TE) and P2MP LSPs (e.g. those one gets
> from mLDP) – the difference is essentially the presence (for the former)
> and lack of (for the latter) an interface associated with the LSP.
>
>
>
> At the head end one has choices:
>
> 1)   Add replications to the mroute over multiple unicast tunnels,
> e.g.
>
> ip mroute add 1.1.1.1 239.1.1.1 via mpls-tunnel1 Forward
>
> ip mroute add 1.1.1.1 239.1.1.1 via mpls-tunnel2 Forward
>
> ip mroute add 1.1.1.1 239.1.1.1 via mpls-tunnel3 Forward
>
> but note that we do not support having an ‘out-label’ specification here,
> hence the tunnels must be dedicated to the mroute – which is not so
> scalable.
>
> 2)   Define one MPLS P2MP tunnel with replications
>
>   mpls tunnel [multicast] add via 10.10.10.10 Eth0 out-label 55
>
>   mpls tunnel  add via 11.11.11.11 Eth1 out-label 66
>
> and then point the mroute via this tunnel
>
>   ip mroute 1.1.1.1 239.1.1.1 via mpls-tunnelXXX Forward
>
> the tunnel can be shared or dedicated to the mroute (i.e. a default or
> data MDT).
>
>
>
> option 2 is the typical/recommended way, since it reflects the control
> plane model; BGP gives paths via the core-tress (i.e. replications for the
> mroute via tunnels) and mLDP/RSVP-TE builds the LSPs (add/removes
> replications for the P2MP MPLS tunnel).
>
>
>
> If there are also IP replications to make, then combinations can be used,
> e.g.;
>
> ip mroute 1.1.1.1 239.1.1.1 via mpls-tunnelXXX
>
> ip mroute 1.1.1.1 239.1.1.1 via Eth0 Forward
>
> 2-stage replication; first via all tunnels and all attached peers, then
> via each next-hop in the tunnel.
>
>
>
>
>
> MPLS-to-MPLS: the mid-point.
>
>
>
>
>
> At the mid-point we build MPLS entries that perform replication:
>
>mpls local-label [multicast] 33 eos via 10.10.10.10 eth0 out-label 77
>
>mpls local-label [multicast] 33 eos via 11.11.11.11 eth1 out-label 77
>
> each path is unicast. i.e. the packet is sent out with a unicast MAC to
> the peer in the path, consequently RPF is necessary.
>
>
>
> MPLS-to-IP: the tail
>
>
>
>
>
> The use of upstream assigned labels has not been tested, though it could
> easily be made to work I think, but let’s discount this use-case as it’s

Re: [vpp-dev] How to get interface stats using python api?

[Weitao Han]

I will try the latest version of vpp.
Thank you very much!

WT Han


2017-06-13 18:56 GMT+08:00 :

> Hi again,
>
> > I tried the method you told me, but the data that I got is '\x00'.
> >
> > Like this, vnet_interface_counters(_0=49, vnet_counter_type=1,
> is_combined=1, first_sw_if_index=0, count=7, data='\x00\x00\x00\x00\x00\
> x00\x00')
> >
> > I don't why this happened.
>
> Ah, yes sorry. Forgot to tell you that it was broken prior to below commit.
>
> You need:
>
> commit ee551988bcce08ad7a15f71fb9d2239b4239ab08
> Author: Aloys Augustin 
> Date:   Fri Feb 17 14:55:29 2017 +0100
>
> Fix vnet_interface_counters API definition
>
> The api specification had u8 as data type, which caused the python
> binding to fail.
> Fixes VPP-642
>
> Change-Id: I9ba97959740d44c8f4a12db9356d0d1bcd709a73
> Signed-off-by: Aloys Augustin 
> Signed-off-by: Ole Troan 
>
>
> And that changes vnet_interface_counters to a simple and a combined
> counters version.
>
> Sorry, for trickle feeding you information, my brain trashed in the middle
> of the context switch. ;-)
>
> Feel free to put something on the wiki as you go along.
>
> Best regards,
> Ole
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] A few questions regarding mcast fib

[Neale Ranns (nranns)]

Hi nagp,

VPP does support those scenarios. I’ve not written any documentation sadly, so 
I’ll write some instructions here… When I wrote the mfib/mpls code I did little 
testing via the debug CLI, so some of the options below are not be available 
via the CLI, I’ve put those options is []. I’ll be cheeky and leave the 
implementation as an exercise to the reader…. but see test_mpls.py and the 
test_mcast* functions therein for the various head, midpoint and tail 
programming via the API. There are also examples of how to setup the 
fib_route_path_t for each scenario in [m]fib_test.c.

IP-to-IP:

Adding routes to the mfib, and adding replications for those routes, is similar 
to adding ECMP paths to routes in the unicast-fib (they even share the sme 
fib_path[_list] code).
The prefix in the mFIB can be:

1)(*,G/m)
ip mroute add 232.1.0.0/16 via Eth0 Forward

2)   (*,G)

ip mroute add 232.1.1.1 via Eth0 Forward

3)   (S,G)

   ip mroute add 1.1.1.1 239.1.1.1 via Eth0 Forward

adding more replications is achieved by adding more paths:

ip mroute add 1.1.1.1 239.1.1.1 via Eth1 Forward

ip mroute add 1.1.1.1 239.1.1.1 via Eth2 Forward

ip mroute add 1.1.1.1 239.1.1.1 via Eth3 Forward

You’ll note the path is “attached”, i.e. only the interface is given and not 
the next-hop. For mcast routes this is the expected case. The path will resolve 
via the special multicast adjacency on the interface, which will perform the 
MAC address fixup at switch time. If you want to specify a next-hop in the 
path, and so have a unicast MAC address applied, then you’ll need: 
https://gerrit.fd.io/r/#/c/6974/

The flag ‘Forward’ is required to specify this is as a replication, i.e. a path 
used for forwarding. This distinction is required because for multicast one 
must also specify the RPF constraints. RPF can be specified in several ways:

1)   a particular [set of] interfaces;

  ip mroute add 1.1.1.1 239.1.1.1 via Eth10 Accept

2)   An RPF-ID (more on this later). No CLI for this

3)   Accept from any interface – this can be thought of as an RPF ‘don’t 
care’ – there are no loops, I personally guarantee it :/
   ip mroute 1.1.1.1 239.1.1.1 AA
the AA stands for accept-any-interface – it is a property of the mFIB entry, 
not one of its paths

At this point we do not support PIM register tunnels.

IP-to-MPLS: the head-end

VPP supports point-2-multi-point (P2MP) MPLS tunnels (the sort of tunnels that 
one gets via e.g. RSVP P2MP-TE) and P2MP LSPs (e.g. those one gets from mLDP) – 
the difference is essentially the presence (for the former) and lack of (for 
the latter) an interface associated with the LSP.

At the head end one has choices:

1)   Add replications to the mroute over multiple unicast tunnels, e.g.

ip mroute add 1.1.1.1 239.1.1.1 via mpls-tunnel1 Forward

ip mroute add 1.1.1.1 239.1.1.1 via mpls-tunnel2 Forward

ip mroute add 1.1.1.1 239.1.1.1 via mpls-tunnel3 Forward

but note that we do not support having an ‘out-label’ specification here, hence 
the tunnels must be dedicated to the mroute – which is not so scalable.

2)   Define one MPLS P2MP tunnel with replications
  mpls tunnel [multicast] add via 10.10.10.10 Eth0 out-label 55
  mpls tunnel  add via 11.11.11.11 Eth1 out-label 66
and then point the mroute via this tunnel
  ip mroute 1.1.1.1 239.1.1.1 via mpls-tunnelXXX Forward
the tunnel can be shared or dedicated to the mroute (i.e. a default or data 
MDT).

option 2 is the typical/recommended way, since it reflects the control plane 
model; BGP gives paths via the core-tress (i.e. replications for the mroute via 
tunnels) and mLDP/RSVP-TE builds the LSPs (add/removes replications for the 
P2MP MPLS tunnel).

If there are also IP replications to make, then combinations can be used, e.g.;
ip mroute 1.1.1.1 239.1.1.1 via mpls-tunnelXXX
ip mroute 1.1.1.1 239.1.1.1 via Eth0 Forward
2-stage replication; first via all tunnels and all attached peers, then via 
each next-hop in the tunnel.


MPLS-to-MPLS: the mid-point.


At the mid-point we build MPLS entries that perform replication:
   mpls local-label [multicast] 33 eos via 10.10.10.10 eth0 out-label 77
   mpls local-label [multicast] 33 eos via 11.11.11.11 eth1 out-label 77
each path is unicast. i.e. the packet is sent out with a unicast MAC to the 
peer in the path, consequently RPF is necessary.

MPLS-to-IP: the tail


The use of upstream assigned labels has not been tested, though it could easily 
be made to work I think, but let’s discount this use-case as it’s rarely, if 
ever, used. Consequently, any VRF context must be recovered from the transport 
LSP – i.e. P2MP LSPs cannot PHP.

At the tail, we then need to extract two pieces of information from the label 
the packet arrives with; firstly, the VRF and secondly the RPF information. For 
an LSP with an associated interface (i.e. RSVP-TE) this is easier, since the 
interface is bound to a VRF and the mroutes in that VRF can have RPF 
constraints

Re: [vpp-dev] How to get interface stats using python api?

[otroan]

Hi again,

> I tried the method you told me, but the data that I got is '\x00'.
> 
> Like this, vnet_interface_counters(_0=49, vnet_counter_type=1, is_combined=1, 
> first_sw_if_index=0, count=7, data='\x00\x00\x00\x00\x00\x00\x00')
> 
> I don't why this happened.

Ah, yes sorry. Forgot to tell you that it was broken prior to below commit.

You need:

commit ee551988bcce08ad7a15f71fb9d2239b4239ab08
Author: Aloys Augustin 
Date:   Fri Feb 17 14:55:29 2017 +0100

Fix vnet_interface_counters API definition

The api specification had u8 as data type, which caused the python
binding to fail.
Fixes VPP-642

Change-Id: I9ba97959740d44c8f4a12db9356d0d1bcd709a73
Signed-off-by: Aloys Augustin 
Signed-off-by: Ole Troan 


And that changes vnet_interface_counters to a simple and a combined counters 
version.

Sorry, for trickle feeding you information, my brain trashed in the middle of 
the context switch. ;-)

Feel free to put something on the wiki as you go along.

Best regards,
Ole


signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] How to get interface stats using python api?

[Weitao Han]

Dear Ole

I tried the method you told me, but the data that I got is '\x00'.

Like this, vnet_interface_counters(_0=49, vnet_counter_type=1,
is_combined=1, first_sw_if_index=0, count=7,
data='\x00\x00\x00\x00\x00\x00\x00')

I don't why this happened.

Thanks
WT Han


2017-06-13 18:02 GMT+08:00 :

> Hello,
>
> > How to get interface stats using python api?
> > For example, I want to know "GigabitEthernete/0/1" rx packets, what
> shoud I do?
>
> You register for stats with the want_stats call.
> Before that you must register an event handler with
> VPP.register_event_callback
>
> Then that callback will be called periodically with the stats messages.
> VL_API_VNET_INTERFACE_COUNTERS, VL_API_VNET_IP6_FIB_COUNTERS and
> VL_API_VNET_IP4_FIB_COUNTERS if I remember correctly.
>
> Ping me if you need more help.
>
> Cheers,
> Ole
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] How to get interface stats using python api?

[otroan]

Hello,

> How to get interface stats using python api?
> For example, I want to know "GigabitEthernete/0/1" rx packets, what shoud I 
> do?

You register for stats with the want_stats call.
Before that you must register an event handler with VPP.register_event_callback

Then that callback will be called periodically with the stats messages.
VL_API_VNET_INTERFACE_COUNTERS, VL_API_VNET_IP6_FIB_COUNTERS and 
VL_API_VNET_IP4_FIB_COUNTERS if I remember correctly.

Ping me if you need more help.

Cheers,
Ole


signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] How to get interface stats using python api?

[Weitao Han]

Hi!

How to get interface stats using python api?
For example, I want to know "GigabitEthernete/0/1" rx packets, what shoud I
do?

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

Re: [vpp-dev] vpp ip6 fib

[Pragash Vijayaragavan]

Thanks for the help Neale, works fine now.

Thanks,

Pragash Vijayaragavan
Grad Student at Rochester Institute of Technology
email : pxv3...@rit.edu
ph : 585 764 4662


On Tue, Jun 13, 2017 at 3:40 AM, Neale Ranns (nranns) 
wrote:

> Hi Pragash,
>
>
>
> To update table[FWD] we use the ip6_fib_table_fwding* functions.
>
> Tp update table[NON_FWD] we use the ip6_fb_table_entry_* functions.
>
>
>
> In both cases the key is the prefix (a/x in your example). In table[FWD]
> the value is the index of the load-balance object, in table[NON-FWD] the
> value is the index of the fib_entry_t.
>
>
>
> If you add this route;
>
>   Ip route add a/x via b.
>
>
>
> You’ll first see additions to both tables for b/128 and then additions for
> a/x.
>
>
>
> Hth,
>
> neale
>
>
>
> *From: *Pragash Vijayaragavan 
> *Reply-To: *"pxv3...@rit.edu" 
> *Date: *Tuesday, 13 June 2017 at 07:26
> *To: *"Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" <
> vpp-dev@lists.fd.io>
> *Cc: *Minseok Kwon , Shailesh Vajpayee 
> *Subject: *vpp ip6 fib
>
>
>
> Hi,
>
>
>
> Can someone please help me on below,
>
>
>
> when i insert a route using "ip route add  via "
>
>
>
> how does the fib insert this in its table[FWD, NON_FWD], -> does it call
> different functions for forwarding and nonforwarding ip6_addresses?
>
>
>
> I have inserted a cuckoo_add code on "ip6_fib_table_fwding_dpo_update"
> function,
>
> but only the  ip is getting inserted into my cuckoo filter always.
>
>
>
> Which function does a/x call to insert into the fib?,
>
>
>
> i also tried a cuckoo_add inside "ip6_fib_table_entry_insert"
>
> but this didnt work as well.
>
>
>
> I came across this when i made a CLI to display my cuckoo filter, and im
> pretty sure there is
>
> nothing wrong with the cli.
>
>
>
>
> Thanks,
>
>
>
> Pragash Vijayaragavan
>
> Grad Student at Rochester Institute of Technology
>
> email : pxv3...@rit.edu
>
> ph : 585 764 4662 <(585)%20764-4662>
>
>
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vpp ip6 fib

[Neale Ranns (nranns)]

Hi Pragash,

To update table[FWD] we use the ip6_fib_table_fwding* functions.
Tp update table[NON_FWD] we use the ip6_fb_table_entry_* functions.

In both cases the key is the prefix (a/x in your example). In table[FWD] the 
value is the index of the load-balance object, in table[NON-FWD] the value is 
the index of the fib_entry_t.

If you add this route;
  Ip route add a/x via b.

You’ll first see additions to both tables for b/128 and then additions for a/x.

Hth,
neale

From: Pragash Vijayaragavan 
Reply-To: "pxv3...@rit.edu" 
Date: Tuesday, 13 June 2017 at 07:26
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Cc: Minseok Kwon , Shailesh Vajpayee 
Subject: vpp ip6 fib

Hi,

Can someone please help me on below,

when i insert a route using "ip route add  via "

how does the fib insert this in its table[FWD, NON_FWD], -> does it call 
different functions for forwarding and nonforwarding ip6_addresses?

I have inserted a cuckoo_add code on "ip6_fib_table_fwding_dpo_update" function,
but only the  ip is getting inserted into my cuckoo filter always.

Which function does a/x call to insert into the fib?,

i also tried a cuckoo_add inside "ip6_fib_table_entry_insert"
but this didnt work as well.

I came across this when i made a CLI to display my cuckoo filter, and im pretty 
sure there is
nothing wrong with the cli.


Thanks,

Pragash Vijayaragavan
Grad Student at Rochester Institute of Technology
email : pxv3...@rit.edu
ph : 585 764 4662

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

[vpp-dev] Questions about IKEV2

[薛欣颖]

Hi guys,

I'm testing IKEV2.  When I set VPP up as an active negotiation. There is no 
actively initiate negotiation after command configuration.
Has anyone ever seen this appearance?

Thanks,
xyxue





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