Pinned topicSEA defaultid vs. Virtual Adapter PVID

‏2012-10-01T19:25:27Z
|Tags:

Answered question
This question has been answered.

Unanswered question
This question has not been answered yet.

I am trying to understand the details of how the SEA defaultid differs from the Virtual Adapter PVID. It seems to make sense when I look at examples where a switch's PVID is extended into the internal VLAN and I have seen examples where bogus defaultid/PVIDs have been used to break the VLAN forwarding so that the switch's default VLAN does not get into the internal VLAN and vise versa. The question is, when are the two applied to a packet? My guess would be that the SEA's defaultid is applied to inbound packets and the Virtual Adapter's PVID is applied to packets leaving the internal switch. I do not see a good explanation of this in any manual or document I have found. Can anyone point me to these details?

Re: SEA defaultid vs. Virtual Adapter PVID

‏2012-10-01T19:41:19Z

This is the accepted answer.
This is the accepted answer.

defaultid is primarily useful in cases where you want to associate multiple virtual Ethernet adapters with the same SEA. This allows you to ignore the PVID on a particular virtual Ethernet adapter while providing full bridging for all of it's 802.1q addl vlans.

Any traffic sent on the PVID of the second virtual Ethernet adapter will reach the VIOS as untagged traffic, but then it will be dropped and not passed on to the external network. Similarly, if untagged traffic comes inbound, the SEA will know to route it to the defaultid PVID instead of any alternative.

Re: SEA defaultid vs. Virtual Adapter PVID

defaultid is primarily useful in cases where you want to associate multiple virtual Ethernet adapters with the same SEA. This allows you to ignore the PVID on a particular virtual Ethernet adapter while providing full bridging for all of it's 802.1q addl vlans.

Any traffic sent on the PVID of the second virtual Ethernet adapter will reach the VIOS as untagged traffic, but then it will be dropped and not passed on to the external network. Similarly, if untagged traffic comes inbound, the SEA will know to route it to the defaultid PVID instead of any alternative.

Thank you for that explanation as I think it has helped me gel a better understanding of the concept of the SEA PVID.

Thinking of a switch, the concept of a port's PVID is simple in that there should not be any untagged packets inside the switch and there is the simple rule that outbound PVID packets are untagged and inbound untagged packets are tagged with PVID.

With the SEA, a switch port (Physical Adapter) is really connected to multiple internal ports (Virtual Adapters), each with a unique PVID. The inbound untagged packets are tagged and forwarded with the SEA's PVID (-defaultid y) to only one (-default entx) of the multiple ports. Since there are multiple internal ports, each with a unique PVID, the outbound untagged packets could originate from any of the Virtual Adapters and not just from the one identified by the SEA's -default. Any of these internal ports could present an untagged packet to the SEA, which would just forward them on to the switch port. This would imply that the outbound untagged packets are the "sum" of all the SEA's Virtual Adapter's PVIDs and not untagged packets from a single internal VLAN.

Summarizing this into a statement, I would say: The SEA's PVID is defined by -default and -defaultid, which identify a specific Virtual Adapter and VLANID for inbound untagged packets. The SEA's PVID is not applied to outbound packets because the SEA's Virtual Adapter's PVIDs have already presented untagged packets to the SEA based on their own PVID. The SEA just forwards these untagged packets on to the Physical Adapter.

This is not to say it would be desirable or even useful to use this behavior in a configuration, but my goal was to define the details of the SEA's treatment of untagged packets in a multiple Virtual Adapter configuration.

Re: SEA defaultid vs. Virtual Adapter PVID

defaultid is primarily useful in cases where you want to associate multiple virtual Ethernet adapters with the same SEA. This allows you to ignore the PVID on a particular virtual Ethernet adapter while providing full bridging for all of it's 802.1q addl vlans.

Any traffic sent on the PVID of the second virtual Ethernet adapter will reach the VIOS as untagged traffic, but then it will be dropped and not passed on to the external network. Similarly, if untagged traffic comes inbound, the SEA will know to route it to the defaultid PVID instead of any alternative.

Amartey wrote, in part --> Any traffic sent on the PVID of the second virtual Ethernet adapter will reach the VIOS as untagged traffic, but then it will be dropped and not passed on to the external network.

