All,
It was a very quiet meeting at 1600UTC today... Could we in the future have the
meeting time set fixed against UTC so that we avoid any confusion whenever
different regions of the world randomly chooses to move their clocks forward or
backward?
Best regards,
Ole
signature.asc
Descriptio
Ole,
The meeting is on the meeting page and the vpp calendar as 8am PST.
While I share your frustration about DST... it was clearly documented as
such :)
Ed
On Tue, Mar 14, 2017 at 9:11 AM, wrote:
> All,
>
> It was a very quiet meeting at 1600UTC today... Could we in the future
> have the meet
Hi folks,
I have a few questions about the sw_interface_set_l2_bridge API message.
Now, some people have called me a "pedantic ass", to my face even,
so I can handle that. :-) And I wouldn't want to disappoint, so here we
go...
>From commit 374e2c5fc30a5bfabfd2eb6c2d3ca5797402af16, line 640
of
Hi Jon,
You make a valid point about the name chosen for the API param “enable”. Rather
than argue about the best name, let me describe how it works.
The API is intended to enable or disable an interface in L2 bridging mode. By
disable, or enable=0, it will put the interface back to L3 mode whi
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 la
On Tue, Mar 14, 2017 at 1:50 PM, John Lo (loj) wrote:
> Hi Jon,
>
Hi John,
> You make a valid point about the name chosen for the API param “enable”.
> Rather than argue about the best name, let me describe how it works.
>
Sure!
> The API is intended to enable or disable an interface in L2
Hi Jon,
Making the API call using the sw_if_index of the interface with enable=0 will
remove the interface from the bridge domain. The interface will then be back in
L3 mode, as I implied from my original reply.
Regards,
John
From: Jon Loeliger [mailto:j...@netgate.com]
Sent: Tuesday, March 14
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 pa
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] On
Behalf Of John Lo (loj)
Sent: Tuesday, March 14, 2017 4:41 PM
To: Dumitrescu, Cristian ; vpp-dev@lists.fd.io
S
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 ano
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: Dumitresc
11 matches
Mail list logo
