Avaya Support Forums  

Go Back   Avaya Support Forums > Avaya Networking Products

Closed Thread
 
Thread Tools Search this Thread Display Modes
  #21  
Old 06-22-2015, 02:27 PM
sbilde sbilde is offline
Hot Shot
 
Join Date: Jun 2015
Location: Dallas, TX
Posts: 14
sbilde has 10 reputation points
Default

Thanks. You're probably referring to this:

Quote:
DISCARD UNTAGFRAM The value false indicates that the port will pass untagged frames
It only means the port would let the untagged ports into the switch and tag it with PVID.
  #22  
Old 06-24-2015, 08:40 AM
smanjunath smanjunath is offline
Aspiring Member
.
 
Join Date: Jun 2015
Posts: 1
smanjunath has 10 reputation points
Post

Concern 1: Documentation
---------------------------------------

You can find the procedure for configuring vlans on a port in the documentation

https://downloads.avaya.com/css/P8/documents/101007454
Page 35 - Adding or removing ports in a VLAN



Concern 2: making a "trunk" port _not_ to strip the Default VLAN tag
----------------------------------------------------------------------------------------------------

Whenever you configure a port for trunking / 802.1q you have an option to set a default vlan id on that port. On a tagged port it is expected to receive packets with tag. But whenever you receive a untagged packet on a trunk port we now classify those packets being part of the default vlan id. Switch bridges these packets on the default vlan id path. This is for packets ingressing into a trunk port.

On the egress side again you can send these default vlan id packets as tagged or untagged. By default Avaya switch sends the packets with tag. If you prefer to untag the default vlan id packets then you have to enable the port configuration "UNTAG DEFVLAN"

I have a VSP-4450GSX-PWR+ switch running VSP4000.4.1.0.0.GA software. With default config (UNTAG DEFVLAN - disabled) I am receiving default vlan id packets with tag. Whenever I am enabling the untag default vlan option (UNTAG DEFVLAN - enabled) then switch strips of the vlan tag and sends the packets.


My Topology:
-----------

Laptop1 ---->(1/12) VSP_4K (1/20) ---------> Laptop2

Untagged traffic is sent from Laptop1 and received at Laptop2.

Configurations:
--------------

VSP_4K:1(config)#sho interf gig vlan 1/12,1/20
================================================== ==============================
Port Vlans
================================================== ==============================
PORT DISCARD DISCARD DEFAULT VLAN PORT UNTAG DYNAMIC
NUM TAGGING TAGFRAM UNTAGFRAM VLANID IDS TYPE DEFVLAN VLANS
--------------------------------------------------------------------------------
1/12 enable false false 50 50,150 normal disable P
1/20 enable false false 50 50,150 normal disable P

--------------------------------------------------------------------------------
DYNAMIC VLAN Legend:
P=Protocol enabled.
VSP_4K:1(config)#
VSP_4K:1(config)#interf gig 1/20
VSP_4K:1(config-if)#interf gig 1/20
VSP_4K:1(config-if)#untag-port-default-vlan
VSP_4K:1(config-if)#exit
VSP_4K:1(config)#sho interf gig vlan 1/12,1/20
================================================== ==============================
Port Vlans
================================================== ==============================
PORT DISCARD DISCARD DEFAULT VLAN PORT UNTAG DYNAMIC
NUM TAGGING TAGFRAM UNTAGFRAM VLANID IDS TYPE DEFVLAN VLANS
--------------------------------------------------------------------------------
1/12 enable false false 50 50,150 normal disable P
1/20 enable false false 50 50,150 normal enable P

--------------------------------------------------------------------------------
DYNAMIC VLAN Legend:
P=Protocol enabled.
VSP_4K:1(config)#
  #23  
Old 06-24-2015, 09:48 AM
sbilde sbilde is offline
Hot Shot
 
Join Date: Jun 2015
Location: Dallas, TX
Posts: 14
sbilde has 10 reputation points
Default

Quote:
Originally Posted by smanjunath View Post
Concern 1: Documentation
---------------------------------------

You can find the procedure for configuring vlans on a port in the documentation

https://downloads.avaya.com/css/P8/documents/101007454
Page 35 - Adding or removing ports in a VLAN
*sigh*
I can _NOT_ find an instruction on how to make the port tagged or untagged in this document. The encapsulation dot1q and vlan tagging tagall commands are not even mentioned, that's just ridiculous.




Quote:
Originally Posted by smanjunath View Post
Concern 2: making a "trunk" port _not_ to strip the Default VLAN tag
----------------------------------------------------------------------------------------------------

.....

On the egress side again you can send these default vlan id packets as tagged or untagged. By default Avaya switch sends the packets with tag. If you prefer to untag the default vlan id packets then you have to enable the port configuration "UNTAG DEFVLAN"
Again, the problem is - the egress port can both untag and not_untag packets from vlan 50 (the default one) even with "UNTAG DEFVLAN" disabled.