Sorry, I have to challenge the last half of the above statement.

IMHO, any outbound destined traffic that reaches the VIO Server will be forwarded to the external network. The presence or absence of VLAN tags is irrelevant at this point. If the outbound destined packet reaches the VIO Server.... the SEA copies the packet to the external network. The VIO Server / SEA does not do filtering.

The external network switch then deals with the validity of the arriving packet.

Re: SEA defaultid vs. Virtual Adapter PVID

Thank you for that explanation as I think it has helped me gel a better understanding of the concept of the SEA PVID.

Thinking of a switch, the concept of a port's PVID is simple in that there should not be any untagged packets inside the switch and there is the simple rule that outbound PVID packets are untagged and inbound untagged packets are tagged with PVID.

With the SEA, a switch port (Physical Adapter) is really connected to multiple internal ports (Virtual Adapters), each with a unique PVID. The inbound untagged packets are tagged and forwarded with the SEA's PVID (-defaultid y) to only one (-default entx) of the multiple ports. Since there are multiple internal ports, each with a unique PVID, the outbound untagged packets could originate from any of the Virtual Adapters and not just from the one identified by the SEA's -default. Any of these internal ports could present an untagged packet to the SEA, which would just forward them on to the switch port. This would imply that the outbound untagged packets are the "sum" of all the SEA's Virtual Adapter's PVIDs and not untagged packets from a single internal VLAN.

Summarizing this into a statement, I would say: The SEA's PVID is defined by -default and -defaultid, which identify a specific Virtual Adapter and VLANID for inbound untagged packets. The SEA's PVID is not applied to outbound packets because the SEA's Virtual Adapter's PVIDs have already presented untagged packets to the SEA based on their own PVID. The SEA just forwards these untagged packets on to the Physical Adapter.

This is not to say it would be desirable or even useful to use this behavior in a configuration, but my goal was to define the details of the SEA's treatment of untagged packets in a multiple Virtual Adapter configuration.

Conceptually I think you have it right. aka we are more or less on the same page, but my view is slightly different from what has been described in this thread.

My understanding goes something like -->

1. the SEA does NOT drop packets. The switches (either the external switches or the internal switch(es) (implemented in the hypervisor)) will drop packets but NOT the SEA itself.

2. the SEA does NOT have a PVID. The SEA is NOT a switch.... the SEA is a relay point between switches. Only ports on a switch have a PVID. A Virtual Ethernet Adapter (defined in the hypervisor) is synonymous with a port & therefore will have a PVID. Setting the PVID and any Additional 802.1q VLAN IDs on the Virtual Ethernet Adapter is therefore critical to your VLAN success.

3. the VLAN implementation had a problem with what to do with ingress packets (i.e. inbound packets received from an external switch) that arrive untagged. One solution --> provide the SEA with the options -default entX -defaultid NNN. This provides the mechanism to copy the ingress packet to a pre-defined Virtual Ethernet Adapter and to tag the packet as VLAN NNN. That's it. The SEA is otherwise VLAN unaware.

The hypervisor will now determine what Virtual Ethernet Adapters get to see this "newly" tagged packet..... OR if no matching Virtual Ethernet Adapter(s), the packet is silently discarded.

4. the SEA does NOT have a problem with any other packets. Tagged ingress packets get forwarded, unaltered. Tagged or untagged egress packets (i.e. outbound packets destined for an external network) arriving at the SEA are forwarded, unaltered, to the external switch, where the external switch deals with them.

We can always dive deeper, but that's the 10,000 ft view of my understanding. If someone has a better understanding, please step up & educate me.

Re: SEA defaultid vs. Virtual Adapter PVID

Conceptually I think you have it right. aka we are more or less on the same page, but my view is slightly different from what has been described in this thread.

My understanding goes something like -->

1. the SEA does NOT drop packets. The switches (either the external switches or the internal switch(es) (implemented in the hypervisor)) will drop packets but NOT the SEA itself.

2. the SEA does NOT have a PVID. The SEA is NOT a switch.... the SEA is a relay point between switches. Only ports on a switch have a PVID. A Virtual Ethernet Adapter (defined in the hypervisor) is synonymous with a port & therefore will have a PVID. Setting the PVID and any Additional 802.1q VLAN IDs on the Virtual Ethernet Adapter is therefore critical to your VLAN success.

