As I explained, it all depends on how you are forwarding packets, (via L3 IP routing, L2 bridging, or L2 xconnect). If it is one of the L2 bridging or xconnect case, it may be feasible to sue classifier to match VLAN tags for packets without having to use sub-interfaces. -John
From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com] Sent: Tuesday, March 14, 2017 6:38 PM To: John Lo (loj) <l...@cisco.com>; vpp-dev@lists.fd.io Subject: RE: Classifying on QinQ labels Hi John, Thanks very much for your answer! Based on your comments below, my understanding is that even in the absence of any sub-interface defined, VLAN and QinQ packets should be matched (i.e. accepted) by the main interface, and the VLAN labels not removed from the packet. So I will take another look at my setup tomorrow. What I want to do is meter/police a set of QinQ flows, so my understanding is I need to setup a classifier table and define a policer for each table session (which in my case is a QinQ flow). Do I need to define a sub-interface for every QinQ flow, or could this be done with no sub-interface at all? Regards, Cristian From: John Lo (loj) [mailto:l...@cisco.com] Sent: Tuesday, March 14, 2017 8:58 PM To: Dumitrescu, Cristian <cristian.dumitre...@intel.com<mailto:cristian.dumitre...@intel.com>>; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: RE: Classifying on QinQ labels I may not have fully answered all the original questions. Added extra edit to my original reply in bold. -John From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of John Lo (loj) Sent: Tuesday, March 14, 2017 4:41 PM To: Dumitrescu, Cristian <cristian.dumitre...@intel.com<mailto:cristian.dumitre...@intel.com>>; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] Classifying on QinQ labels Hi Cristian, If the interface is in L3 routing mode, packets with VLAN tags, either one or two, will need to match a sub-interface or will be dropped. It is not just QinQ packets that are dropped. Once the packet is received, however, the VLAN tags are not removed in the L3 input processing path. So it is possible to perform classification on the VLAN tags to check cos fields, etc. When the packet is routed out an output interface, however, the L2 header will be replaced with whatever is the correct header according to the adjacency info of the output interface. I am not sure why you claim VLAN tag is removed unless you are on the output path when L2 header rewrite happens. If an interface is put into an L2 mode and associated with a bridge domain, however, exact VLAN match will not be necessary. Sub-interface can still be setup and ethernet-input node will perform best-match sub-interface lookup. For example, if you have a sub-interface with VLAN 10 and another sub-interface with QinQ of outer VLAN 10 and inner VLAN 20 on this interface, then: * Any packet with QinQ matching 10/20 will be matched to that QinQ sub-interface. * Any packet with outer VLAN 10, with or without inner VLAN tags will be matched to the VLAN 10 sub-interface. * Any packet with no VLAN tag or outer VLAN tag other than 10 will be matched to the main interface. When a (sub-)interface is in L2 mode, the L2 header including any VLAN tags will not be changed from input to output. So it will be possible to perform input classification on VLAN tags on a (sub-)interface. VLAN tags of an incoming packet can be modified by specifying a tag-rewrite operation to push/pop/replace VLAN tags on packet input. Once tag-rewrite is specified on a (sub-)interface input, an opposite tag-rewrite will be placed on output of that (sub-)interface. For proper packet forwarding in a bridge domain (BD) if the BD have (sub-)interfaces that receive packets with different VLAN tags, tag-rewrite will be necessary to make sure all packets being forwarded in the BD is unified in presence of VLAN tags. Hope this description is helpful, John From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Dumitrescu, Cristian Sent: Tuesday, March 14, 2017 2:54 PM To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: [vpp-dev] Classifying on QinQ labels Hi guys, Is there a way to classify the input packets based on the QinQ field (i.e. SVLAN and CVLAN labels)? It looks like by default all QinQ packets are dropped, so to avoid this a sub-interface has to be created for every QinQ label. The problem with this approach is that SVLAN and CVLAN labels are removed from the packet, therefore these fields can no longer be used by any classifier table. create sub TenGigabitEthernet86/0/1 svlan1cvlan100 dot1q 1 inner-dot1q 100 Also, we need to be able to create thousands of QinQ flows, so probably the sub-interface approach is not the best. Can the sub-interface approach be made to work for QinQ-based classifier? Is there a better way to handle QinQ flows that the sub-interface approach? Regards, Cristian
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
