Re: [vpp-dev] NAT44 and rate limiting
I used John's exact setup. I added policer to loop5 and lan0 configure policer name policy2 type 1r2c cir 500 cb 5000 rate kbps conform-action transmit exceed-action drop classify table mask l3 ip4 src classify session policer-hit-next policy2 table-index 0 match l3 ip4 src 10.8.200.2 set policer classify interface loop5 ip4-table 0 set policer classify interface lan0 ip4-table 20 sh int loop5 features loop5 ip4-unicast: nat44-in2out ip4-policer-classify sh int lan0 features lan0 ip4-unicast: ip4-not-enabled ip4-policer-classify "sh classify tables verbose" shows table has been added. "show classify policer type ip4" shows table has been added to loop5 and lan0. As you can see below it's ethernet-input l2-input l2-learn l2-fwd ip4-input nat44-in2out ip4-lookup ip4-policer-classify is not present after nat44-in2out. Packet 1 1:23:06:454709: dpdk-input lan0 rx queue 0 buffer 0xb3cf: current data 0, length 60, free-list 0, clone-count 0, totlen-nifb 0, trace 0x2 ext-hdr-valid l4-cksum-computed l4-cksum-correct PKT MBUF: port 3, nb_segs 1, pkt_len 60 buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr 0xe96cf440 packet_type 0x111 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 rss 0x0 fdir.hi 0x0 fdir.lo 0x0 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 Packet Types RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers RTE_PTYPE_L4_TCP (0x0100) TCP packet IP4: ac:2e:33:1f:cc:3e -> ee:af:33:00:00:11 TCP: 10.155.6.109 -> 10.8.200.1 tos 0x00, ttl 128, length 40, checksum 0x3811 fragment id 0xdfad, flags DONT_FRAGMENT TCP: 49727 -> 5201 seq. 0x34aa7da4 ack 0x4578b6ae flags 0x10 ACK, tcp header: 20 bytes window 53248, checksum 0x77bc 01:23:06:454710: ethernet-input frame: flags 0x3, hw-if-index 4, sw-if-index 4 IP4: ac:2e:33:1f:cc:3e -> ee:af:33:00:00:11 01:23:06:454711: l2-input l2-input: sw_if_index 4 dst ee:af:33:00:00:11 src ac:2e:33:1f:cc:3e 01:23:06:454712: l2-learn l2-learn: sw_if_index 4 dst ee:af:33:00:00:11 src ac:2e:33:1f:cc:3e bd_index 1 01:23:06:454712: l2-fwd l2-fwd: sw_if_index 4 dst ee:af:33:00:00:11 src ac:2e:33:1f:cc:3e bd_index 1 result [0x70007, 7] static age-not bvi 01:23:06:454713: ip4-input TCP: 10.155.6.109 -> 10.8.200.1 tos 0x00, ttl 128, length 40, checksum 0x3811 fragment id 0xdfad, flags DONT_FRAGMENT TCP: 49727 -> 5201 seq. 0x34aa7da4 ack 0x4578b6ae flags 0x10 ACK, tcp header: 20 bytes window 53248, checksum 0x77bc 01:23:06:454713: nat44-in2out NAT44_IN2OUT_FAST_PATH: sw_if_index 7, next index 0, session 22 01:23:06:454714: ip4-lookup fib 0 dpo-idx 1 flow hash: 0x TCP: 10.8.200.2 -> 10.8.200.1 tos 0x00, ttl 128, length 40, checksum 0x770e fragment id 0xdfad, flags DONT_FRAGMENT TCP: 26849 -> 5201 seq. 0x34aa7da4 ack 0x4578b6ae flags 0x10 ACK, tcp header: 20 bytes window 53248, checksum 0x1018 01:23:06:454715: ip4-rewrite tx_sw_if_index 6 dpo-idx 1 : ipv4 via 10.8.200.1 wan0: mtu:9000 a0369f9be2e2083571eb70550800 flow hash: 0x : a0369f9be2e2083571eb705508004528dfad40007f06780e0a08c8020a08 0020: c80168e1145134aa7da44578b6ae5010d0001018 01:23:06:454716: wan0-output wan0 IP4: a2:12:53:ac:bf:3b -> 2b:dd:3e:22:ae:2e TCP: 10.8.200.2 -> 10.8.200.1 tos 0x00, ttl 127, length 40, checksum 0x780e fragment id 0xdfad, flags DONT_FRAGMENT TCP: 26849 -> 5201 seq. 0x34aa7da4 ack 0x4578b6ae flags 0x10 ACK, tcp header: 20 bytes window 53248, checksum 0x1018 01:23:06:454716: wan0-tx wan0 tx queue 1 buffer 0xb3cf: current data 0, length 60, free-list 0, clone-count 0, totlen-nifb 0, trace 0x2 ext-hdr-valid l4-cksum-computed l4-cksum-correct natted l2-hdr-offset 0 l3-hdr-offset 14 PKT MBUF: port 3, nb_segs 1, pkt_len 60 buf_len 2176, data_len 60, ol_flags 0x180, data_off 128, phys_addr 0xe96cf440 packet_type 0x111 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 rss 0x0 fdir.hi 0x0 fdir.lo 0x0 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 Packet Types RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers RTE_PTYPE_L4_TCP (0x0100) TCP packet IP4: a2:12:53:ac:bf:3b -> 2b:dd:3e:22:ae:2e TCP: 10.8.200.2 -> 10.8.200.1 tos 0x00, ttl 127, length 40, checksum 0x780e fragment id 0xdfad, flags DONT_FRAGMENT TCP: 26849 -> 5201 seq. 0x34aa7da4 ack 0x4578b6ae flags 0x10 ACK, tcp header: 20 bytes window 53248, checksum 0x1018 Cheers On Thu, Apr 18, 2019 at 9:12 PM carlito nueno via Lists.Fd.Io wrote: > > John, > > from
Re: [vpp-dev] NAT44 and rate limiting
John, from your packet trace: 00:01:47:426336: ip4-input-no-checksum TCP: 10.8.200.1 -> 10.8.200.2 tos 0x00, ttl 64, length 52, checksum 0x96b0 fragment id 0x, flags DONT_FRAGMENT TCP: 80 -> 18995 seq. 0x732f1a24 ack 0x702b5a27 flags 0x12 SYN ACK, tcp header: 32 bytes window 29200, checksum 0xb6b3 00:01:47:426337: nat44-out2in NAT44_OUT2IN: sw_if_index 6, next index 1, session index 1 You can't use src 10.8.200.2 because packets entering wan0 are out to in, hence nat44_out2in, will have src of 10.8.200.1. Packets before nat44_out2in will have dst of 10.8.200.2. Hence your policer session will not work. from your packet trace: 00:01:47:426338: loop5-output loop5 IP4: de:ad:00:00:00:05 -> c0:56:27:90:3f:fc TCP: 10.8.200.1 -> 10.155.6.109 tos 0x00, ttl 63, length 52, checksum 0x58b3 fragment id 0x, flags DONT_FRAGMENT TCP: 80 -> 50051 Again, l2 src 08:25:a1:cb:40:55 won't work because packets after NAT are leaving out of loop5 with src de:ad:00:00:00:05. My hunch is this might work: classify session policer-hit-next policy1 table-index 1 match l2 src de:ad:00:00:00:05 set policer classify interface loop5 l2-table 1 Hope this helps. On Tue, Apr 16, 2019 at 8:28 PM John Pearson wrote: > > Hi all, > > I am using NAT44 and am trying to limit upload and download bandwidth > separately on wan0. > > setup: > file server <--> [wan0] VPP [loop5] <--> client > > Info: > file server > ip address: 10.8.200.1 > mac: a0:36:9f:9b:e2:e2 > > wan0 > ip addr: 10.8.200.2 > gateway: 10.8.200.1 > mac: 08:25:a1:cb:40:55 > > loop5 > ip addr: 10.155.6.1 > mac: de:ad:00:00:00:05 > > client > ip addr: 10.155.6.109 > mac: c0:56:27:90:3f:fc > > vpp.conf > > set int state wan0 up > set int ip address wan0 10.8.200.2/24 > ip route add 0.0.0.0/0 via 10.8.200.1 > > set int state lan0 up > > create loopback interface instance 5 > set int l2 bridge loop5 5 bvi > set int ip address loop5 10.155.6.1/24 > set int state loop5 up > set int l2 bridge lan0 5 > > nat44 add interface address wan0 > set interface nat44 in loop5 out wan0 > > Packet trace of 2 packets: https://pastebin.com/PZLMpG1i > > What I tried: > > configure policer name policy1 type 1r2c cir 500 cb 5000 rate kbps > conform-action transmit exceed-action drop > classify table mask l3 ip4 src > classify session policer-hit-next policy1 table-index 0 match l3 ip4 src > 10.8.200.2 > set policer classify interface wan0 ip4-table 0 > > - > > configure policer name policy1 type 1r2c cir 500 cb 5000 rate kbps > conform-action transmit exceed-action drop > classify table mask l2 src > classify session policer-hit-next policy1 table-index 1 match l2 src > 08:25:a1:cb:40:55 > set policer classify interface wan0 l2-table 0 > > Please let me know where I am making a mistake. > > Thanks! > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#12802): https://lists.fd.io/g/vpp-dev/message/12802 > Mute This Topic: https://lists.fd.io/mt/31208381/675621 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [carlitonu...@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12820): https://lists.fd.io/g/vpp-dev/message/12820 Mute This Topic: https://lists.fd.io/mt/31208381/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] 6rd
Hi, I would like to configure my VPP instance as a 6rd CPE but I don’t see from the “create 6rd tunnel “ command any option to specify the BR IPv4 address so my container connected behind VPP can reach IPv6 host outside of the 6rd domain. Thanks, Laurent -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12819): https://lists.fd.io/g/vpp-dev/message/12819 Mute This Topic: https://lists.fd.io/mt/31236640/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] sw_interface_dump changes
Hi Matt.
If you look at https://gerrit.fd.io/r/#/c/18693/5/test/vpp_papi_provider.py,
the field was set to default to ~0 for the python client. When I made the
change, I chose to do it this way to make the api fall more in line with
other calls such as l2_interface_efp_filter and
sw_interface_rx_placement_dump.
~0 is the sentinel value typically used for "any" or "all" interfaces.
This change was made more backward compatible in:
https://gerrit.fd.io/r/#/c/18980/.
Paul
On Thu, Apr 18, 2019 at 3:22 PM Matthew Smith wrote:
>
> Hi,
>
> It looks like in https://gerrit.fd.io/r/#/c/18693/ the message format and
> handler for sw_interface_dump changed in a backwards-incompatible way. It's
> not too difficult to correct for, but it seems like any API clients that
> used this call might be broken. Some code that I maintain that connects to
> the binary API broke, and vpp_api_test looks like it did too. I tested with
> a build generated from commit 5a8844b "GRE: API update".
>
> A field was added to the message named sw_if_index, which causes a single
> interface to be dumped. You have to set this to ~0 to receive all
> interfaces, which was the default behavior before. Since clients written
> against earlier versions of the API didn't have to populate this field,
> they are probably passing 0 because the memory was zeroed when it was
> allocated. This has the effect of only receiving the details for
> sw_if_index 0 ("local0") when a sw_interface_dump message is sent in which
> the value of sw_if_index has not been set.
>
> I have adjusted my code to deal with the change but I don't know how many
> other clients of the binary API exist out there that will be broken by
> this. Should backwards compatibility be restored? Or just fix vpp_api_test
> and move on?
>
> -Matt
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#12817): https://lists.fd.io/g/vpp-dev/message/12817
> Mute This Topic: https://lists.fd.io/mt/31234917/1594641
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [
> pvi...@vinciconsulting.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12818): https://lists.fd.io/g/vpp-dev/message/12818
Mute This Topic: https://lists.fd.io/mt/31234917/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] sw_interface_dump changes
Hi,
It looks like in https://gerrit.fd.io/r/#/c/18693/ the message format and
handler for sw_interface_dump changed in a backwards-incompatible way. It's
not too difficult to correct for, but it seems like any API clients that
used this call might be broken. Some code that I maintain that connects to
the binary API broke, and vpp_api_test looks like it did too. I tested with
a build generated from commit 5a8844b "GRE: API update".
A field was added to the message named sw_if_index, which causes a single
interface to be dumped. You have to set this to ~0 to receive all
interfaces, which was the default behavior before. Since clients written
against earlier versions of the API didn't have to populate this field,
they are probably passing 0 because the memory was zeroed when it was
allocated. This has the effect of only receiving the details for
sw_if_index 0 ("local0") when a sw_interface_dump message is sent in which
the value of sw_if_index has not been set.
I have adjusted my code to deal with the change but I don't know how many
other clients of the binary API exist out there that will be broken by
this. Should backwards compatibility be restored? Or just fix vpp_api_test
and move on?
-Matt
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12817): https://lists.fd.io/g/vpp-dev/message/12817
Mute This Topic: https://lists.fd.io/mt/31234917/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Using wildcard-ip4-arp-publisher-process
More info from the want_ip4_arp_events API (see src/vnet/ip/ip.api) where the
mac_ip param in the events will tell the client if the event is for ARP
resolution in L# or MAC/IP info in BDs:
/** \brief Register for IP4 ARP resolution event on receing ARP reply or
MAC/IP info from ARP requests in L2 BDs
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param enable_disable - 1 => register for events, 0 => cancel registration
@param pid - sender's pid
@param ip - exact IP4 address of interested arp resolution event, or
0 to get MAC/IP info from ARP requests in BDs
*/
autoreply define want_ip4_arp_events
{
u32 client_index;
u32 context;
u8 enable_disable;
u32 pid;
vl_api_ip4_address_t ip;
};
/** \brief Tell client about an IP4 ARP resolution event or
MAC/IP info from ARP requests in L2 BDs
@param client_index - opaque cookie to identify the sender
@param ip - the exact ip4 address of interest
@param pid - client pid registered to receive notification
@param sw_if_index - interface which received ARP packet
@param mac - the new mac address
@param mac_ip - 0: ARP resolution event, 1: MAC/IP info from L2 BDs
*/
define ip4_arp_event
{
u32 client_index;
vl_api_ip4_address_t ip;
u32 pid;
u32 sw_if_index;
vl_api_mac_address_t mac;
u8 mac_ip;
};
Regards,
John
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of John Lo (loj) via
Lists.Fd.Io
Sent: Thursday, April 18, 2019 11:30 AM
To: Raj ; vpp-dev
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Using wildcard-ip4-arp-publisher-process
Hi Raj,
The registration for ARP events with specific IP is different to when
registration for a wild card IP.
If a client register for ARP events for a specific IP address, an event will be
sent by VPP to the client when ARP resolution occurred for the specified IP
address in L3 FIB.
If a client register for ARP events for a wild card IP address, an event will
be sent by VPP to client when an ARP request was sent by an interface in a
bridge domain (BD) where the ARP-termination feature is enabled in that BD. It
has nothing to do with ARP resolution but rather an interface in a BD sent an
ARP request or GARP. It is designed for clients to learn MAC and IP of an
interface in a BD which can be useful if these are interfaces for VMs. Again
- these events are generated from a BD for the registered client only if ARP
termination is enabled on a BD. ARP termination is not enabled on BDs by
default.
Hope this helps,
John
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Raj
Sent: Thursday, April 18, 2019 9:38 AM
To: vpp-dev
Subject: [vpp-dev] Using wildcard-ip4-arp-publisher-process
Hi all,
I am trying to get ARP events from VPP and found that there is a
'wildcard-ip4-arp-publisher-process' process which could be used. To use this,
I registered a client using API `vpp.api.want_ip4_arp_events` using 0 as IP
address argument. I could see that registration is happening and
`wc_arp_set_publisher_node` function was getting invoked, as it should.
But the node was not reporting any ARP events to the client. Looking through
the code, the main function in the node, `wc_arp_process (vlib_main_t vm,
vlib_node_runtime_t rt, vlib_frame_t * f)` is not getting invoked.
I also registered another client, using `vpp.api.want_ip4_arp_events` but using
a valid IP addres as IP address in argument. Here I'm able to get the ARP
events in the client process from ip-route-resolver-process, as expected.
I just need to figure out why wildcard-ip4-arp-publisher-process is not
reporting ARP events, though ip-route-resolver-process is doing so.
Thanks and Regards,
Raj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12816): https://lists.fd.io/g/vpp-dev/message/12816
Mute This Topic: https://lists.fd.io/mt/31223473/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Using wildcard-ip4-arp-publisher-process
Hi Raj, The registration for ARP events with specific IP is different to when registration for a wild card IP. If a client register for ARP events for a specific IP address, an event will be sent by VPP to the client when ARP resolution occurred for the specified IP address in L3 FIB. If a client register for ARP events for a wild card IP address, an event will be sent by VPP to client when an ARP request was sent by an interface in a bridge domain (BD) where the ARP-termination feature is enabled in that BD. It has nothing to do with ARP resolution but rather an interface in a BD sent an ARP request or GARP. It is designed for clients to learn MAC and IP of an interface in a BD which can be useful if these are interfaces for VMs. Again - these events are generated from a BD for the registered client only if ARP termination is enabled on a BD. ARP termination is not enabled on BDs by default. Hope this helps, John -Original Message- From: vpp-dev@lists.fd.io On Behalf Of Raj Sent: Thursday, April 18, 2019 9:38 AM To: vpp-dev Subject: [vpp-dev] Using wildcard-ip4-arp-publisher-process Hi all, I am trying to get ARP events from VPP and found that there is a 'wildcard-ip4-arp-publisher-process' process which could be used. To use this, I registered a client using API `vpp.api.want_ip4_arp_events` using 0 as IP address argument. I could see that registration is happening and `wc_arp_set_publisher_node` function was getting invoked, as it should. But the node was not reporting any ARP events to the client. Looking through the code, the main function in the node, `wc_arp_process (vlib_main_t vm, vlib_node_runtime_t rt, vlib_frame_t * f)` is not getting invoked. I also registered another client, using `vpp.api.want_ip4_arp_events` but using a valid IP addres as IP address in argument. Here I'm able to get the ARP events in the client process from ip-route-resolver-process, as expected. I just need to figure out why wildcard-ip4-arp-publisher-process is not reporting ARP events, though ip-route-resolver-process is doing so. Thanks and Regards, Raj -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12815): https://lists.fd.io/g/vpp-dev/message/12815 Mute This Topic: https://lists.fd.io/mt/31223473/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP PPPoE Plugin
Hi Abeeha,
I submitted a patch to gerrt.fd.io to remove output nodes for PPPoE.
https://gerrit.fd.io/r/#/c/18993/
Would you like to try if it fixes your node index out of range issue? I expect
the patch can easily be cherry-picked to 1901.
Regards,
John
From: vpp-dev@lists.fd.io On Behalf Of John Lo (loj) via
Lists.Fd.Io
Sent: Wednesday, April 17, 2019 12:06 PM
To: Abeeha Aqeel ; hongjun...@intel.com;
vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP PPPoE Plugin
Hi Abeeha,
Have you tried the suggestion I made previously in a similar thread to get rid
of the dummy_interface_tx nodes for PPPoE sessions?
diff --git a/src/plugins/pppoe/pppoe.c b/src/plugins/pppoe/pppoe.c
index d73a718..f61926d 100644
--- a/src/plugins/pppoe/pppoe.c
+++ b/src/plugins/pppoe/pppoe.c
@@ -87,7 +87,7 @@ pppoe_interface_admin_up_down (vnet_main_t * vnm, u32
hw_if_index, u32 flags)
VNET_DEVICE_CLASS (pppoe_device_class,static) = {
.name = "PPPoE",
.format_device_name = format_pppoe_name,
- .tx_function = dummy_interface_tx,
+ // .tx_function = dummy_interface_tx,
.admin_up_down_function = pppoe_interface_admin_up_down,
};
/* *INDENT-ON* */
I believe this would prevent creation of TX nodes for PPPoE sessions which are
not used anyway. Then you should not encounter any problem with node index
assert error.
If it does work, please submit this patch via gerrit.fd.io so it can be merged
upstream.
Regards,
John
From: vpp-dev@lists.fd.io
mailto:vpp-dev@lists.fd.io>> On Behalf Of Abeeha Aqeel
Sent: Wednesday, April 17, 2019 8:20 AM
To: hongjun...@intel.com;
vpp-dev@lists.fd.io
Cc: b...@xflowresearch.com
Subject: [vpp-dev] VPP PPPoE Plugin
Dear Hongjun,
(PFA = Please find attached)
Code:
Branch: stable/1901
Patch: PFA: stable_1901_patch.txt
Configuration:
PFA: vpp-startup.conf
Steps for setting up:
PFA: setup_steps.bash
Attempted to make 10,000 connections.
Using API calls from control plane application; to create pppoe sessions
Final output from control plane before VPP crashed:
PFA: no_of_connections.png
VPP log-file:
PFA:vpp.log
Dump from journalctl:
PFA: journal_dump.txt
As you can see from the journalctl output, the code crashes on the Assertion
‘node_index < 2^14’. And as you can see from the patch file included, we
changed the original assertion from ‘less than 2^10’ to ‘less than 2^14’. We
did that, because the original assertion crashes VPP way before even 7,000
connections are connected. (Around 400 connections.)
Regards,
Abeeha Aqeel
From: AbduSami bin Khurram
Sent: Wednesday, April 17, 2019 2:33 PM
To: Abeeha Aqeel
Subject: RE: VPP PPPoE Plugin
Dear Abeeha,
(PFA = Please find attached)
Code:
Branch: stable/1901
Patch: PFA: stable_1901_patch.txt
Configuration:
PFA: vpp-startup.conf
Steps for setting up:
PFA: setup_steps.bash
Attempted to make 10,000 connections.
Using API calls from control plane application; to create pppoe sessions
Final output from control plane before VPP crashed:
PFA: no_of_connections.png
VPP log-file:
PFA:vpp.log
Dump from journalctl:
PFA: journal_dump.txt
As you can see from the journalctl output, the code crashes on the Assertion
‘node_index < 2^14’. And as you can see from the patch file included, we
changed the original assertion from ‘less than 2^10’ to ‘less than 2^14’. We
did that, because the original assertion crashes VPP way before even 7,000
connections are connected. (Around 400 connections.)
Warm Regards,
AbduSami bin Khurram
Software Design Engineer, xFlow Research Pvt. Ltd.
+92-331-5543190
abdusami.khur...@xflowresearch.com
www.xflowresearch.com
From: Ni, Hongjun
Sent: 17 April 2019 13:04
To: Abeeha Aqeel;
vpp-dev@lists.fd.io
Cc: b...@xflowresearch.com
Subject: RE: VPP PPPoE Plugin
Hi Aqeel,
Could you send out the core dump log when VPP crash with 7000 sessions?
Thanks,
Hongjun
From: Abeeha Aqeel [mailto:abeeha.aq...@xflowresearch.com]
Sent: Tuesday, April 16, 2019 8:01 PM
To: Ni, Hongjun mailto:hongjun...@intel.com>>;
vpp-dev@lists.fd.io
Cc: b...@xflowresearch.com
Subject: VPP PPPoE Plugin
Dear Hongjun,
I am trying to create 64000 VPP sessions with the VPP Plugin. VPP is being used
as the forwarding plane while our control plane separately caters the PPPoE
control packets. The VPP is installed on Centos 7 on bare-metal server. The
current implementation of the plugin included in VPP Stable 19.01 is allowing
only 7000 sessions and VPP crashes afterwards.
I tried to add the PPPoE plugin implemented by OpenBRAS
[vpp-dev] Using wildcard-ip4-arp-publisher-process
Hi all, I am trying to get ARP events from VPP and found that there is a 'wildcard-ip4-arp-publisher-process' process which could be used. To use this, I registered a client using API `vpp.api.want_ip4_arp_events` using 0 as IP address argument. I could see that registration is happening and `wc_arp_set_publisher_node` function was getting invoked, as it should. But the node was not reporting any ARP events to the client. Looking through the code, the main function in the node, `wc_arp_process (vlib_main_t vm, vlib_node_runtime_t rt, vlib_frame_t * f)` is not getting invoked. I also registered another client, using `vpp.api.want_ip4_arp_events` but using a valid IP addres as IP address in argument. Here I'm able to get the ARP events in the client process from ip-route-resolver-process, as expected. I just need to figure out why wildcard-ip4-arp-publisher-process is not reporting ARP events, though ip-route-resolver-process is doing so. Thanks and Regards, Raj -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12812): https://lists.fd.io/g/vpp-dev/message/12812 Mute This Topic: https://lists.fd.io/mt/31223473/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
