[Edited Message Follows]
Thanks Jim, tried this before with no luck. I'm still not seeing packets coming
through to the other end.
vpp# set interface l2 bridge TenGigabitEthernet1/0/1 100
vpp# set interface l2 bridge TenGigabitEthernet1/0/0 100
vpp# set interface state TenGigabitEthernet1/0/1
Thanks Jim, tried this before with no luck. I'm still not seeing packets coming
through to the other end.
vpp# set interface l2 bridge TenGigabitEthernet1/0/1 100
vpp# set interface l2 bridge TenGigabitEthernet1/0/0 100
vpp# set interface state TenGigabitEthernet1/0/1 up
vpp# set interface state
https://wiki.fd.io/view/VPP/Command-line_Interface_(CLI)_Guide#set_interface
vpp# set interface l2 bridge TenGigabitEthernet0/8/0 100
vpp# set interface l2 bridge TenGigabitEthernet0/9/0 100
vpp# set interface state TenGigabitEthernet0/8/0 up
vpp# set interface state TenGigabitEthernet0/9/0 up
[Edited Message Follows]
Working with VPP for the first time and looking for some advice with initial
setup.
Looking to have VPP act like a passive device that simply forwards all of the
packets through it from NICA > NICB. Currently it will only forward packets for
IPs in the same subnets
Working with VPP for the first time and looking for some advice with initial
setup.
Looking to have VPP act like a passive device that simply forwards all of the
packets through it from NICA > NICB. Currently it will only forward packets for
IPs in the same subnets configured in the NICs, what
Hi Berk,
As per previous email mentioned:
“tap_cli code we don't want to test. as it is going to be deprecated in favour
of tapv2.
Code is not done yet just because people were ignoring requests to move to the
new code (inc. VIRL).”
I suggest you leverage tapv2, and also need some rework for
Hello,
I have a tap interface connected to a noisy LAN and I found that a certain type
of IGMP packet will sometimes cause a crash (backtrace at the end) in
ip4_fib_mtrie_lookup_step_one(). More specifically its an IGMP packet with the
router alert IP option. Here's a packet trace:
I have no idea what you are trying to do with PPPoE. From an L2 forwarding
point of view, however, you need to put interfaces into the same bridge domain
(BD) so they can forward packets to each other. If you have only two
interfaces to send packets to each other, you can L2 cross connect
Switching to l2 mode with bridge-domain gives another trace, but anyway frame
is not going to pppoe_cp_dispatch.
02:02:10:942877: tapcli-rx
tapcli-0
02:02:10:942881: ethernet-input
PPPOE_DISCOVERY: 2e:0d:e3:67:3e:bf -> 52:54:00:ea:ca:a5
02:02:10:942882: l2-input
l2-input: sw_if_index 3 dst
Hi Jeff,
It was not intentional. The commit you mentioned was addressing tunnel
implementations in VPP which uses similar encap/decap approach with
vnet/src/vxlan as the model or “template”. L2TP uses different encap/decap
approach so was not included.
With respect to the dummy tx function,
Regarding this commit:
https://git.fd.io/vpp/commit/?id=e5453d0fa29f39a7f78a7e22815566a7f4c9e5ef
I noticed that L2TP still has its dummy interface tx function and is not
mentioned in the commit message. Wanted to check if this was intentional or
not.
Thanks,
Jeff
-=-=-=-=-=-=-=-=-=-=-=-
Hello,
Just wanted to bring attention to what I believe are two issues with the
tx_burst_vector_internal() function in src/plugins/dpdk/device/device.c
1) The first concerns this if statement:
if (PREDICT_FALSE (n_sent < 0))
Where n_sent is set by:
n_sent = rte_ring_sp_enqueue_burst(...);
or
The interface is in L3 mode. Thus, VPP will only allow packets whose
destination MAC is the same as the interface MAC or bcast/mcast MAC. The
error “l3 mac mismatch” means the DMAC here “52:54:00:ea:ca:a5“ is not the same
as the MAC of the interface. -John
From:
Dear Emma,
Thanks again for reporting this. Please give a shot to
https://gerrit.fd.io/r/#/c/15309/, that should fix the issue.
Also if you could share the workflow that you are using these ACLs in,
would be cool! Or are they more just for fuzz testing? thank you!
--a
On 10/16/18, emma sdi
Hi
I am working on QoS with VPP. I think that know how to configure HQoS to
determine pkt's TC and QUEUE.
Can i determin the DSCP value that is equivalent to traffic class X and
queue Y?
set dpdk interface hqos tctbl entry tc queue
If yes, my main question is that, how can i decide in PE
hi emma,
thank you for reaching out. I can reproduce this locally, let me take
a look at it and come back to you.
--a
On 10/16/18, emma sdi wrote:
> Dear vpp,
> I tried to define specific acls and add them to interfaces via vpp_api_test
> in master branch. When the case was adding interface to
Sorry, PADO came from tap trace, but anyway i not understand reason of drop.
00:10:24:106524: tapcli-rx
tapcli-0
00:10:24:106529: ethernet-input
PPPOE_DISCOVERY: ae:24:05:0d:4c:e9 -> 52:54:00:ea:ca:a5
00:10:24:106531: error-drop
ethernet-input: l3 mac mismatch
-=-=-=-=-=-=-=-=-=-=-=-
Links:
Dear all,
Please, take a moment to either fix or dismiss (in coverity) the warnings
highlighted by the tool.
There are currently 7 outstanding difects; the affected areas are:
* plugins/memif/device.c
* vnet/vxlan-gpe/encap.c
* plugins/nsh/nsh.c
* vppinfra/linux/mem.c
When fixing any of the
Dear vpp,
I tried to define specific acls and add them to interfaces via vpp_api_test
in master branch. When the case was adding interface to an acl, vpp
crahed.
In this test, I added my vpp_api_test commands in file named as
"vat-commands". My startup.conf and "vat-commands"files are as
Hi all,
I am facing an occasional VPP crash when running CLIs ( show node
counters) whilst under load.
I am using VPP version v18.01.1-100~g3a6948c. Upgrading to a newer version
is not an option for me currently.
VPP cores out of 'unix_cli_read_ready'
Here is the BT:
*(gdb) bt*
*#0
20 matches
Mail list logo
