Hi Mike, Perhaps you could tell us why you want to create an untagged sub-interface.
Regards, Neale De : <vpp-dev@lists.fd.io> au nom de "Bly, Mike" <m...@ciena.com> Date : vendredi 21 septembre 2018 à 17:06 À : "John Lo (loj)" <l...@cisco.com>, Edward Warnicke <hagb...@gmail.com>, "vpp-dev@lists.fd.io" <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 <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 <hagb...@gmail.com>; vpp-dev@lists.fd.io; Bly, Mike <m...@ciena.com> 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> <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 <m...@ciena.com<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-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 <vijch...@ciena.com<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>" <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" <vijch...@ciena.com<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>" <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" <vijch...@ciena.com<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>" <vpp-dev@lists.fd.io<mailto: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, sending a new email with the old email trail: Looking to understand the significance of “SUBINT_CONFIG_VALID” flag. When is it set and why ? untagged sub-interface creation fails when this flag is set. Question is when is this flag being set at first place ?? Does this flag indicate that a valid vlan is configured on this interface ? Still looking in to the code but, so far, did not find any instance in the configuration code path (up until “ethernet_sw_interface_add_del”) where this flag is being set. -vijay From: "Chandra Mohan, Vijay Mohan" <vijch...@ciena.com<mailto:vijch...@ciena.com>> Date: Wednesday, September 12, 2018 at 10:16 AM To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> Subject: Re: Unable to create sub-interface with 'untagged' option Just wanted to check if you anyone got a chance to look at this ? Am I missing some configuration here before creating a sub-interface for untagged frames ? -Vijay From: "Chandra Mohan, Vijay Mohan" <vijch...@ciena.com<mailto:vijch...@ciena.com>> Date: Thursday, September 6, 2018 at 3:57 PM To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> Subject: Re: Unable to create sub-interface with 'untagged' option Did anyone get a chance to take a look at this ? -vijay From: "Chandra Mohan, Vijay Mohan" <vijch...@ciena.com<mailto:vijch...@ciena.com>> Date: Wednesday, September 5, 2018 at 1:35 PM To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> Subject: Unable to create sub-interface with 'untagged' option Hi All, Creation of a sub-interface with ‘untagged’ option fails with the message “ create sub-interfaces: vlan is already in use” . Any idea what I am missing here ? There is no other configs present and trying to create sub-interface for the first time. vpp# create sub-interfaces GigabitEthernet5/0/0 1 untagged create sub-interfaces: vlan is already in use Thanks, Vijay -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10559): https://lists.fd.io/g/vpp-dev/message/10559 Mute This Topic: https://lists.fd.io/mt/25750421/675607 Group Owner: vpp-dev+ow...@lists.fd.io<mailto:vpp-dev%2bow...@lists.fd.io> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [aws.ism...@gmail.com<mailto:aws.ism...@gmail.com>] -=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10579): https://lists.fd.io/g/vpp-dev/message/10579 Mute This Topic: https://lists.fd.io/mt/25812529/464962 Group Owner: vpp-dev+ow...@lists.fd.io<mailto:vpp-dev%2bow...@lists.fd.io> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [hagb...@gmail.com<mailto:hagb...@gmail.com>] -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10632): https://lists.fd.io/g/vpp-dev/message/10632 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] -=-=-=-=-=-=-=-=-=-=-=-
