Pinned topicSEA Interface Packet Forwarding

‏2012-10-04T20:13:11Z
|Tags:

Answered question
This question has been answered.

Unanswered question
This question has not been answered yet.

Based on my previous question, I understand the packet forwarding for a SEA to be that all external inbound untagged is sent to "-default entx -defaultid y" and all internal VLAN inbound untagged (and tagged) is forwarded across the trunk link even if there are multiple Virtual Adapters with different PIVDs feeding the SEA. This is ignoring configurations where untagged packets are deliberately dropped by sending them to unused VLANs.

This brought up the question of where the SEA's interface packets enter the flow. Since it seems the SEA is outside of the internal VLANs and outside the switch's VLANs. What determines where the SEA's interface's packets go? My understanding is that the interface on the SEA is not a member of a specific VLAN, but part of the untagged traffic that flows on the trunk link.

Does SEA interface traffic only flow across the trunk to the switch or can it enter the internal VLAN.

Does this imply that an interface can be configured (and used from an external system) on a SEA only if the trunk link is configured for untagged traffic?

Re: SEA Interface Packet Forwarding

My understanding is that the interface on the SEA is not a member of a specific VLAN, but part of the untagged traffic that flows on the trunk link.

Not really. The SEA is quite capable of handling tagged / untagged traffic simultaneously. There may be some upper limits (like 20 different VLAN IDs) that I haven't tested... but using a handful of different VLAN IDs, there is no problem.

Any interfaces you choose to build / configure on top of the SEA will have to be configured to handle the expected traffic (untagged or tagged). So it depends how you build / configure EACH interface on top of the SEA.

The default enX interface will handle all untagged traffic. Tagged traffic will require:

mkvdev -vlan entX -tagid NNNN entY Available enY Available etY Available ....................then use enY to access the tagged traffic. Repeat as necessary
for additional VLAN IDs.

Most don't build interfaces on the SEA..... but the choice is yours.

Does SEA interface traffic only flow across the trunk to the switch or can it enter the internal VLAN.

Traffic originating from interfaces configured on top of the SEA can flow in all directions..... to external switches or internal switches.

Does this imply that an interface can be configured (and used from an external system) on a SEA only if the trunk link is configured for untagged traffic?

No..... the phrase "only if" does not apply. Traffic can be tagged or untagged.....BUT it is up to you to configure the interface(s) to handle the traffic accordingly.

My understanding is that the interface on the SEA is not a member of a specific VLAN, but part of the untagged traffic that flows on the trunk link.

Not really. The SEA is quite capable of handling tagged / untagged traffic simultaneously. There may be some upper limits (like 20 different VLAN IDs) that I haven't tested... but using a handful of different VLAN IDs, there is no problem.

Any interfaces you choose to build / configure on top of the SEA will have to be configured to handle the expected traffic (untagged or tagged). So it depends how you build / configure EACH interface on top of the SEA.

The default enX interface will handle all untagged traffic. Tagged traffic will require:
<pre class="jive-pre">
mkvdev -vlan entX -tagid NNNN entY Available enY Available etY Available ....................then use enY to access the tagged traffic. Repeat as necessary
for additional VLAN IDs.
</pre>
Most don't build interfaces on the SEA..... but the choice is yours.

Does SEA interface traffic only flow across the trunk to the switch or can it enter the internal VLAN.

Traffic originating from interfaces configured on top of the SEA can flow in all directions..... to external switches or internal switches.

Does this imply that an interface can be configured (and used from an external system) on a SEA only if the trunk link is configured for untagged traffic?

No..... the phrase "only if" does not apply. Traffic can be tagged or untagged.....BUT it is up to you to configure the interface(s) to handle the traffic accordingly.

Re: SEA Interface Packet Forwarding

Re: SEA Interface Packet Forwarding

‏2013-01-24T21:48:57Z

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

As mentioned above, I had observed duplicate ping replies when pinging out from the VIOS on a SEA interface. I opened a PMR and it turned into an APAR. IBM found that the forwarding table hashing process was hashing two different MAC addresses into the same forwarding table entry and losing the previous entry. The spin-off from this was I asked if this was a forwarding table unique to SEA interface (en* device) packets and was told it was. This answers my initial question, there is a forwarding table unique to just SEA interface traffic. There are also forwarding table in the hypervisor virtual switches, but the SEA interface has its own special forwarding table.

Re: SEA Interface Packet Forwarding

As mentioned above, I had observed duplicate ping replies when pinging out from the VIOS on a SEA interface. I opened a PMR and it turned into an APAR. IBM found that the forwarding table hashing process was hashing two different MAC addresses into the same forwarding table entry and losing the previous entry. The spin-off from this was I asked if this was a forwarding table unique to SEA interface (en* device) packets and was told it was. This answers my initial question, there is a forwarding table unique to just SEA interface traffic. There are also forwarding table in the hypervisor virtual switches, but the SEA interface has its own special forwarding table.