Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged sub-interface

[Bly, Mike]

Neale, et al,

Please find the following patch. https://gerrit.fd.io/r/#/c/15086/

My previous regression errors were operator error. Same results w/ and w/o this 
patch.

-Mike
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10724): https://lists.fd.io/g/vpp-dev/message/10724
Mute This Topic: https://lists.fd.io/mt/25812529/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged sub-interface

[Bly, Mike]

Neale,

We are in need of providing a full blend of L2 and L3 services on each NIC. The 
permutations dictate a need for untagged to be separated from what VPP calls 
“default” (all non-explicit tagged traffic) on disparate sub-interfaces. I have 
the changes done locally that appear to make this work and all of the 
permutations appear to function correctly from an L2 perspective (refer to my 
original simple config).

I wanted to run “make test” before submitting my patch, but even with the stock 
stable/1801 branch I am running into test failures on a CentOS container setup. 
All preceding sub-tests (except MAC learning) are passing. Digging through 
online search results to see what I can figure out.

==
ARP Test Case
==
ARP  OK
Fatal Python error: Bus error

Thread 0x7ff607bff700  (most recent call first):
  File "/usr/lib64/python2.7/threading.py", line 339 in wait
  File "/usr/lib64/python2.7/Queue.py", line 168 in get
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 850 in 
thread_msg_handler
  File "/usr/lib64/python2.7/threading.py", line 765 in run
  File "/usr/lib64/python2.7/threading.py", line 812 in __bootstrap_inner
  File "/usr/lib64/python2.7/threading.py", line 785 in __bootstrap
...
Thread 0x7ff799844700  (most recent call first):
  File "/usr/lib64/python2.7/threading.py", line 339 in wait
  File "/usr/lib64/python2.7/Queue.py", line 168 in get
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 850 in 
thread_msg_handler
  File "/usr/lib64/python2.7/threading.py", line 765 in run
  File "/usr/lib64/python2.7/threading.py", line 812 in __bootstrap_inner
  File "/usr/lib64/python2.7/threading.py", line 785 in __bootstrap

Current thread 0x7ff7a4950740  (most recent call first):
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 616 in _write_new_cffi
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 773 in _call_vpp
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 571 in 
  File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 99 in __call__
  File "/workspace/vpp/test/vpp_papi_provider.py", line 184 in cli
  File "/workspace/vpp/test/framework.py", line 496 in setUp
  File "/workspace/vpp/test/test_neighbor.py", line 24 in setUp
  File "/usr/lib64/python2.7/unittest/case.py", line 360 in run
  File "/usr/lib64/python2.7/unittest/case.py", line 433 in __call__
  File "/usr/lib64/python2.7/unittest/suite.py", line 108 in run
  File "/usr/lib64/python2.7/unittest/suite.py", line 70 in __call__
  File "/usr/lib64/python2.7/unittest/runner.py", line 151 in run
  File "/workspace/vpp/test/framework.py", line 1108 in run
  File "run_tests.py", line 21 in test_runner_wrapper
  File "/usr/lib64/python2.7/multiprocessing/process.py", line 114 in run
  File "/usr/lib64/python2.7/multiprocessing/process.py", line 258 in _bootstrap
  File "/usr/lib64/python2.7/multiprocessing/forking.py", line 126 in __init__
  File "/usr/lib64/python2.7/multiprocessing/process.py", line 130 in start
  File "run_tests.py", line 57 in run_forked
  File "run_tests.py", line 159 in 