3. the VLAN implementation had a problem with what to do with ingress packets (i.e. inbound packets received from an external switch) that arrive untagged. One solution --> provide the SEA with the options -default entX -defaultid NNN. This provides the mechanism to copy the ingress packet to a pre-defined Virtual Ethernet Adapter and to tag the packet as VLAN NNN. That's it. The SEA is otherwise VLAN unaware.

The hypervisor will now determine what Virtual Ethernet Adapters get to see this "newly" tagged packet..... OR if no matching Virtual Ethernet Adapter(s), the packet is silently discarded.

4. the SEA does NOT have a problem with any other packets. Tagged ingress packets get forwarded, unaltered. Tagged or untagged egress packets (i.e. outbound packets destined for an external network) arriving at the SEA are forwarded, unaltered, to the external switch, where the external switch deals with them.

We can always dive deeper, but that's the 10,000 ft view of my understanding. If someone has a better understanding, please step up & educate me.

I need to retract part of this statement..... since I can't edit my previous post, I'll eat some crow & correct myself.

I had a chance to do some testing this afternoon and noticed that the VIO Server / SEA is aware of the valid VLAN ID's carried on its own Virtual Ethenet Adapter(s).

From the command -> entstat -all entX <- where entX = the SEA, you'll notice numerous stats, including the valid VLAN ID's. For example.... here's a snippet, where the Virtual Ethernet Adapter is defined with PVID 1 and Additional VLAN IDs of 2068 and 2069 :

Not much.... my guess is any broadcast ingress traffic gets copied to all Virtual Ethernet Adapters that make up the SEA and have a matching VLAN ID .....

..... once the correct MAC address is known & (assuming the SEA maintains a MAC address table) is populated in the SEA's MAC address table..... future ingress traffic would be directed to the correct Virtual Ethernet Adapter.

egress traffic is probably managed in much the same way.

I think we sort of knew this..... just didn't see it stated anywhwere.

Speculation off:

The_Doctor wrote, in part -> The SEA is otherwise VLAN unaware.

I need to retract part of this statement..... since I can't edit my previous post, I'll eat some crow & correct myself.

I had a chance to do some testing this afternoon and noticed that the VIO Server / SEA is aware of the valid VLAN ID's carried on its own Virtual Ethenet Adapter(s).

Not much.... my guess is any broadcast ingress traffic gets copied to all Virtual Ethernet Adapters that make up the SEA and have a matching VLAN ID .....

..... once the correct MAC address is known & (assuming the SEA maintains a MAC address table) is populated in the SEA's MAC address table..... future ingress traffic would be directed to the correct Virtual Ethernet Adapter.

egress traffic is probably managed in much the same way.

I think we sort of knew this..... just didn't see it stated anywhwere.

Not much.... my guess is any broadcast ingress traffic gets copied to all Virtual Ethernet Adapters that make up the SEA and have a matching VLAN ID .....

..... once the correct MAC address is known & (assuming the SEA maintains a MAC address table) is populated in the SEA's MAC address table..... future ingress traffic would be directed to the correct Virtual Ethernet Adapter.

egress traffic is probably managed in much the same way.

I think we sort of knew this..... just didn't see it stated anywhwere.

1) Untagged ingress traffic (coming into the system from outside) will flow only to the default virtual Ethernet adapter using its PVID. On any given SEA, a vlan ID (or PVID) can only be trunked once (with the same priority), so the untagged packet always has a very defined place to go.

2) Untagged egress traffic (coming from inside the system to the outside) is only forwarded on if it comes from the default virtual Ethernet adapter. Any untagged traffic from other virtual Ethernet adapters will not be forwarded out of the system.

I think The_Doctor and I concur on #1 above. I've been meaning to actually test #2 above but haven't been able to find the time. I did however verify that this was the case theoretically with the SEA development team. Testing this though should be very easy to do. Simply attach a second virtual Ethernet adapter with it's own unique PVID to the SEA, and then create a client LPAR on the same PVID - can it reach the outside world (keeping in mind ingress packets won't arrive given #1).

