Re: [vpp-dev] Rx stuck to 0 after a while

[Andrew Yourtchenko]

Dear Rubina,

Thanks for catching and reporting this!

I suspect what might be happening is my recent change of using two
unidirectional sessions in bihash vs. the single one triggered a race,
whereby as the owning worker is deleting the session,
the non-owning worker is trying to update it. That would logically
explain the "BUG: .." line (since you don't change the interfaces nor
moving the traffic around, the 5 tuples should not collide), and as
well the later stop.

To take care of this issue, I think I will split the deletion of the
session in two stages:
1) deactivation of the bihash entries that steer the traffic
2) freeing up the per-worker session structure

and have a little pause time inbetween these two so that the
workers-in-progress could
finish updating the structures.

The below gerrit is the first cut:

https://gerrit.fd.io/r/#/c/12770/

It passes the make test right now but I did not kick its tires too
much yet, will do tomorrow.

You can try this change out in your test setup as well and tell me how it feels.

--a

On 5/28/18, Rubina Bianchi  wrote:
> Hi
>
> I run vpp v18.07-rc0~237-g525c9d0f with only 2 interface in stateful acl
> (permit+reflect) and generated sfr traffic using trex v2.27. My rx will
> become 0 after a short while, about 300 sec in my machine. Here is vpp
> status:
>
> root@MYRB:~# service vpp status
> * vpp.service - vector packet processing engine
>Loaded: loaded (/lib/systemd/system/vpp.service; disabled; vendor preset:
> enabled)
>Active: failed (Result: signal) since Mon 2018-05-28 11:35:03 +0130; 37s
> ago
>   Process: 32838 ExecStopPost=/bin/rm -f /dev/shm/db /dev/shm/global_vm
> /dev/shm/vpe-api (code=exited, status=0/SUCCESS)
>   Process: 31754 ExecStart=/usr/bin/vpp -c /etc/vpp/startup.conf
> (code=killed, signal=ABRT)
>   Process: 31750 ExecStartPre=/sbin/modprobe uio_pci_generic (code=exited,
> status=0/SUCCESS)
>   Process: 31747 ExecStartPre=/bin/rm -f /dev/shm/db /dev/shm/global_vm
> /dev/shm/vpe-api (code=exited, status=0/SUCCESS)
>  Main PID: 31754 (code=killed, signal=ABRT)
>
> May 28 16:32:47 MYRB vnet[31754]: acl_fa_node_fn:210: BUG: session
> LSB16(sw_if_index) and 5-tuple collision!
> May 28 16:35:02 MYRB vnet[31754]: unix_signal_handler:124: received signal
> SIGCONT, PC 0x7f1fb591cac0
> May 28 16:35:02 MYRB vnet[31754]: received SIGTERM, exiting...
> May 28 16:35:02 MYRB systemd[1]: Stopping vector packet processing
> engine...
> May 28 16:35:02 MYRB vnet[31754]: unix_signal_handler:124: received signal
> SIGTERM, PC 0x7f1fb3c40867
> May 28 16:35:03 MYRB vpp[31754]: vlib_worker_thread_barrier_sync_int: worker
> thread deadlock
> May 28 16:35:03 MYRB systemd[1]: vpp.service: Main process exited,
> code=killed, status=6/ABRT
> May 28 16:35:03 MYRB systemd[1]: Stopped vector packet processing engine.
> May 28 16:35:03 MYRB systemd[1]: vpp.service: Unit entered failed state.
> May 28 16:35:03 MYRB systemd[1]: vpp.service: Failed with result 'signal'.
>
> I attach my vpp configs to this email. I also run this test with the same
> config and added 4 interface instead of two. But in this case nothing
> happened to vpp and it was functional for a long time.
>
> Thanks,
> RB
>

-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9433): https://lists.fd.io/g/vpp-dev/message/9433
View All Messages In Topic (2): https://lists.fd.io/g/vpp-dev/topic/20397310
Mute This Topic: https://lists.fd.io/mt/20397310/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] show trace caused "out of memory"

[xulang]

Hi,
Below is part of my startup.conf. 
The default heapsize is 512M, so I set 2G heapsize for 4 CPU cores.
But it does not work, nothing changed, any ideas?






main-core 1
## Set logical CPU core(s) where worker threads are running
corelist-workers 2-3


heapsize { 2G }


Regards



在 2018-05-28 19:10:30，"Kingwel Xie"  写道：


Hi,

 

You should increase heap size. In startup.conf, heapsize 1g or something like 
that.

 

When running in multi-core environment, vpp definitely need more memory, 
because some global variables have to be expanded to have multiple copies – per 
worker thread. F.g., Interface Counters, Error counters …

 

Regards,

Kingwel

 

From:vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of xulang
Sent: Monday, May 28, 2018 6:16 PM
To:vpp-dev@lists.fd.io
Subject: [vpp-dev] show trace caused "out of memory"

 

Hi all,

When we only use one CPU core, the cmd "show trace max 5000" works well.

But it will crash when we use four CPU cores because of "out of memory".

Below are some information, any guides?

 

root@vBRAS:~# cat /proc/meminfo 

MemTotal:4028788 kB

MemFree:  585636 kB

MemAvailable: 949116 kB

Buffers:   22696 kB

Cached:   592600 kB

SwapCached:0 kB

Active:  1773520 kB

Inactive: 118616 kB

Active(anon):1295912 kB

Inactive(anon):45640 kB

Active(file): 477608 kB

Inactive(file):72976 kB

Unevictable:3656 kB

Mlocked:3656 kB

SwapTotal:976380 kB

SwapFree: 976380 kB

Dirty: 0 kB

Writeback: 0 kB

AnonPages:   1280520 kB

Mapped:   112324 kB

Shmem: 62296 kB

Slab:  84456 kB

SReclaimable:  35976 kB

SUnreclaim:48480 kB

KernelStack:5968 kB

PageTables:   267268 kB

NFS_Unstable:  0 kB

Bounce:0 kB

WritebackTmp:  0 kB

CommitLimit: 2466484 kB

Committed_AS:   5368769328 kB

VmallocTotal:   34359738367 kB

VmallocUsed:   0 kB

VmallocChunk:  0 kB

HardwareCorrupted: 0 kB

AnonHugePages:348160 kB

CmaTotal:  0 kB

CmaFree:   0 kB

HugePages_Total: 512

HugePages_Free:  384

HugePages_Rsvd:0

HugePages_Surp:0

Hugepagesize:   2048 kB

DirectMap4k:   96064 kB

DirectMap2M: 3049472 kB

DirectMap1G: 3145728 kB

 

 

0: load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so

0: vlib_pci_bind_to_uio: Skipping PCI device :02:0e.0 as host interface 
ens46 is up

EAL: Detected 4 lcore(s)

EAL: No free hugepages reported in hugepages-1048576kB

EAL: Probing VFIO support...

[New Thread 0x7b0019efa700 (LWP 5207)]

[New Thread 0x7b00196f9700 (LWP 5208)]

[New Thread 0x7b0018ef8700 (LWP 5209)]

EAL: PCI device :02:01.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:06.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:07.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:08.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:09.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0a.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0b.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0c.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0d.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0e.0 on NUMA socket -1

EAL:   Device is blacklisted, not initializing

DPDK physical memory layout:

Segment 0: phys:0x7d40, len:2097152, virt:0x7b001500, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0

Segment 1: phys:0x7d80, len:266338304, virt:0x7affe460, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0

[New Thread 0x7b00186f7700 (LWP 5210)]

/usr/bin/vpp[5202]: dpdk_ipsec_process:241: DPDK Cryptodev support is disabled, 
default to OpenSSL IPsec

/usr/bin/vpp[5202]: dpdk_lib_init:1084: 16384 mbufs allocated but total rx/tx 
ring size is 18432

/usr/bin/vpp[5202]: svm_client_scan_this_region_nolock:1139: /vpe-api: cleanup 
ghost pid 4719

/usr/bin/vpp[5202]: svm_client_scan_this_region_nolock:1139: /global_vm: 
cleanup ghost pid 4719