22:36:41,079 Timeout while waiting for child test runner process (last test 
running was `ARP Duplicates' in `/tmp/vpp-unittest-ARPTestCase-HV5bsk')!
22:36:41,080 Creating a link to the failed test: 
/tmp/vpp-failed-unittests/vpp-unittest-ARPTestCase-HV5bsk-FAILED -> 
vpp-unittest-ARPTestCase-HV5bsk
1 test(s) failed, 0 attempt(s) left
Killing possible remaining process IDs:  1108 1115 1117
Not compressing files in temporary directories from failed test runs.
make[1]: *** [test] Error 1
make[1]: Leaving directory `/workspace/vpp/test'
make: *** [test] Error 2


-Mike

From: Neale Ranns (nranns) 
Sent: Tuesday, September 25, 2018 12:39 AM
To: Bly, Mike ; John Lo (loj) ; Edward Warnicke 
; vpp-dev@lists.fd.io
Subject: Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged 
sub-interface

Hi Mike,

Perhaps you could tell us why you want to create an untagged sub-interface.

Regards,
Neale


De : mailto:vpp-dev@lists.fd.io>> au nom de "Bly, Mike" 
mailto:m...@ciena.com>>
Date : vendredi 21 septembre 2018 à 17:06
À : "John Lo (loj)" mailto:l...@cisco.com>>, Edward Warnicke 
mailto:hagb...@gmail.com>>, 
"vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Objet : Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged 
sub-interface

John,

Any advise on this is appre

Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged sub-interface

[Neale Ranns via Lists.Fd.Io]

Hi Mike,

Perhaps you could tell us why you want to create an untagged sub-interface.

Regards,
Neale


De :  au nom de "Bly, Mike" 
Date : vendredi 21 septembre 2018 à 17:06
À : "John Lo (loj)" , Edward Warnicke , 
"vpp-dev@lists.fd.io" 
Objet : Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged 
sub-interface

John,

Any advise on this is appreciated. We can certainly dig into this, but we first 
wanted to sanity check with the community in case there was something obvious 
as to why it is working the way it is currently. I am hopeful that between you 
efforts and ours we can run this to ground in short order.

-Mike

From: vpp-dev@lists.fd.io  On Behalf Of John Lo (loj) via 
Lists.Fd.Io
Sent: Thursday, September 20, 2018 4:02 PM
To: Edward Warnicke ; vpp-dev@lists.fd.io; Bly, Mike 

Cc: vpp-dev@lists.fd.io
Subject: Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged 
sub-interface

When a sub-interface is created, matching of tags on the packet to the 
sub-interface can be specified as “exact-match”.  With exact-match, packet must 
have the same number of tags with values matching that specified for the 
sub-interface.  Otherwise, packets will belong to the best matched 
sub-interface.  A sub-interface to be used for L3 must be created with 
exact-match.  Otherwise, IP forwarding cannot get a proper L2 header rewrite 
for output on the sub-interface.

As for a main interface,  I suppose when it is in L2 mode, packets received 
with no tags or with tags without any specific sub-interface match is 
considered as on the main interface.  When the main interface is in L3 mode, it 
will only get untagged packets because of the exact match requirement.  I think 
this is why the default sub-interface starts to get non-matching tagged packets 
when main interface is in L3 mode, as observed.  Packets received on the main 
interface in L3 mode can be IP forwarded or be dropped.

It is a good question – what is the expected sub-interface classification 
behavior with untagged or default sub-interface?  I think this is the area of 
VPP that has not been used much and thus we have little knowledge of how it 
behaves without studying the code (hence lack of response to this thread of 
questions so far).  When I get a chance, I can take look into this issue – how 
VLAN match should work for default/untagged sub-interface and why untagged 
sub-interface creation fails.  I don’t know how soon I will get to it.  So, if 
anyone is willing to contribute and submit a patch to fix the issue, I will be 
happy to review and/or merge the patch as appropriate.

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Edward Warnicke
Sent: Thursday, September 20, 2018 1:25 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; Bly, Mike 
mailto:m...@ciena.com>>
Subject: Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged 
sub-interface

Guys,
  Anyone have any thoughts on this?

Ed



On September 20, 2018 at 12:01:05 PM, Bly, Mike 
(m...@ciena.com<mailto:m...@ciena.com>) wrote:
Ed/Keith, et al,

What Vijay is digging into is trying to understand how to provide the following 
sub-interface setup on a common/single physical NIC. I am hoping you can shed 
some light on the feasibility of this, given the current code to date.

Our goal is to provide proper separation of untagged vs. explicit-vlan (EVPL) 
vs. default (all remaining vlans) vs. EPL as needed on a given NIC, independent 
of any choice of forwarding mode (L2 vs L3).

GigabitEthernet5/0/0 --> “not used to forward traffic” (see next three 
sub-if’s), calling it sub_if_0 for reference below (seen as possible EPL path, 
but not covered here, since already “working”)
GigabitEthernet5/0/0.untagged --> all untagged traffic on this port goes to 
sub_if_1
GigabitEthernet5/0/0.vid1 --> all traffic arriving with outer tag == 1 goes to 
sub_if_2
GigabitEthernet5/0/0.default --> all other tagged traffic goes to sub_if_3

The only way we seem to be able to get sub_if_3 to process traffic is to 
disable sub_if_0 (set mode to l3).

Additionally, the current configuration checking in src/vnet/ethernet/node.c 
does not seem amenable to allowing the actual configuration and support of 
untagged vs default as two distinct sub-if’s processing traffic at the same 
time (my sub_if_1 and sub_if_3 above). Are we missing something here in how 
this is supposed to work? We would be fine with letting “sub_if_0” carry the 
untagged traffic (in place of sub_if_1), but we have yet to figure out how to 
do that while still having sub_if_3 processing “all other tagged frames”. We 
can say in all of our testing that we in fact do correctly see sub_if_2 working 
as expected.

Here is a simple configuration showing our current efforts in this area:

create bridge-domain 1
create bridge-domain 2
create bridge-domain 3

set interface l2 brid

Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged sub-interface

[Bly, Mike]

John,

Any advise on this is appreciated. We can certainly dig into this, but we first 
wanted to sanity check with the community in case there was something obvious 
as to why it is working the way it is currently. I am hopeful that between you 
efforts and ours we can run this to ground in short order.

-Mike

From: vpp-dev@lists.fd.io  On Behalf Of John Lo (loj) via 
Lists.Fd.Io
Sent: Thursday, September 20, 2018 4:02 PM
To: Edward Warnicke ; vpp-dev@lists.fd.io; Bly, Mike 

Cc: vpp-dev@lists.fd.io
Subject: Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged 
sub-interface

When a sub-interface is created, matching of tags on the packet to the 
sub-interface can be specified as “exact-match”.  With exact-match, packet must 
have the same number of tags with values matching that specified for the 
sub-interface.  Otherwise, packets will belong to the best matched 
sub-interface.  A sub-interface to be used for L3 must be created with 
exact-match.  Otherwise, IP forwarding cannot get a proper L2 header rewrite 
for output on the sub-interface.

As for a main interface,  I suppose when it is in L2 mode, packets received 
with no tags or with tags without any specific sub-interface match is 
considered as on the main interface.  When the main interface is in L3 mode, it 
will only get untagged packets because of the exact match requirement.  I think 
this is why the default sub-interface starts to get non-matching tagged packets 
when main interface is in L3 mode, as observed.  Packets received on the main 
interface in L3 mode can be IP forwarded or be dropped.

It is a good question – what is the expected sub-interface classification 
behavior with untagged or default sub-interface?  I think this is the area of 
VPP that has not been used much and thus we have little knowledge of how it 
behaves without studying the code (hence lack of response to this thread of 
questions so far).  When I get a chance, I can take look into this issue – how 
VLAN match should work for default/untagged sub-interface and why untagged 
sub-interface creation fails.  I don’t know how soon I will get to it.  So, if 
anyone is willing to contribute and submit a patch to fix the issue, I will be 
happy to review and/or merge the patch as appropriate.

Regards,
John

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Edward Warnicke
Sent: Thursday, September 20, 2018 1:25 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; Bly, Mike 
mailto:m...@ciena.com>>
Subject: Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged 
sub-interface

Guys,
  Anyone have any thoughts on this?

Ed



On September 20, 2018 at 12:01:05 PM, Bly, Mike 
(m...@ciena.com<mailto:m...@ciena.com>) wrote:
Ed/Keith, et al,

What Vijay is digging into is trying to understand how to provide the following 
sub-interface setup on a common/single physical NIC. I am hoping you can shed 
some light on the feasibility of this, given the current code to date.

Our goal is to provide proper separation of untagged vs. explicit-vlan (EVPL) 
vs. default (all remaining vlans) vs. EPL as needed on a given NIC, independent 
of any choice of forwarding mode (L2 vs L3).

GigabitEthernet5/0/0 --> “not used to forward traffic” (see next three 
sub-if’s), calling it sub_if_0 for reference below (seen as possible EPL path, 
but not covered here, since already “working”)
GigabitEthernet5/0/0.untagged --> all untagged traffic on this port goes to 
sub_if_1
GigabitEthernet5/0/0.vid1 --> all traffic arriving with outer tag == 1 goes to 
sub_if_2
GigabitEthernet5/0/0.default --> all other tagged traffic goes to sub_if_3

The only way we seem to be able to get sub_if_3 to process traffic is to 
disable sub_if_0 (set mode to l3).

Additionally, the current configuration checking in src/vnet/ethernet/node.c 
does not seem amenable to allowing the actual configuration and support of 
untagged vs default as two distinct sub-if’s processing traffic at the same 
time (my sub_if_1 and sub_if_3 above). Are we missing something here in how 
this is supposed to work? We would be fine with letting “sub_if_0” carry the 
untagged traffic (in place of sub_if_1), but we have yet to figure out how to 
do that while still having sub_if_3 processing “all other tagged frames”. We 
can say in all of our testing that we in fact do correctly see sub_if_2 working 
as expected.

Here is a simple configuration showing our current efforts in this area:

create bridge-domain 1
create bridge-domain 2
create bridge-domain 3

set interface l2 bridge GigabitEthernet5/0/0 1
set interface l2 bridge GigabitEthernet5/0/1 1

create sub-interfaces GigabitEthernet5/0/0 4095 default
create sub-interfaces GigabitEthernet5/0/1 4095 default
set interface l2 bridge GigabitEthernet5/0/0.4095 2
set interface l2 bridge GigabitEthernet5/0/1.4095 2

create sub-interfaces GigabitEthernet5/0/0 1
create sub-interfac

Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged sub-interface

[John Lo (loj) via Lists.Fd.Io]

When a sub-interface is created, matching of tags on the packet to the 
sub-interface can be specified as “exact-match”.  With exact-match, packet must 
have the same number of tags with values matching that specified for the 
sub-interface.  Otherwise, packets will belong to the best matched 
sub-interface.  A sub-interface to be used for L3 must be created with 
exact-match.  Otherwise, IP forwarding cannot get a proper L2 header rewrite 
for output on the sub-interface.

As for a main interface,  I suppose when it is in L2 mode, packets received 
with no tags or with tags without any specific sub-interface match is 
considered as on the main interface.  When the main interface is in L3 mode, it 
will only get untagged packets because of the exact match requirement.  I think 
this is why the default sub-interface starts to get non-matching tagged packets 
when main interface is in L3 mode, as observed.  Packets received on the main 
interface in L3 mode can be IP forwarded or be dropped.

It is a good question – what is the expected sub-interface classification 
behavior with untagged or default sub-interface?  I think this is the area of 
VPP that has not been used much and thus we have little knowledge of how it 
behaves without studying the code (hence lack of response to this thread of 
questions so far).  When I get a chance, I can take look into this issue – how 
VLAN match should work for default/untagged sub-interface and why untagged 
sub-interface creation fails.  I don’t know how soon I will get to it.  So, if 
anyone is willing to contribute and submit a patch to fix the issue, I will be 
happy to review and/or merge the patch as appropriate.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Edward Warnicke
Sent: Thursday, September 20, 2018 1:25 PM
To: vpp-dev@lists.fd.io; Bly, Mike 
Subject: Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged 
sub-interface

Guys,
  Anyone have any thoughts on this?

Ed



On September 20, 2018 at 12:01:05 PM, Bly, Mike 
(m...@ciena.com<mailto:m...@ciena.com>) wrote:
Ed/Keith, et al,

What Vijay is digging into is trying to understand how to provide the following 
sub-interface setup on a common/single physical NIC. I am hoping you can shed 
some light on the feasibility of this, given the current code to date.

Our goal is to provide proper separation of untagged vs. explicit-vlan (EVPL) 
vs. default (all remaining vlans) vs. EPL as needed on a given NIC, independent 
of any choice of forwarding mode (L2 vs L3).

GigabitEthernet5/0/0 --> “not used to forward traffic” (see next three 
sub-if’s), calling it sub_if_0 for reference below (seen as possible EPL path, 
but not covered here, since already “working”)
GigabitEthernet5/0/0.untagged --> all untagged traffic on this port goes to 
sub_if_1
GigabitEthernet5/0/0.vid1 --> all traffic arriving with outer tag == 1 goes to 
sub_if_2
GigabitEthernet5/0/0.default --> all other tagged traffic goes to sub_if_3

The only way we seem to be able to get sub_if_3 to process traffic is to 
disable sub_if_0 (set mode to l3).

Additionally, the current configuration checking in src/vnet/ethernet/node.c 
does not seem amenable to allowing the actual configuration and support of 
untagged vs default as two distinct sub-if’s processing traffic at the same 
time (my sub_if_1 and sub_if_3 above). Are we missing something here in how 
this is supposed to work? We would be fine with letting “sub_if_0” carry the 
untagged traffic (in place of sub_if_1), but we have yet to figure out how to 
do that while still having sub_if_3 processing “all other tagged frames”. We 
can say in all of our testing that we in fact do correctly see sub_if_2 working 
as expected.

Here is a simple configuration showing our current efforts in this area:

create bridge-domain 1
create bridge-domain 2
create bridge-domain 3

set interface l2 bridge GigabitEthernet5/0/0 1
set interface l2 bridge GigabitEthernet5/0/1 1

create sub-interfaces GigabitEthernet5/0/0 4095 default
create sub-interfaces GigabitEthernet5/0/1 4095 default
set interface l2 bridge GigabitEthernet5/0/0.4095 2
set interface l2 bridge GigabitEthernet5/0/1.4095 2

create sub-interfaces GigabitEthernet5/0/0 1
create sub-interfaces GigabitEthernet5/0/1 1
set interface l2 bridge GigabitEthernet5/0/1.1 3
set interface l2 bridge GigabitEthernet5/0/0.1 3


set interface state GigabitEthernet5/0/0 up
set interface state GigabitEthernet5/0/1 up
set interface state GigabitEthernet5/0/0.4095 up
set interface state GigabitEthernet5/0/1.4095 up
set interface state GigabitEthernet5/0/0.1 up
set interface state GigabitEthernet5/0/1.1 up

As noted above, the only way to get GigabitEthernet5/0/0.4095 to process frames 
is to do the following, but doing so drops all untagged traffic.

set interface l3 GigabitEthernet5/0/0

Let us know next steps in resolving this.

Best Regards,
Mike

-- Forwarded message --
From: Chandra Mohan, Vijay 

Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged sub-interface

[Edward Warnicke]

Guys,
Anyone have any thoughts on this?

Ed


On September 20, 2018 at 12:01:05 PM, Bly, Mike (m...@ciena.com) wrote:

Ed/Keith, et al,



What Vijay is digging into is trying to understand how to provide the
following sub-interface setup on a common/single physical NIC. I am hoping
you can shed some light on the feasibility of this, given the current code
to date.



Our goal is to provide proper separation of untagged vs. explicit-vlan
(EVPL) vs. default (all remaining vlans) vs. EPL as needed on a given NIC,
independent of any choice of forwarding mode (L2 vs L3).



GigabitEthernet5/0/0 à “not used to forward traffic” (see next three
sub-if’s), calling it sub_if_0 for reference below (seen as possible EPL
path, but not covered here, since already “working”)

GigabitEthernet5/0/0.untagged à all untagged traffic on this port goes to
sub_if_1

GigabitEthernet5/0/0.vid1 à all traffic arriving with outer tag == 1 goes
to sub_if_2

GigabitEthernet5/0/0.default à all other tagged traffic goes to sub_if_3



The only way we seem to be able to get sub_if_3 to process traffic is to
disable sub_if_0 (set mode to l3).



Additionally, the current configuration checking in
src/vnet/ethernet/node.c does not seem amenable to allowing the actual
configuration and support of untagged vs default as two distinct sub-if’s
processing traffic at the same time (my sub_if_1 and sub_if_3 above). Are
we missing something here in how this is supposed to work? We would be fine
with letting “sub_if_0” carry the untagged traffic (in place of sub_if_1),
but we have yet to figure out how to do that while still having sub_if_3
processing “all other tagged frames”. We can say in all of our testing that
we in fact do correctly see sub_if_2 working as expected.



Here is a simple configuration showing our current efforts in this area:



create bridge-domain 1

create bridge-domain 2

create bridge-domain 3



set interface l2 bridge GigabitEthernet5/0/0 1

set interface l2 bridge GigabitEthernet5/0/1 1



create sub-interfaces GigabitEthernet5/0/0 4095 default

create sub-interfaces GigabitEthernet5/0/1 4095 default

set interface l2 bridge GigabitEthernet5/0/0.4095 2

set interface l2 bridge GigabitEthernet5/0/1.4095 2



create sub-interfaces GigabitEthernet5/0/0 1

create sub-interfaces GigabitEthernet5/0/1 1

set interface l2 bridge GigabitEthernet5/0/1.1 3

set interface l2 bridge GigabitEthernet5/0/0.1 3





set interface state GigabitEthernet5/0/0 up

set interface state GigabitEthernet5/0/1 up

set interface state GigabitEthernet5/0/0.4095 up

set interface state GigabitEthernet5/0/1.4095 up

set interface state GigabitEthernet5/0/0.1 up

set interface state GigabitEthernet5/0/1.1 up



As noted above, the only way to get GigabitEthernet5/0/0.4095 to process
frames is to do the following, but doing so drops all untagged traffic.



set interface l3 GigabitEthernet5/0/0



Let us know next steps in resolving this.



Best Regards,

Mike



-- Forwarded message --
From: *Chandra Mohan, Vijay Mohan* 
Date: Tue, Sep 18, 2018 at 8:35 PM
Subject: Re: [vpp-dev] Failing to create untagged sub-interface
To: "vpp-dev@lists.fd.io" 



typedef struct

{

  u32 sw_if_index;

  u32 flags;

  // config entry is-valid flag

  // exact match flags (valid if packet has 0/1/2/3 tags)

  // L2 vs L3 forwarding mode

#define SUBINT_CONFIG_MATCH_0_TAG (1<<0)

#define SUBINT_CONFIG_MATCH_1_TAG (1<<1)

#define SUBINT_CONFIG_MATCH_2_TAG (1<<2)

#define SUBINT_CONFIG_MATCH_3_TAG (1<<3)

#define SUBINT_CONFIG_VALID   (1<<4)

#define SUBINT_CONFIG_L2  (1<<5)

#define SUBINT_CONFIG_P2P (1<<6)



} subint_config_t;





typedef struct

{

  subint_config_t untagged_subint;

  subint_config_t default_subint;

  u16 dot1q_vlans;  // pool id for vlan table

  u16 dot1ad_vlans; // pool id for vlan table

} main_intf_t;



Each main interface has untagged_subint and default_subint. The sw_if_index
in untagged_subint is same as the sw_if_index of the physical interface and
the ‘flags’ has ‘SUBINT_CONFIG_VALID’ set. Since, by default, physical
interface forwards untagged traffic, is the physical interface itself is
being treated as untagged sub-interface ? is my understanding correct ?



-vijay







*From: *"Chandra Mohan, Vijay Mohan" 
*Date: *Tuesday, September 18, 2018 at 3:52 PM
*To: *"vpp-dev@lists.fd.io" 
*Subject: *Re: Failing to create untagged sub-interface



Fd.io pages states following in the “create sub-interfaces” section:

Example of how to created a subinterface to process untagged packets:

*vpp# create sub-interfaces GigabitEthernet2/0/0 5 untagged*



I am trying to do exactly same thing mentioned above and it fails. Is this
a known issue (a bug) ??



-vijay





*From: *"Chandra Mohan, Vijay Mohan" 
*Date: *Tuesday, September 18, 2018 at 2:37 PM
*To: *"vpp-dev@lists.fd.io" 
*Subject: *Failing to create untagged sub-interface



Was not sure if this email is being delivered properly or not, so, 

Re: [**EXTERNAL**] Fwd: [vpp-dev] Failing to create untagged sub-interface

[Bly, Mike]

Ed/Keith, et al,

What Vijay is digging into is trying to understand how to provide the following 
sub-interface setup on a common/single physical NIC. I am hoping you can shed 
some light on the feasibility of this, given the current code to date.

Our goal is to provide proper separation of untagged vs. explicit-vlan (EVPL) 
vs. default (all remaining vlans) vs. EPL as needed on a given NIC, independent 
of any choice of forwarding mode (L2 vs L3).

GigabitEthernet5/0/0 --> “not used to forward traffic” (see next three 
sub-if’s), calling it sub_if_0 for reference below (seen as possible EPL path, 
but not covered here, since already “working”)
GigabitEthernet5/0/0.untagged --> all untagged traffic on this port goes to 
sub_if_1
GigabitEthernet5/0/0.vid1 --> all traffic arriving with outer tag == 1 goes to 
sub_if_2
GigabitEthernet5/0/0.default --> all other tagged traffic goes to sub_if_3

The only way we seem to be able to get sub_if_3 to process traffic is to 
disable sub_if_0 (set mode to l3).

Additionally, the current configuration checking in src/vnet/ethernet/node.c 
does not seem amenable to allowing the actual configuration and support of 
untagged vs default as two distinct sub-if’s processing traffic at the same 
time (my sub_if_1 and sub_if_3 above). Are we missing something here in how 
this is supposed to work? We would be fine with letting “sub_if_0” carry the 
untagged traffic (in place of sub_if_1), but we have yet to figure out how to 
do that while still having sub_if_3 processing “all other tagged frames”. We 
can say in all of our testing that we in fact do correctly see sub_if_2 working 
as expected.

Here is a simple configuration showing our current efforts in this area:

create bridge-domain 1
create bridge-domain 2
create bridge-domain 3

set interface l2 bridge GigabitEthernet5/0/0 1
set interface l2 bridge GigabitEthernet5/0/1 1

create sub-interfaces GigabitEthernet5/0/0 4095 default
create sub-interfaces GigabitEthernet5/0/1 4095 default
set interface l2 bridge GigabitEthernet5/0/0.4095 2
set interface l2 bridge GigabitEthernet5/0/1.4095 2

create sub-interfaces GigabitEthernet5/0/0 1
create sub-interfaces GigabitEthernet5/0/1 1
set interface l2 bridge GigabitEthernet5/0/1.1 3
set interface l2 bridge GigabitEthernet5/0/0.1 3


set interface state GigabitEthernet5/0/0 up
set interface state GigabitEthernet5/0/1 up
set interface state GigabitEthernet5/0/0.4095 up
set interface state GigabitEthernet5/0/1.4095 up
set interface state GigabitEthernet5/0/0.1 up
set interface state GigabitEthernet5/0/1.1 up

As noted above, the only way to get GigabitEthernet5/0/0.4095 to process frames 
is to do the following, but doing so drops all untagged traffic.

set interface l3 GigabitEthernet5/0/0

Let us know next steps in resolving this.

Best Regards,
Mike

-- Forwarded message --
From: Chandra Mohan, Vijay Mohan mailto:vijch...@ciena.com>>
Date: Tue, Sep 18, 2018 at 8:35 PM
Subject: Re: [vpp-dev] Failing to create untagged sub-interface
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>




typedef struct

{

  u32 sw_if_index;

  u32 flags;

  // config entry is-valid flag

  // exact match flags (valid if packet has 0/1/2/3 tags)

  // L2 vs L3 forwarding mode

#define SUBINT_CONFIG_MATCH_0_TAG (1<<0)

#define SUBINT_CONFIG_MATCH_1_TAG (1<<1)

#define SUBINT_CONFIG_MATCH_2_TAG (1<<2)

#define SUBINT_CONFIG_MATCH_3_TAG (1<<3)

#define SUBINT_CONFIG_VALID   (1<<4)

#define SUBINT_CONFIG_L2  (1<<5)

#define SUBINT_CONFIG_P2P (1<<6)



} subint_config_t;





typedef struct

{

  subint_config_t untagged_subint;

  subint_config_t default_subint;

  u16 dot1q_vlans;  // pool id for vlan table

  u16 dot1ad_vlans; // pool id for vlan table

} main_intf_t;

Each main interface has untagged_subint and default_subint. The sw_if_index in 
untagged_subint is same as the sw_if_index of the physical interface and the 
‘flags’ has ‘SUBINT_CONFIG_VALID’ set. Since, by default, physical interface 
forwards untagged traffic, is the physical interface itself is being treated as 
untagged sub-interface ? is my understanding correct ?

-vijay



From: "Chandra Mohan, Vijay Mohan" 
mailto:vijch...@ciena.com>>
Date: Tuesday, September 18, 2018 at 3:52 PM
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: Failing to create untagged sub-interface

Fd.io pages states following in the “create sub-interfaces” section:
Example of how to created a subinterface to process untagged packets:
vpp# create sub-interfaces GigabitEthernet2/0/0 5 untagged

I am trying to do exactly same thing mentioned above and it fails. Is this a 
known issue (a bug) ??

-vijay


From: "Chandra Mohan, Vijay Mohan" 
mailto:vijch...@ciena.com>>
Date: Tuesday, September 18, 2018 at 2:37 PM
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: Failing to create untagged