So the question comes - why would you want > 1 virtual Ethernet adapters associated with a given SEA? The primary answer is Load Balancing - if you have 2 VIOSs, each one can act as the primary for a given virtual Ethernet adapter, while still providing SEA failover capability. There are of course other reasons - for example, until recently, you couldn't modify the list of Addl VLANs associated with a given virtual Ethernet adapter.

Re: SEA defaultid vs. Virtual Adapter PVID

1) Untagged ingress traffic (coming into the system from outside) will flow only to the default virtual Ethernet adapter using its PVID. On any given SEA, a vlan ID (or PVID) can only be trunked once (with the same priority), so the untagged packet always has a very defined place to go.

2) Untagged egress traffic (coming from inside the system to the outside) is only forwarded on if it comes from the default virtual Ethernet adapter. Any untagged traffic from other virtual Ethernet adapters will not be forwarded out of the system.

I think The_Doctor and I concur on #1 above. I've been meaning to actually test #2 above but haven't been able to find the time. I did however verify that this was the case theoretically with the SEA development team. Testing this though should be very easy to do. Simply attach a second virtual Ethernet adapter with it's own unique PVID to the SEA, and then create a client LPAR on the same PVID - can it reach the outside world (keeping in mind ingress packets won't arrive given #1).

So the question comes - why would you want > 1 virtual Ethernet adapters associated with a given SEA? The primary answer is Load Balancing - if you have 2 VIOSs, each one can act as the primary for a given virtual Ethernet adapter, while still providing SEA failover capability. There are of course other reasons - for example, until recently, you couldn't modify the list of Addl VLANs associated with a given virtual Ethernet adapter.

How do you want to create "Untagged egress traffic (coming from inside the system to the outside) " ?
You cannot send untagged pakets from an LPAR. How should the hypervisor switch and especially SEAs handle this?
A ethernet paket coming from a LPAR always has a vlan-tag. Be it a 802.1q capable adapter (that can handle more than 1 VLAN) or not. In the latter case it will have its port-vlan-id.

Re: SEA defaultid vs. Virtual Adapter PVID

How do you want to create "Untagged egress traffic (coming from inside the system to the outside) " ?
You cannot send untagged pakets from an LPAR. How should the hypervisor switch and especially SEAs handle this?
A ethernet paket coming from a LPAR always has a vlan-tag. Be it a 802.1q capable adapter (that can handle more than 1 VLAN) or not. In the latter case it will have its port-vlan-id.

-----vlan 1--------
The OS in both LPARs is blissfully VLAN unaware. It doesn't understand or care about VLANs and tagged packets. It puts data into it's vEth adapter as untagged. As it transports through PHYP it gets tagged to allow PHYP to ensure that it doesn't appear on any other VLAN other than 1. But once it reaches the other side, it will get untagged again as it comes out of the vEth with a PVID of 1.

-----vlan 1--------
In this environment, LPAR1 is still vlan unaware. LPAR2 however must create a pseudo VLAN device that understands tagged packets in order to communicate on VLAN 1. It can communicate untagged on VLAN 2 since that is it's PVID, however all VLAN 1 traffic that lpar 2 receives/sends will be tagged.

Re: SEA defaultid vs. Virtual Adapter PVID

‏2012-10-22T13:21:20Z

This is the accepted answer.
This is the accepted answer.

I went away to a deep dark place for a long time. I started an "iptrace" and "trace" (with IP/adapter/SEA trace points) in the VIOS and pinged a VIOC. I can see what appear to be VLAN decisions occurring when the packets originate on the SEA's interface (en device) and enter the SEA. This seems to answer my initial question. My confusion was based on the network diagrams that show the en interface hung off the SEA. That would make one think the en device was somehow "inside" the trunk. With the trace results I have seen it would appear that the en interface acts like a VLAN port itself. When a packet enters the SEA from the en interface, a forwarding decision is made independent of the internal VLAN and the packet forwarded. The SEA trace also allows one to see the bridged traffic, although in a very cryptic and indirect manner.

Independent of this question, my experiment showed occasional ping DUP replies. The trace showed that an occasional ping request would be flooded (sent out real & virtual adapters) and the switch would forward the real adapter request back to the SEA, who would then bridge it to the VIOC and that reply would be the DUP. I don't own the VIOS, so I will have to see if there is interest in looking closer at that issue, but using and IBM PMR.