sflow, pstag, and order of packet operations.

[Nishal_Goburdha]

hi,

(hardware = x670g2; software = 16.1.4.2-patch1-3)

i'm looking for some validation of whether this is a feature, or a bug, please.
we have several ports that have pstag(s) enabled, eg:

configure vlan bob tag 100
configure vlan jane tag 101

configure vlan bob add ports 1 tagged 11
configure vlan jane add ports 1 tagged 12

we export sampled, ingress sflow, on a per port basis.
in our case, the goal is to approximate mac-address to mac-address in/out bytes.

our collector sees the export fine, however, the vlan-id in the export reads, either as 11 or 12, and not bob or jane. for our purposes, we'd prefer that this be in the "destination" vlan (ie. bob / jane).
so i'm guessing that sflow export is done _before_ processing of the packet/frame, since, the "source" vlan appears to be the one listed.

we can work around this with a software hack, but i'd really prefer not to. so, before effecting any such workarounds, i thought i'd ask:
# if this is known and intentional?
# what the order of operations on the packet would be, in the _egress_ direction (ie. if i changed the way i collected sflow export)
# if this is standard across other extreme switching gear (specifically x690, x870, and the newer SLX gear)

pointers to relevant documentation would be really helpful.

[Nishal_Goburdha]

hi,

thanks for the answer. i did not mean to imply that this is not correct; i'm curious about implementation - ie. order of packet operations - so that we can adopt and code, a standard approach. is there maybe a reference to this (order of packet operations) somewhere?

our specific need is to be able to see traffic from a set of mac addresses, within a particular vlan (bob or jane) so the c-tag, as we're seeing is, it less than ideal, since there may be _many_ of those.

[StephenW]

I would expect this to be correct behavior as it captures the raw packet header that is to be sent. Looking at RFC 3176 it doesn't document the scenario you mention.