Thread 1 "vpp_main" received signal SIGABRT, Aborted.

0x7fffef655428 in raise () from /lib/x86_64-linux-gnu/libc.so.6

(gdb) 

(gdb) 

(gdb) 

(gdb) p errno /*there are only 81 opened fd belong to progress VPP*/

$1 = 9

(gdb) bt

#0  0x7fffef655428 in raise () from /lib/x86_64-linux-gnu/libc.so.6

#1  0x7fffef65702a in abort () from /lib/x86_64-linux-gnu/libc.so.6

#2  0x0040724e in os_panic () at 

Re: [vpp-dev] show trace caused "out of memory"

[xulang]

Hi all,
my mistake, it is working.


Regards






在 2018-05-29 09:41:16，"xulang"  写道：

Hi,
Below is part of my startup.conf. 
The default heapsize is 512M, so I set 2G heapsize for 4 CPU cores.
But it does not work, nothing changed, any ideas?






main-core 1
## Set logical CPU core(s) where worker threads are running
corelist-workers 2-3


heapsize { 2G }


Regards



在 2018-05-28 19:10:30，"Kingwel Xie"  写道：


Hi,

 

You should increase heap size. In startup.conf, heapsize 1g or something like 
that.

 

When running in multi-core environment, vpp definitely need more memory, 
because some global variables have to be expanded to have multiple copies – per 
worker thread. F.g., Interface Counters, Error counters …

 

Regards,

Kingwel

 

From:vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of xulang
Sent: Monday, May 28, 2018 6:16 PM
To:vpp-dev@lists.fd.io
Subject: [vpp-dev] show trace caused "out of memory"

 

Hi all,

When we only use one CPU core, the cmd "show trace max 5000" works well.

But it will crash when we use four CPU cores because of "out of memory".

Below are some information, any guides?

 

root@vBRAS:~# cat /proc/meminfo 

MemTotal:4028788 kB

MemFree:  585636 kB

MemAvailable: 949116 kB

Buffers:   22696 kB

Cached:   592600 kB

SwapCached:0 kB

Active:  1773520 kB

Inactive: 118616 kB

Active(anon):1295912 kB

Inactive(anon):45640 kB

Active(file): 477608 kB

Inactive(file):72976 kB

Unevictable:3656 kB

Mlocked:3656 kB

SwapTotal:976380 kB

SwapFree: 976380 kB

Dirty: 0 kB

Writeback: 0 kB

AnonPages:   1280520 kB

Mapped:   112324 kB

Shmem: 62296 kB

Slab:  84456 kB

SReclaimable:  35976 kB

SUnreclaim:48480 kB

KernelStack:5968 kB

PageTables:   267268 kB

NFS_Unstable:  0 kB

Bounce:0 kB

WritebackTmp:  0 kB

CommitLimit: 2466484 kB

Committed_AS:   5368769328 kB

VmallocTotal:   34359738367 kB

VmallocUsed:   0 kB

VmallocChunk:  0 kB

HardwareCorrupted: 0 kB

AnonHugePages:348160 kB

CmaTotal:  0 kB

CmaFree:   0 kB

HugePages_Total: 512

HugePages_Free:  384

HugePages_Rsvd:0

HugePages_Surp:0

Hugepagesize:   2048 kB

DirectMap4k:   96064 kB

DirectMap2M: 3049472 kB

DirectMap1G: 3145728 kB

 

 

0: load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so

0: vlib_pci_bind_to_uio: Skipping PCI device :02:0e.0 as host interface 
ens46 is up

EAL: Detected 4 lcore(s)

EAL: No free hugepages reported in hugepages-1048576kB

EAL: Probing VFIO support...

[New Thread 0x7b0019efa700 (LWP 5207)]

[New Thread 0x7b00196f9700 (LWP 5208)]

[New Thread 0x7b0018ef8700 (LWP 5209)]

EAL: PCI device :02:01.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:06.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:07.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:08.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:09.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0a.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0b.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0c.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0d.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0e.0 on NUMA socket -1

EAL:   Device is blacklisted, not initializing

DPDK physical memory layout:

Segment 0: phys:0x7d40, len:2097152, virt:0x7b001500, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0

Segment 1: phys:0x7d80, len:266338304, virt:0x7affe460, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0

[New Thread 0x7b00186f7700 (LWP 5210)]

/usr/bin/vpp[5202]: dpdk_ipsec_process:241: DPDK Cryptodev support is disabled, 
default to OpenSSL IPsec

/usr/bin/vpp[5202]: dpdk_lib_init:1084: 16384 mbufs allocated but total rx/tx 
ring size is 18432

/usr/bin/vpp[5202]: svm_client_scan_this_region_nolock:1139: /vpe-api: cleanup 
ghost pid 4719

/usr/bin/vpp[5202]: svm_client_scan_this_region_nolock:1139: /global_vm: 
cleanup ghost pid 4719

Thread 1 "vpp_main" received signal SIGABRT, Aborted.

0x7fffef655428 in raise () from /lib/x86_64-linux-gnu/libc.so.6

(gdb) 

(gdb) 

(gdb) 

(gdb) p errno /*there are only 81 opened fd belong to progress VPP*/

$1 = 9

(gdb) bt

#0  0x7fffef655428 in raise () from /lib/x86_64-linux-gnu/libc.so.6

#1  0x7fffef65702a in abort () from /lib/x86_64-linux-gnu/libc.so.6

#2  0x0040724e in os_panic () 

[vpp-dev] show trace caused "out of memory"

[xulang]

Hi all,
When we only use one CPU core, the cmd "show trace max 5000" works well.
But it will crash when we use four CPU cores because of "out of memory".
Below are some information, any guides?


root@vBRAS:~# cat /proc/meminfo 
MemTotal:4028788 kB
MemFree:  585636 kB
MemAvailable: 949116 kB
Buffers:   22696 kB
Cached:   592600 kB
SwapCached:0 kB
Active:  1773520 kB
Inactive: 118616 kB
Active(anon):1295912 kB
Inactive(anon):45640 kB
Active(file): 477608 kB
Inactive(file):72976 kB
Unevictable:3656 kB
Mlocked:3656 kB
SwapTotal:976380 kB
SwapFree: 976380 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages:   1280520 kB
Mapped:   112324 kB
Shmem: 62296 kB
Slab:  84456 kB
SReclaimable:  35976 kB
SUnreclaim:48480 kB
KernelStack:5968 kB
PageTables:   267268 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 2466484 kB
Committed_AS:   5368769328 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HardwareCorrupted: 0 kB
AnonHugePages:348160 kB
CmaTotal:  0 kB
CmaFree:   0 kB
HugePages_Total: 512
HugePages_Free:  384
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:   96064 kB
DirectMap2M: 3049472 kB
DirectMap1G: 3145728 kB