Try your setup without changing the default vlan untag settings - that's what I was testing.
Simply add the VLAN 50 to both ports and configure both as trunks.

In my case, the laptops are able to ping each other and ingress/egress traffic is untagged.

Last edited by sbilde; 06-24-2015 at 09:50 AM.
  #24  
Old 06-24-2015, 12:53 PM
zakabog zakabog is offline
Genius
 
Join Date: Aug 2014
Posts: 300
zakabog has 25 to 49 reputation pointszakabog has 25 to 49 reputation pointszakabog has 25 to 49 reputation points
Default

I'm still not fully convinced that the switch isn't working exactly as configured. There's nothing in the documentation that says "Untagged traffic received on a tagged port will have an 802.1q tag added to the frame header, then sent to any ports on the corresponding VLAN and will not be untagged as long as UntagDefaultVLAN is disabled on the port it's being sent to." Maybe it doesn't insert an 802.1q tag in the header because it assumes you won't want a tag on an untagged packet? There's nothing in the documentation that says one way or another what exactly it will do to an untagged packet through this process, and since the switch isn't working as you expect it to work it seems very likely that it isn't doing what you think it's going to do.

Filtering untagged frames will cause the ports to behave exactly the way you want them to, and it's well documented as the recommended setup. If you want better documentation then you're going to have to reach out to Avaya (good luck), but I think if you opened a ticket with Avaya they will likely tell you that the device is behaving as expected.
  #25  
Old 06-24-2015, 12:59 PM
sbilde sbilde is offline
Hot Shot
 
Join Date: Jun 2015
Location: Dallas, TX
Posts: 14
sbilde has 10 reputation points
Default

Quote:
Originally Posted by zakabog View Post
I'm still not fully convinced that the switch isn't working exactly as configured. There's nothing in the documentation that says "Untagged traffic received on a tagged port will have an 802.1q tag added to the frame header, then sent to any ports on the corresponding VLAN and will not be untagged as long as UntagDefaultVLAN is disabled on the port it's being sent to." Maybe it doesn't insert an 802.1q tag in the header because it assumes you won't want a tag on an untagged packet?
These things are in the standard, that's how he Ethernet bridge works. If it doesn't insert a tag - what's the purpose of PVID anyway? How would you explain these packets appearing in trunks with exactly the VLAN 50 tag?

Avaya is reached, too.
  #26  
Old 06-24-2015, 03:00 PM
sbilde sbilde is offline
Hot Shot
 
Join Date: Jun 2015
Location: Dallas, TX
Posts: 14
sbilde has 10 reputation points
Default

Everyone thanks for reading, the case is closed.

Since the bug that simple can't stay unnoticed by Q&A and would definitely cause serious problems in the real networks, it is obvious the problem was in the setup itself.

I tried to replicate the problem with various routers and switches instead of the laptops, using trunk/access interfaces - FAIL.

Further investigation has shown the laptop NICs (Intel and Broadcom) behave in a weird way - they strip the VLAN tag (any VLAN tag) and move the packet to the higher protocols (IP in our case) instead of dropping the tagged packet.

No wonder they were able to ping each other.

Changing the registry settings for the NIC to keep VLAN tags:

For Intel:
The new key (dword), either MonitorMode or MonitorModeEnabled should be placed at: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Cl ***\{4D36E972-E325-11CE-BFC1-08002BE10318}\00nn
Where nn is the physical instance of the network port where you want to capture the VLAN tags.

For Broadcom:
  1. Search for "TxCoalescingTicks" and ensure this is the only instance that you have.
  2. Right-click on the instance number (eg. 0008), add a new string value "PreserveVlanInfoInRxPacket" and give it the value "1".
With those settings enabled, NICs don't remove VLAN tags and consequently don't talk to each other anymore.

That solves the mystery of the tagged interface.


Also, a possibly useful trick found while investigating. There is always a VLAN 0 in the system. Adding a VLAN 0 as a PVID to a trunk would effectively block all the untagged traffic both ingress and egress on this port.
Closed Thread

Tags
pvid, vlan, vsp

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 10:05 AM.

This Forum is provided solely for the use and convenience of Avaya customers and partners. Use of the Forum is subject to the Terms and Use and Privacy Statement found at www.avaya.com. No other use is permitted. The Forum including all content posted is “AS IS” and Avaya expressly disclaims all warranties and/or guarantees as to its accuracy, reliability, usefulness, quality or non-infringement of intellectual property. Avaya reserves the right to remove any content posted on the Forum at any time and for whatever reason.

Avaya will not be liable for any content posted on this Forum, including, without limitation, any errors or omissions or for any losses or damages of any kind incurred as a result of use or reliance on any content, regardless of its origin.

You expressly understand and agree that you assume all risks associated with use or reliance on this content.