0: load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
0: vlib_pci_bind_to_uio: Skipping PCI device :02:0e.0 as host interface 
ens46 is up
EAL: Detected 4 lcore(s)
EAL: No free hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
[New Thread 0x7b0019efa700 (LWP 5207)]
[New Thread 0x7b00196f9700 (LWP 5208)]
[New Thread 0x7b0018ef8700 (LWP 5209)]
EAL: PCI device :02:01.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:06.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:07.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:08.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:09.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:0a.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:0b.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:0c.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:0d.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:0e.0 on NUMA socket -1
EAL:   Device is blacklisted, not initializing
DPDK physical memory layout:
Segment 0: phys:0x7d40, len:2097152, virt:0x7b001500, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 1: phys:0x7d80, len:266338304, virt:0x7affe460, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0
[New Thread 0x7b00186f7700 (LWP 5210)]
/usr/bin/vpp[5202]: dpdk_ipsec_process:241: DPDK Cryptodev support is disabled, 
default to OpenSSL IPsec
/usr/bin/vpp[5202]: dpdk_lib_init:1084: 16384 mbufs allocated but total rx/tx 
ring size is 18432
/usr/bin/vpp[5202]: svm_client_scan_this_region_nolock:1139: /vpe-api: cleanup 
ghost pid 4719
/usr/bin/vpp[5202]: svm_client_scan_this_region_nolock:1139: /global_vm: 
cleanup ghost pid 4719
Thread 1 "vpp_main" received signal SIGABRT, Aborted.
0x7fffef655428 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) 
(gdb) 
(gdb) 
(gdb) p errno /*there are only 81 opened fd belong to progress VPP*/
$1 = 9
(gdb) bt
#0  0x7fffef655428 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fffef65702a in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x0040724e in os_panic () at 
/home/vbras/new_trunk/VBRASV100R001_new_trunk/vpp1704/build-data/../src/vpp/vnet/main.c:290
#3  0x7fffefe6b49b in clib_mem_alloc_aligned_at_offset 
(os_out_of_memory_on_failure=1, align_offset=, align=4, 
size=18768606)   /*mmap*/
at 
/home/vbras/new_trunk/VBRASV100R001_new_trunk/vpp1704/build-data/../src/vppinfra/mem.h:102
#4  vec_resize_allocate_memory (v=, 
length_increment=length_increment@entry=1, data_bytes=, 
header_bytes=, header_bytes@entry=0, 
data_align=data_align@entry=4)
at 
/home/vbras/new_trunk/VBRASV100R001_new_trunk/vpp1704/build-data/../src/vppinfra/vec.c:84
#5  0x00420f04 in _vec_resize (data_align=, 
header_bytes=, data_bytes=, 
length_increment=, v=)
at 
/home/vbras/new_trunk/VBRASV100R001_new_trunk/vpp1704/build-data/../src/vppinfra/vec.h:142
#6  vl_api_cli_request_t_handler (mp=) at 
/home/vbras/new_trunk/VBRASV100R001_new_trunk/vpp1704/build-data/../src/vpp/api/api.c:1132
#7  0x77bce2e3 in vl_msg_api_handler_with_vm_node (am=0x77dd6160 
, 

Re: [vpp-dev] dot1ad tag

[Mehran Memarnejad]

Does the efp-filter work base on the second tag??
As far as I experiment, I realized that each subinterface recieves packets
with tags equal to their subinterface number, e.g. GigabitEthernet1/0/0.200
will receieves packets with inner tags(802.1q) of 200, which is customer'
vlan tag.
I think that I should not consider customer's 802.1q tag in PE.

On Monday, May 28, 2018, Mehran Memarnejad  wrote:

> Hi,
> According to Wikipedia's page for 802.1ad:
>
> "A tag stack creates a mechanism for Internet Service Providers
>  to
> encapsulate customer single-tagged 802.1Q traffic with a single tag, the
> final frame being a QinQ frame. The outer tag is used to identify and
> segregate traffic from different customers; the inner tag is preserved from
> the original frame."
>
> Here I want to add the second tag to segregate customer's traffic. In
> other words, I want to consider each customer in PEs as if it is a vlan.
> So their traffic is isolated from each other, even though they are both
> connected to the same VPP's bridge.
> I think that to segregate customer's traffic, we can use:
> 1- Different VPP bridges for each customer
> 2- Use second tag (802.1ad tag) to differentiate customers when they are
> connected to the same VPP bridge.
>
> I don't know that is it a reasonable and common to connect two customers
> to the same VPP bridge??
>
> But altogether, base on my understanding from Wikipedia's page on 802.1ad,
> in my scenario the traffics tagged 120 must not be recieved by the
> Interface with tag 200. Is that right??
>
>
> On Monday, May 28, 2018, John Lo (loj)  wrote:
>
>> What you observed is the expected behavior.  Adding such a check will add
>> an overhead on l2-output with VTR configured and affect the packet
>> forwarding efficiency.   I still don’t understand the purpose of pushing
>> dot1ad tag on packet at customer interface input in your VPLS test setup.
>> It just make L2 forwarding slower because of the VLAN tag push/pop overhead
>> on each packet and does not serve any purpose, AFAIK.   -John
>>
>>
>>
>> *From:* Mehran Memarnejad 
>> *Sent:* Sunday, May 27, 2018 8:56 AM
>> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
>> *Subject:* Re: dot1ad tag
>>
>>
>>
>> Hi,
>>
>> The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
>>
>> But I think there is another bug here.
>>
>> *First scenario:*
>>
>> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push
>> dot1ad 200
>>
>> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push
>> dot1ad* 200*
>>
>> Everything works perfect. the first PE adds the 802.1ad tag of 200 and
>> the second PE removes it.
>>
>> *Second scenario:*
>>
>> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push
>> dot1ad 200
>>
>> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push
>> dot1ad* 120*
>>
>> I expect the second PE does not pass the packet, since its tag(120) is
>> different from the received tag(200), (Or in other words they are in
>> different service provider's vlan. Am I right?)
>>
>> But unfortunately, the second PE passes it.
>>
>> I think that the source code is just considering the number of tags, not
>> the number of tags and their value. I think this is the bug. Am I right??
>>
>>
>>
>>
>>
>> On Sun, May 27, 2018 at 5:18 PM, Mehran Memarnejad <
>> memarnejad...@gmail.com> wrote:
>>
>> Hi,
>>
>> The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
>>
>> But I think there is another bug here.
>>
>> First scenario:
>>
>> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
>>
>> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 200
>>
>>
>>
>> On Sat, May 26, 2018 at 5:51 AM, John Lo (loj)  wrote:
>>
>> I just submitted a patch. Can you give it a try if this resolve the
>> problem?  -John
>>
>> https://gerrit.fd.io/r/#/c/12750/
>>
>>
>>
>> *From:* Mehran Memarnejad 
>> *Sent:* Friday, May 25, 2018 1:24 PM
>>
>>
>> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
>> *Subject:* Re: dot1ad tag
>>
>>
>>
>> Without tag-rewrite configuration, everything works well. But I want to
>> activate QinQ feature, so I need to add service provider tag (sp-tag) by
>> using dot1ad tag.
>>
>>
>>
>> Any more idea to solve the problem??
>>
>> On Friday, May 25, 2018, John Lo (loj)  wrote:
>>
>> The tag-rewrite (VTR) configuration looks right.  I looked at the
>> l2_vtr_process() function in l2_vtr.h to check how it checks for errors.
>> This is the error drop path:
>>
>>
>>
>>   /* if not enough tags to pop then drop packet */
>>
>>   if (PREDICT_FALSE ((vnet_buffer (b0)->l2.l2_len - 12) <
>> config->pop_bytes))
>>
>> {
>>
>>   return 1;
>>
>> }
>>
>>
>>
>> My guess is that interface-rx-dpo-l2 node did not setup l2_len field in
>> the 

[vpp-dev] dot1ad tag

[Mehran Memarnejad]

Hi,
According to Wikipedia's page for 802.1ad
:

"A tag stack creates a mechanism for Internet Service Providers to
encapsulate customer single-tagged 802.1Q traffic with a single tag, the
final frame being a QinQ frame. The outer tag is used to identify and
segregate traffic from different customers; the inner tag is preserved from
the original frame."

Here I want to add the second tag to segregate customer's traffic. In other
words, I want to consider each customer in PEs as if it is a vlan.
So their traffic is isolated from each other, even though they are both
connected to the same VPP's bridge.
I think that to segregate customer's traffic, we can use:
1- Different VPP bridges for each customer
2- Use second tag (802.1ad tag) to differentiate customers when they are
connected to the same VPP bridge.

Q1: I don't know whether it is reasonable and common to connect two
customers to the same VPP bridge??

Q2: But altogether, base on my understanding from Wikipedia's page on
802.1ad, in my scenario the traffics tagged 120 must not be recieved by the
Interface with tag 200. Is that right??


On Monday, May 28, 2018, John Lo (loj)  wrote:

> What you observed is the expected behavior.  Adding such a check will add
> an overhead on l2-output with VTR configured and affect the packet
> forwarding efficiency.   I still don’t understand the purpose of pushing
> dot1ad tag on packet at customer interface input in your VPLS test setup.
> It just make L2 forwarding slower because of the VLAN tag push/pop overhead
> on each packet and does not serve any purpose, AFAIK.   -John
>
>
>
> *From:* Mehran Memarnejad 
> *Sent:* Sunday, May 27, 2018 8:56 AM
> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
> *Subject:* Re: dot1ad tag
>
>
>
> Hi,
>
> The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
>
> But I think there is another bug here.
>
> *First scenario:*
>
> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push
> dot1ad 200
>
> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad*
> 200*
>
> Everything works perfect. the first PE adds the 802.1ad tag of 200 and the
> second PE removes it.
>
> *Second scenario:*
>
> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push
> dot1ad 200
>
> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad*
> 120*
>
> I expect the second PE does not pass the packet, since its tag(120) is
> different from the received tag(200), (Or in other words they are in
> different service provider's vlan. Am I right?)
>
> But unfortunately, the second PE passes it.
>
> I think that the source code is just considering the number of tags, not
> the number of tags and their value. I think this is the bug. Am I right??
>
>
>
>
>
> On Sun, May 27, 2018 at 5:18 PM, Mehran Memarnejad <
> memarnejad...@gmail.com> wrote:
>
> Hi,
>
> The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
>
> But I think there is another bug here.
>
> First scenario:
>
> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
>
> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 200
>
>
>
> On Sat, May 26, 2018 at 5:51 AM, John Lo (loj)  wrote:
>
> I just submitted a patch. Can you give it a try if this resolve the
> problem?  -John
>
> https://gerrit.fd.io/r/#/c/12750/
>
>
>
> *From:* Mehran Memarnejad 
> *Sent:* Friday, May 25, 2018 1:24 PM
>
>
> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
> *Subject:* Re: dot1ad tag
>
>
>
> Without tag-rewrite configuration, everything works well. But I want to
> activate QinQ feature, so I need to add service provider tag (sp-tag) by
> using dot1ad tag.
>
>
>
> Any more idea to solve the problem??
>
> On Friday, May 25, 2018, John Lo (loj)  wrote:
>
> The tag-rewrite (VTR) configuration looks right.  I looked at the
> l2_vtr_process() function in l2_vtr.h to check how it checks for errors.
> This is the error drop path:
>
>
>
>   /* if not enough tags to pop then drop packet */
>
>   if (PREDICT_FALSE ((vnet_buffer (b0)->l2.l2_len - 12) <
> config->pop_bytes))
>
> {
>
>   return 1;
>
> }
>
>
>
> My guess is that interface-rx-dpo-l2 node did not setup l2_len field in
> the vnet buffer properly before passing the packet to l2-input node. That’s
> why tag-rewrite  operation on l2-output node does not function properly.
> If you remove the tag rewrite config from these GigabitEthernet5/0/0
> customer ports on both PEs, I suppose it should start to work.  Any reason
> you want to have the additional dot1ad tag on the packets for forwarding in
> the BD and MPLS tunnel?
>
>
>
> Regards,
>
> John
>
>
>
> *From:* Mehran Memarnejad 
> *Sent:* Friday, May 25, 2018 4:40 AM
> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
> *Subject:* Re: 

[vpp-dev] dot1ad tag

[Mehran Memarnejad]

Does the efp-filter work base on the second tag??
As far as I experiment, I realized that each subinterface receives packets
with tags equal to their subinterface number, e.g. GigabitEthernet1/0/0.200
will receives packets with inner tags(802.1q) of 200, which is customer'
vlan tag.
I think that I should not consider customer's 802.1q tag in PE.


> On Monday, May 28, 2018, John Lo (loj)  wrote:
>
>> What you observed is the expected behavior.  Adding such a check will add
>> an overhead on l2-output with VTR configured and affect the packet
>> forwarding efficiency.   I still don’t understand the purpose of pushing
>> dot1ad tag on packet at customer interface input in your VPLS test setup.
>> It just make L2 forwarding slower because of the VLAN tag push/pop overhead
>> on each packet and does not serve any purpose, AFAIK.   -John
>>
>>
>>
>> *From:* Mehran Memarnejad 
>> *Sent:* Sunday, May 27, 2018 8:56 AM
>> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
>> *Subject:* Re: dot1ad tag
>>
>>
>>
>> Hi,
>>
>> The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
>>
>> But I think there is another bug here.
>>
>> *First scenario:*
>>
>> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push
>> dot1ad 200
>>
>> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push
>> dot1ad* 200*
>>
>> Everything works perfect. the first PE adds the 802.1ad tag of 200 and
>> the second PE removes it.
>>
>> *Second scenario:*
>>
>> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push
>> dot1ad 200
>>
>> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push
>> dot1ad* 120*
>>
>> I expect the second PE does not pass the packet, since its tag(120) is
>> different from the received tag(200), (Or in other words they are in
>> different service provider's vlan. Am I right?)
>>
>> But unfortunately, the second PE passes it.
>>
>> I think that the source code is just considering the number of tags, not
>> the number of tags and their value. I think this is the bug. Am I right??
>>
>>
>>
>>
>>
>> On Sun, May 27, 2018 at 5:18 PM, Mehran Memarnejad <
>> memarnejad...@gmail.com> wrote:
>>
>> Hi,
>>
>> The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
>>
>> But I think there is another bug here.
>>
>> First scenario:
>>
>> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
>>
>> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 200
>>
>>
>>
>> On Sat, May 26, 2018 at 5:51 AM, John Lo (loj)  wrote:
>>
>> I just submitted a patch. Can you give it a try if this resolve the
>> problem?  -John
>>
>> https://gerrit.fd.io/r/#/c/12750/
>>
>>
>>
>> *From:* Mehran Memarnejad 
>> *Sent:* Friday, May 25, 2018 1:24 PM
>>
>>
>> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
>> *Subject:* Re: dot1ad tag
>>
>>
>>
>> Without tag-rewrite configuration, everything works well. But I want to
>> activate QinQ feature, so I need to add service provider tag (sp-tag) by
>> using dot1ad tag.
>>
>>
>>
>> Any more idea to solve the problem??
>>
>> On Friday, May 25, 2018, John Lo (loj)  wrote:
>>
>> The tag-rewrite (VTR) configuration looks right.  I looked at the
>> l2_vtr_process() function in l2_vtr.h to check how it checks for errors.
>> This is the error drop path:
>>
>>
>>
>>   /* if not enough tags to pop then drop packet */
>>
>>   if (PREDICT_FALSE ((vnet_buffer (b0)->l2.l2_len - 12) <
>> config->pop_bytes))
>>
>> {
>>
>>   return 1;
>>
>> }
>>
>>
>>
>> My guess is that interface-rx-dpo-l2 node did not setup l2_len field in
>> the vnet buffer properly before passing the packet to l2-input node. That’s
>> why tag-rewrite  operation on l2-output node does not function properly.
>> If you remove the tag rewrite config from these GigabitEthernet5/0/0
>> customer ports on both PEs, I suppose it should start to work.  Any reason
>> you want to have the additional dot1ad tag on the packets for forwarding in
>> the BD and MPLS tunnel?
>>
>>
>>
>> Regards,
>>
>> John
>>
>>
>>
>> *From:* Mehran Memarnejad 
>> *Sent:* Friday, May 25, 2018 4:40 AM
>> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
>> *Subject:* Re: dot1ad tag
>>
>>
>>
>> Sw_if_index 6 is the mpls tunnel0 and sw_if_index 3 is the
>> GigabitEthernet5/0/0 on which I have set interface tag-rewrite push dot1ad
>> 12  (both of them are attached to bridge1)
>>
>>
>>
>> Gigabitethernet5/0/0 is the PE's interface toward customer, meaning that
>> I guess if it does not drop the packet, VPLS will work.
>>
>>
>>
>> The packet is sent to the interface attached to bridge
>> (gigabitethernet5/0/0) by mupls tunnel0.
>>
>> But then the packet drops.
>>
>>
>>
>> On Friday, May 25, 2018, John Lo (loj)  wrote:
>>
>> Hi Mehran,
>>
>>
>>
>> The packet trace shows drop is cause by l2-output node when the 

[vpp-dev] Does vcl_epoll_wait() support client concurrent request ? #vnet

[muziding]

HI，

I developed a simple http server by vcl_epoll. When there are multiple client 
requests at the same time , the http server will have some errors, such as 
vcl_epoll_wait() will return unready session. so, I have some questions about 
VCL:
Is VCL still in development ?
Is VCL currently  available  for http server development ?

thanks,
Ning Li

Re: [vpp-dev] show trace caused "out of memory"

[Kingwel Xie]

Hi,

You should increase heap size. In startup.conf, heapsize 1g or something like 
that.

When running in multi-core environment, vpp definitely need more memory, 
because some global variables have to be expanded to have multiple copies - per 
worker thread. F.g., Interface Counters, Error counters ...

Regards,
Kingwel

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of xulang
Sent: Monday, May 28, 2018 6:16 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] show trace caused "out of memory"

Hi all,
When we only use one CPU core, the cmd "show trace max 5000" works well.
But it will crash when we use four CPU cores because of "out of memory".
Below are some information, any guides?

root@vBRAS:~# cat /proc/meminfo
MemTotal:4028788 kB
MemFree:  585636 kB
MemAvailable: 949116 kB
Buffers:   22696 kB
Cached:   592600 kB
SwapCached:0 kB
Active:  1773520 kB
Inactive: 118616 kB
Active(anon):1295912 kB
Inactive(anon):45640 kB
Active(file): 477608 kB
Inactive(file):72976 kB
Unevictable:3656 kB
Mlocked:3656 kB
SwapTotal:976380 kB
SwapFree: 976380 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages:   1280520 kB
Mapped:   112324 kB
Shmem: 62296 kB
Slab:  84456 kB
SReclaimable:  35976 kB
SUnreclaim:48480 kB
KernelStack:5968 kB
PageTables:   267268 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 2466484 kB
Committed_AS:   5368769328 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HardwareCorrupted: 0 kB
AnonHugePages:348160 kB
CmaTotal:  0 kB
CmaFree:   0 kB
HugePages_Total: 512
HugePages_Free:  384
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:   96064 kB
DirectMap2M: 3049472 kB
DirectMap1G: 3145728 kB


0: load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
0: vlib_pci_bind_to_uio: Skipping PCI device :02:0e.0 as host interface 
ens46 is up
EAL: Detected 4 lcore(s)
EAL: No free hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
[New Thread 0x7b0019efa700 (LWP 5207)]
[New Thread 0x7b00196f9700 (LWP 5208)]
[New Thread 0x7b0018ef8700 (LWP 5209)]
EAL: PCI device :02:01.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:06.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:07.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:08.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:09.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:0a.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:0b.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:0c.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:0d.0 on NUMA socket -1
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device :02:0e.0 on NUMA socket -1
EAL:   Device is blacklisted, not initializing
DPDK physical memory layout:
Segment 0: phys:0x7d40, len:2097152, virt:0x7b001500, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 1: phys:0x7d80, len:266338304, virt:0x7affe460, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0
[New Thread 0x7b00186f7700 (LWP 5210)]
/usr/bin/vpp[5202]: dpdk_ipsec_process:241: DPDK Cryptodev support is disabled, 
default to OpenSSL IPsec
/usr/bin/vpp[5202]: dpdk_lib_init:1084: 16384 mbufs allocated but total rx/tx 
ring size is 18432
/usr/bin/vpp[5202]: svm_client_scan_this_region_nolock:1139: /vpe-api: cleanup 
ghost pid 4719
/usr/bin/vpp[5202]: svm_client_scan_this_region_nolock:1139: /global_vm: 
cleanup ghost pid 4719
Thread 1 "vpp_main" received signal SIGABRT, Aborted.
0x7fffef655428 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)
(gdb)
(gdb)
(gdb) p errno /*there are only 81 opened fd belong to progress VPP*/
$1 = 9
(gdb) bt
#0  0x7fffef655428 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fffef65702a in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x0040724e in os_panic () at 
/home/vbras/new_trunk/VBRASV100R001_new_trunk/vpp1704/build-data/../src/vpp/vnet/main.c:290
#3  0x7fffefe6b49b in clib_mem_alloc_aligned_at_offset 
(os_out_of_memory_on_failure=1, align_offset=, align=4, 
size=18768606)   /*mmap*/
at 
/home/vbras/new_trunk/VBRASV100R001_new_trunk/vpp1704/build-data/../src/vppinfra/mem.h:102
#4  vec_resize_allocate_memory (v=, 
length_increment=length_increment@entry=1, data_bytes=, 
header_bytes=, header_bytes@entry=0, 
data_align=data_align@entry=4)
at 

Re: [vpp-dev] dot1ad tag

[Mehran Memarnejad]

Hi,
According to Wikipedia's page for 802.1ad:

"A tag stack creates a mechanism for Internet Service Providers
 to encapsulate
customer single-tagged 802.1Q traffic with a single tag, the final frame
being a QinQ frame. The outer tag is used to identify and segregate traffic
from different customers; the inner tag is preserved from the original
frame."

Here I want to add the second tag to segregate customer's traffic. In other
words, I want to consider each customer in PEs as if it is a vlan.
So their traffic is isolated from each other, even though they are both
connected to the same VPP's bridge.
I think that to segregate customer's traffic, we can use:
1- Different VPP bridges for each customer
2- Use second tag (802.1ad tag) to differentiate customers when they are
connected to the same VPP bridge.

I don't know that is it a reasonable and common to connect two customers to
the same VPP bridge??

But altogether, base on my understanding from Wikipedia's page on 802.1ad,
in my scenario the traffics tagged 120 must not be recieved by the
Interface with tag 200. Is that right??


On Monday, May 28, 2018, John Lo (loj)  wrote:

> What you observed is the expected behavior.  Adding such a check will add
> an overhead on l2-output with VTR configured and affect the packet
> forwarding efficiency.   I still don’t understand the purpose of pushing
> dot1ad tag on packet at customer interface input in your VPLS test setup.
> It just make L2 forwarding slower because of the VLAN tag push/pop overhead
> on each packet and does not serve any purpose, AFAIK.   -John
>
>
>
> *From:* Mehran Memarnejad 
> *Sent:* Sunday, May 27, 2018 8:56 AM
> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
> *Subject:* Re: dot1ad tag
>
>
>
> Hi,
>
> The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
>
> But I think there is another bug here.
>
> *First scenario:*
>
> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push
> dot1ad 200
>
> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad*
> 200*
>
> Everything works perfect. the first PE adds the 802.1ad tag of 200 and the
> second PE removes it.
>
> *Second scenario:*
>
> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push
> dot1ad 200
>
> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad*
> 120*
>
> I expect the second PE does not pass the packet, since its tag(120) is
> different from the received tag(200), (Or in other words they are in
> different service provider's vlan. Am I right?)
>
> But unfortunately, the second PE passes it.
>
> I think that the source code is just considering the number of tags, not
> the number of tags and their value. I think this is the bug. Am I right??
>
>
>
>
>
> On Sun, May 27, 2018 at 5:18 PM, Mehran Memarnejad <
> memarnejad...@gmail.com> wrote:
>
> Hi,
>
> The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
>
> But I think there is another bug here.
>
> First scenario:
>
> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
>
> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 200
>
>
>
> On Sat, May 26, 2018 at 5:51 AM, John Lo (loj)  wrote:
>
> I just submitted a patch. Can you give it a try if this resolve the
> problem?  -John
>
> https://gerrit.fd.io/r/#/c/12750/
>
>
>
> *From:* Mehran Memarnejad 
> *Sent:* Friday, May 25, 2018 1:24 PM
>
>
> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
> *Subject:* Re: dot1ad tag
>
>
>
> Without tag-rewrite configuration, everything works well. But I want to
> activate QinQ feature, so I need to add service provider tag (sp-tag) by
> using dot1ad tag.
>
>
>
> Any more idea to solve the problem??
>
> On Friday, May 25, 2018, John Lo (loj)  wrote:
>
> The tag-rewrite (VTR) configuration looks right.  I looked at the
> l2_vtr_process() function in l2_vtr.h to check how it checks for errors.
> This is the error drop path:
>
>
>
>   /* if not enough tags to pop then drop packet */
>
>   if (PREDICT_FALSE ((vnet_buffer (b0)->l2.l2_len - 12) <
> config->pop_bytes))
>
> {
>
>   return 1;
>
> }
>
>
>
> My guess is that interface-rx-dpo-l2 node did not setup l2_len field in
> the vnet buffer properly before passing the packet to l2-input node. That’s
> why tag-rewrite  operation on l2-output node does not function properly.
> If you remove the tag rewrite config from these GigabitEthernet5/0/0
> customer ports on both PEs, I suppose it should start to work.  Any reason
> you want to have the additional dot1ad tag on the packets for forwarding in
> the BD and MPLS tunnel?
>
>
>
> Regards,
>
> John
>
>
>
> *From:* Mehran Memarnejad 
> *Sent:* Friday, May 25, 2018 4:40 AM
> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
> *Subject:* 

[vpp-dev] dot1ad tag

[Mehran Memarnejad]

Does the efp-filter work base on the second tag??
As far as I experiment, I realized that each subinterface receives packets
with tags equal to their subinterface number, e.g. GigabitEthernet1/0/0.200
will receives packets with inner tags(802.1q) of 200, which is customer'
vlan tag.
I think that I should not consider customer's 802.1q tag in PE.


> On Monday, May 28, 2018, John Lo (loj)  wrote:
>
>> What you observed is the expected behavior.  Adding such a check will add
>> an overhead on l2-output with VTR configured and affect the packet
>> forwarding efficiency.   I still don’t understand the purpose of pushing
>> dot1ad tag on packet at customer interface input in your VPLS test setup.
>> It just make L2 forwarding slower because of the VLAN tag push/pop overhead
>> on each packet and does not serve any purpose, AFAIK.   -John
>>
>>
>>
>> *From:* Mehran Memarnejad 
>> *Sent:* Sunday, May 27, 2018 8:56 AM
>> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
>> *Subject:* Re: dot1ad tag
>>
>>
>>
>> Hi,
>>
>> The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
>>
>> But I think there is another bug here.
>>
>> *First scenario:*
>>
>> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push
>> dot1ad 200
>>
>> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push
>> dot1ad* 200*
>>
>> Everything works perfect. the first PE adds the 802.1ad tag of 200 and
>> the second PE removes it.
>>
>> *Second scenario:*
>>
>> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push
>> dot1ad 200
>>
>> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push
>> dot1ad* 120*
>>
>> I expect the second PE does not pass the packet, since its tag(120) is
>> different from the received tag(200), (Or in other words they are in
>> different service provider's vlan. Am I right?)
>>
>> But unfortunately, the second PE passes it.
>>
>> I think that the source code is just considering the number of tags, not
>> the number of tags and their value. I think this is the bug. Am I right??
>>
>>
>>
>>
>>
>> On Sun, May 27, 2018 at 5:18 PM, Mehran Memarnejad <
>> memarnejad...@gmail.com> wrote:
>>
>> Hi,
>>
>> The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
>>
>> But I think there is another bug here.
>>
>> First scenario:
>>
>> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
>>
>> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 200
>>
>>
>>
>> On Sat, May 26, 2018 at 5:51 AM, John Lo (loj)  wrote:
>>
>> I just submitted a patch. Can you give it a try if this resolve the
>> problem?  -John
>>
>> https://gerrit.fd.io/r/#/c/12750/
>>
>>
>>
>> *From:* Mehran Memarnejad 
>> *Sent:* Friday, May 25, 2018 1:24 PM
>>
>>
>> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
>> *Subject:* Re: dot1ad tag
>>
>>
>>
>> Without tag-rewrite configuration, everything works well. But I want to
>> activate QinQ feature, so I need to add service provider tag (sp-tag) by
>> using dot1ad tag.
>>
>>
>>
>> Any more idea to solve the problem??
>>
>> On Friday, May 25, 2018, John Lo (loj)  wrote:
>>
>> The tag-rewrite (VTR) configuration looks right.  I looked at the
>> l2_vtr_process() function in l2_vtr.h to check how it checks for errors.
>> This is the error drop path:
>>
>>
>>
>>   /* if not enough tags to pop then drop packet */
>>
>>   if (PREDICT_FALSE ((vnet_buffer (b0)->l2.l2_len - 12) <
>> config->pop_bytes))
>>
>> {
>>
>>   return 1;
>>
>> }
>>
>>
>>
>> My guess is that interface-rx-dpo-l2 node did not setup l2_len field in
>> the vnet buffer properly before passing the packet to l2-input node. That’s
>> why tag-rewrite  operation on l2-output node does not function properly.
>> If you remove the tag rewrite config from these GigabitEthernet5/0/0
>> customer ports on both PEs, I suppose it should start to work.  Any reason
>> you want to have the additional dot1ad tag on the packets for forwarding in
>> the BD and MPLS tunnel?
>>
>>
>>
>> Regards,
>>
>> John
>>
>>
>>
>> *From:* Mehran Memarnejad 
>> *Sent:* Friday, May 25, 2018 4:40 AM
>> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
>> *Subject:* Re: dot1ad tag
>>
>>
>>
>> Sw_if_index 6 is the mpls tunnel0 and sw_if_index 3 is the
>> GigabitEthernet5/0/0 on which I have set interface tag-rewrite push dot1ad
>> 12  (both of them are attached to bridge1)
>>
>>
>>
>> Gigabitethernet5/0/0 is the PE's interface toward customer, meaning that
>> I guess if it does not drop the packet, VPLS will work.
>>
>>
>>
>> The packet is sent to the interface attached to bridge
>> (gigabitethernet5/0/0) by mupls tunnel0.
>>
>> But then the packet drops.
>>
>>
>>
>> On Friday, May 25, 2018, John Lo (loj)  wrote:
>>
>> Hi Mehran,
>>
>>
>>
>> The packet trace shows drop is cause by l2-output node when the 

[vpp-dev] dot1ad tag

[Mehran Memarnejad]

Hi,
According to Wikipedia's page for 802.1ad
:

"A tag stack creates a mechanism for Internet Service Providers to
encapsulate customer single-tagged 802.1Q traffic with a single tag, the
final frame being a QinQ frame. The outer tag is used to identify and
segregate traffic from different customers; the inner tag is preserved from
the original frame."

Here I want to add the second tag to segregate customer's traffic. In other
words, I want to consider each customer in PEs as if it is a vlan.
So their traffic is isolated from each other, even though they are both
connected to the same VPP's bridge.
I think that to segregate customer's traffic, we can use:
1- Different VPP bridges for each customer
2- Use second tag (802.1ad tag) to differentiate customers when they are
connected to the same VPP bridge.

Q1: I don't know whether it is reasonable and common to connect two
customers to the same VPP bridge??

Q2: But altogether, base on my understanding from Wikipedia's page on
802.1ad, in my scenario the traffics tagged 120 must not be recieved by the
Interface with tag 200. Is that right??


On Monday, May 28, 2018, John Lo (loj)  wrote:

> What you observed is the expected behavior.  Adding such a check will add
> an overhead on l2-output with VTR configured and affect the packet
> forwarding efficiency.   I still don’t understand the purpose of pushing
> dot1ad tag on packet at customer interface input in your VPLS test setup.
> It just make L2 forwarding slower because of the VLAN tag push/pop overhead
> on each packet and does not serve any purpose, AFAIK.   -John
>
>
>
> *From:* Mehran Memarnejad 
> *Sent:* Sunday, May 27, 2018 8:56 AM
> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
> *Subject:* Re: dot1ad tag
>
>
>
> Hi,
>
> The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
>
> But I think there is another bug here.
>
> *First scenario:*
>
> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push
> dot1ad 200
>
> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad*
> 200*
>
> Everything works perfect. the first PE adds the 802.1ad tag of 200 and the
> second PE removes it.
>
> *Second scenario:*
>
> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push
> dot1ad 200
>
> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad*
> 120*
>
> I expect the second PE does not pass the packet, since its tag(120) is
> different from the received tag(200), (Or in other words they are in
> different service provider's vlan. Am I right?)
>
> But unfortunately, the second PE passes it.
>
> I think that the source code is just considering the number of tags, not
> the number of tags and their value. I think this is the bug. Am I right??
>
>
>
>
>
> On Sun, May 27, 2018 at 5:18 PM, Mehran Memarnejad <
> memarnejad...@gmail.com> wrote:
>
> Hi,
>
> The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
>
> But I think there is another bug here.
>
> First scenario:
>
> PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
>
> PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 200
>
>
>
> On Sat, May 26, 2018 at 5:51 AM, John Lo (loj)  wrote:
>
> I just submitted a patch. Can you give it a try if this resolve the
> problem?  -John
>
> https://gerrit.fd.io/r/#/c/12750/
>
>
>
> *From:* Mehran Memarnejad 
> *Sent:* Friday, May 25, 2018 1:24 PM
>
>
> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
> *Subject:* Re: dot1ad tag
>
>
>
> Without tag-rewrite configuration, everything works well. But I want to
> activate QinQ feature, so I need to add service provider tag (sp-tag) by
> using dot1ad tag.
>
>
>
> Any more idea to solve the problem??
>
> On Friday, May 25, 2018, John Lo (loj)  wrote:
>
> The tag-rewrite (VTR) configuration looks right.  I looked at the
> l2_vtr_process() function in l2_vtr.h to check how it checks for errors.
> This is the error drop path:
>
>
>
>   /* if not enough tags to pop then drop packet */
>
>   if (PREDICT_FALSE ((vnet_buffer (b0)->l2.l2_len - 12) <
> config->pop_bytes))
>
> {
>
>   return 1;
>
> }
>
>
>
> My guess is that interface-rx-dpo-l2 node did not setup l2_len field in
> the vnet buffer properly before passing the packet to l2-input node. That’s
> why tag-rewrite  operation on l2-output node does not function properly.
> If you remove the tag rewrite config from these GigabitEthernet5/0/0
> customer ports on both PEs, I suppose it should start to work.  Any reason
> you want to have the additional dot1ad tag on the packets for forwarding in
> the BD and MPLS tunnel?
>
>
>
> Regards,
>
> John
>
>
>
> *From:* Mehran Memarnejad 
> *Sent:* Friday, May 25, 2018 4:40 AM
> *To:* John Lo (loj) ; vpp-dev@lists.fd.io
> *Subject:* Re: 

Re: [vpp-dev] show trace caused "out of memory"

[xulang]

Hi,
Thanks, 
what is the default heapsize?
So we need to prepare extra PHY memory, right?


Regards



在 2018-05-28 19:10:30，"Kingwel Xie"  写道：


Hi,

 

You should increase heap size. In startup.conf, heapsize 1g or something like 
that.

 

When running in multi-core environment, vpp definitely need more memory, 
because some global variables have to be expanded to have multiple copies – per 
worker thread. F.g., Interface Counters, Error counters …

 

Regards,

Kingwel

 

From:vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of xulang
Sent: Monday, May 28, 2018 6:16 PM
To:vpp-dev@lists.fd.io
Subject: [vpp-dev] show trace caused "out of memory"

 

Hi all,

When we only use one CPU core, the cmd "show trace max 5000" works well.

But it will crash when we use four CPU cores because of "out of memory".

Below are some information, any guides?

 

root@vBRAS:~# cat /proc/meminfo 

MemTotal:4028788 kB

MemFree:  585636 kB

MemAvailable: 949116 kB

Buffers:   22696 kB

Cached:   592600 kB

SwapCached:0 kB

Active:  1773520 kB

Inactive: 118616 kB

Active(anon):1295912 kB

Inactive(anon):45640 kB

Active(file): 477608 kB

Inactive(file):72976 kB

Unevictable:3656 kB

Mlocked:3656 kB

SwapTotal:976380 kB

SwapFree: 976380 kB

Dirty: 0 kB

Writeback: 0 kB

AnonPages:   1280520 kB

Mapped:   112324 kB

Shmem: 62296 kB

Slab:  84456 kB

SReclaimable:  35976 kB

SUnreclaim:48480 kB

KernelStack:5968 kB

PageTables:   267268 kB

NFS_Unstable:  0 kB

Bounce:0 kB

WritebackTmp:  0 kB

CommitLimit: 2466484 kB

Committed_AS:   5368769328 kB

VmallocTotal:   34359738367 kB

VmallocUsed:   0 kB

VmallocChunk:  0 kB

HardwareCorrupted: 0 kB

AnonHugePages:348160 kB

CmaTotal:  0 kB

CmaFree:   0 kB

HugePages_Total: 512

HugePages_Free:  384

HugePages_Rsvd:0

HugePages_Surp:0

Hugepagesize:   2048 kB

DirectMap4k:   96064 kB

DirectMap2M: 3049472 kB

DirectMap1G: 3145728 kB

 

 

0: load_one_plugin:63: Loaded plugin: 
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so

0: vlib_pci_bind_to_uio: Skipping PCI device :02:0e.0 as host interface 
ens46 is up

EAL: Detected 4 lcore(s)

EAL: No free hugepages reported in hugepages-1048576kB

EAL: Probing VFIO support...

[New Thread 0x7b0019efa700 (LWP 5207)]

[New Thread 0x7b00196f9700 (LWP 5208)]

[New Thread 0x7b0018ef8700 (LWP 5209)]

EAL: PCI device :02:01.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:06.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:07.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:08.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:09.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0a.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0b.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0c.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0d.0 on NUMA socket -1

EAL:   probe driver: 8086:100f net_e1000_em

EAL: PCI device :02:0e.0 on NUMA socket -1

EAL:   Device is blacklisted, not initializing

DPDK physical memory layout:

Segment 0: phys:0x7d40, len:2097152, virt:0x7b001500, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0

Segment 1: phys:0x7d80, len:266338304, virt:0x7affe460, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0

[New Thread 0x7b00186f7700 (LWP 5210)]

/usr/bin/vpp[5202]: dpdk_ipsec_process:241: DPDK Cryptodev support is disabled, 
default to OpenSSL IPsec

/usr/bin/vpp[5202]: dpdk_lib_init:1084: 16384 mbufs allocated but total rx/tx 
ring size is 18432

/usr/bin/vpp[5202]: svm_client_scan_this_region_nolock:1139: /vpe-api: cleanup 
ghost pid 4719

/usr/bin/vpp[5202]: svm_client_scan_this_region_nolock:1139: /global_vm: 
cleanup ghost pid 4719

Thread 1 "vpp_main" received signal SIGABRT, Aborted.

0x7fffef655428 in raise () from /lib/x86_64-linux-gnu/libc.so.6

(gdb) 

(gdb) 

(gdb) 

(gdb) p errno /*there are only 81 opened fd belong to progress VPP*/

$1 = 9

(gdb) bt

#0  0x7fffef655428 in raise () from /lib/x86_64-linux-gnu/libc.so.6

#1  0x7fffef65702a in abort () from /lib/x86_64-linux-gnu/libc.so.6

#2  0x0040724e in os_panic () at 
/home/vbras/new_trunk/VBRASV100R001_new_trunk/vpp1704/build-data/../src/vpp/vnet/main.c:290

#3  0x7fffefe6b49b in clib_mem_alloc_aligned_at_offset 
(os_out_of_memory_on_failure=1, align_offset=, align=4, 
size=18768606)   

Re: [vpp-dev] vpp input '\b' problem

[Ray Kinsella]

The VPP CLI is really for debug purposes only.
What are you trying to configure that has such a long command?

Ray K


On 24/05/2018 03:31, 贾铁振 wrote:
When VPP cli configuring multi line content, then continuously input 
'\b', or press' backspace '/' backspace 'continuously, the CLI cursor 
can only go back to the left of the line and cannot return to the last 
line. How can this problem be solved?


Example：
first:
VPP# a
aa
aaa

then input 'backspace' , can only be deleted last seven 'a'
VPP# a
aa





-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9430): https://lists.fd.io/g/vpp-dev/message/9430
View All Messages In Topic (4): https://lists.fd.io/g/vpp-dev/topic/20009021
Mute This Topic: https://lists.fd.io/mt/20009021/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Rx stuck to 0 after a while

[Rubina Bianchi]

Hi

I run vpp v18.07-rc0~237-g525c9d0f with only 2 interface in stateful acl 
(permit+reflect) and generated sfr traffic using trex v2.27. My rx will become 
0 after a short while, about 300 sec in my machine. Here is vpp status:

root@MYRB:~# service vpp status
* vpp.service - vector packet processing engine
   Loaded: loaded (/lib/systemd/system/vpp.service; disabled; vendor preset: 
enabled)
   Active: failed (Result: signal) since Mon 2018-05-28 11:35:03 +0130; 37s ago
  Process: 32838 ExecStopPost=/bin/rm -f /dev/shm/db /dev/shm/global_vm 
/dev/shm/vpe-api (code=exited, status=0/SUCCESS)
  Process: 31754 ExecStart=/usr/bin/vpp -c /etc/vpp/startup.conf (code=killed, 
signal=ABRT)
  Process: 31750 ExecStartPre=/sbin/modprobe uio_pci_generic (code=exited, 
status=0/SUCCESS)
  Process: 31747 ExecStartPre=/bin/rm -f /dev/shm/db /dev/shm/global_vm 
/dev/shm/vpe-api (code=exited, status=0/SUCCESS)
 Main PID: 31754 (code=killed, signal=ABRT)

May 28 16:32:47 MYRB vnet[31754]: acl_fa_node_fn:210: BUG: session 
LSB16(sw_if_index) and 5-tuple collision!
May 28 16:35:02 MYRB vnet[31754]: unix_signal_handler:124: received signal 
SIGCONT, PC 0x7f1fb591cac0
May 28 16:35:02 MYRB vnet[31754]: received SIGTERM, exiting...
May 28 16:35:02 MYRB systemd[1]: Stopping vector packet processing engine...
May 28 16:35:02 MYRB vnet[31754]: unix_signal_handler:124: received signal 
SIGTERM, PC 0x7f1fb3c40867
May 28 16:35:03 MYRB vpp[31754]: vlib_worker_thread_barrier_sync_int: worker 
thread deadlock
May 28 16:35:03 MYRB systemd[1]: vpp.service: Main process exited, code=killed, 
status=6/ABRT
May 28 16:35:03 MYRB systemd[1]: Stopped vector packet processing engine.
May 28 16:35:03 MYRB systemd[1]: vpp.service: Unit entered failed state.
May 28 16:35:03 MYRB systemd[1]: vpp.service: Failed with result 'signal'.

I attach my vpp configs to this email. I also run this test with the same 
config and added 4 interface instead of two. But in this case nothing happened 
to vpp and it was functional for a long time.

Thanks,
RB


init.conf
Description: init.conf


startup.conf
Description: startup.conf


vat
Description: vat


vppctl
Description: vppctl

Re: [vpp-dev] dot1ad tag

[John Lo (loj)]

With L2 bridging, all packets being forwarded in a bridge domain (BD) is 
expected to have the same 1st VLAN tag (or no VLAN tag).  This also applies to 
QinQ packets being forwarded in a service provider bridge where the top dot1ad 
tag is expected to have the same ID while the 2nd dot1q tag can be any value.  
Thus, putting dot1ad tags with different tag IDs on packets in the same BD is 
not a proper way to send packets in a provider bridge .

If packets are coming into a bridge domain with a VLAN tag, one would typically 
create a sub-interface match that of the VLAN tag and put the sub-interface in 
the BD.  If you really want to mix packets with different VLAN tags in the 
bridge domain while limit L2 forwarding to the same VLAN tags only, one can put 
the efp-filter on a sub-interface in the BD so that it will drop packet output 
on a sub-interface if a packet’s top tag, including after VTR output operation 
if one exist, does not match that of the sub-interface.  Again, this is not 
typical usage and an expensive way to do bridging because of the efp filtering 
and flooding in the BD to all sub-interfaces and rely on efp filter to drop 
packets with non-matching VLAN.  It would be much more efficient to use a 
separate BD for sub-interfaces with the same VLAN tag ID.

With Your VPLS setup, the MPLS tunnel connects user BDs and there isn’t really 
a provider bridge.  Thus it does not make sense to be to push dot1ad provider 
bridge tag as it is not used for forwarding anyway.  If you have users coming 
in with different VLAN tags into this BD but are supposed to bridge to each 
other irrespective of the VLAN tag IDs, typical set up will create a 
sub-interface for each VLAN tag ID, put these into the BD, and put a 
tag-rewrite operation of pop-1 on each sub-interface.  Then packets will have 
their VLAN tag poped on input and forwarded in the BD and sent over VPLS tunnel 
with no VLAN tags.  On output, the proper VLAN tag for each sub-interface will 
be pushed on each untagged packet before output.

I hope my explanation help with how bridging is supposed to work,
John

From: Mehran Memarnejad 
Sent: Sunday, May 27, 2018 9:04 PM
To: John Lo (loj) 
Cc: vpp-dev@lists.fd.io
Subject: Re: dot1ad tag

Does the efp-filter work base on the second tag??
As far as I experiment, I realized that each subinterface recieves packets with 
tags equal to their subinterface number, e.g. GigabitEthernet1/0/0.200 will 
receieves packets with inner tags(802.1q) of 200, which is customer' vlan tag.
I think that I should not consider customer's 802.1q tag in PE.

On Monday, May 28, 2018, Mehran Memarnejad 
> wrote:
Hi,
According to Wikipedia's page for 802.1ad:

"A tag stack creates a mechanism for Internet Service 
Providers to 
encapsulate customer single-tagged 802.1Q traffic with a single tag, the final 
frame being a QinQ frame. The outer tag is used to identify and segregate 
traffic from different customers; the inner tag is preserved from the original 
frame."

Here I want to add the second tag to segregate customer's traffic. In other 
words, I want to consider each customer in PEs as if it is a vlan.
So their traffic is isolated from each other, even though they are both 
connected to the same VPP's bridge.
I think that to segregate customer's traffic, we can use:
1- Different VPP bridges for each customer
2- Use second tag (802.1ad tag) to differentiate customers when they are 
connected to the same VPP bridge.

I don't know that is it a reasonable and common to connect two customers to the 
same VPP bridge??

But altogether, base on my understanding from Wikipedia's page on 802.1ad, in 
my scenario the traffics tagged 120 must not be recieved by the Interface with 
tag 200. Is that right??


On Monday, May 28, 2018, John Lo (loj) > 
wrote:
What you observed is the expected behavior.  Adding such a check will add an 
overhead on l2-output with VTR configured and affect the packet forwarding 
efficiency.   I still don’t understand the purpose of pushing dot1ad tag on 
packet at customer interface input in your VPLS test setup.  It just make L2 
forwarding slower because of the VLAN tag push/pop overhead on each packet and 
does not serve any purpose, AFAIK.   -John

From: Mehran Memarnejad 
>
Sent: Sunday, May 27, 2018 8:56 AM
To: John Lo (loj) >; 
vpp-dev@lists.fd.io
Subject: Re: dot1ad tag

Hi,
The patch makes it work perfectly. Now the Second tag (SPtag) is removed.
But I think there is another bug here.
First scenario:
PE1 : set interface l2 tag-rewrite GigabitEthernet5/0/0 push dot1ad 200
PE2 : set interface l2 tag-rewrite GigabitEthernet4/0/1 push dot1ad 200
Everything works