port configurable external_pcp_override

[grafnu]

Sorry this is kinda two issues in one, but they potentially have the same fix so wanted to discuss them together.

1. Currently the pcp vlan field is "leaked" externally for outgoing packets through a tagged vlan port when loop_protect_external is set. Sometimes it's 0, other times it's 2 -- which might cause problems with external networked systems that interpret this value somehow.
2. Since STP is not part of Faucet, if lacp/LAG is not in use, an externally broadcast packet (e.g. ARP) on a loop_protect_external port might be looped back in through another loop_protect_external port, which then gets broadcast back out the originating port. This results in the sending device receiving a reflected copy of its own broadcast packet, which would be bad.

I'm proposing a new field "external_pcp_override" or equivalent that forces any egress packet on a loop_protect_external port to set the pcp value accordingly. This achieves two functions:

1. Where the external system cares about the pcp value, this can be forced to a neutral value (e.g. 0) that is handled accordingly.
2. If the packet is looped back by the external network, a port-in ACL rule could be created to discard a packet with the indicated VLAN PCP.

#2 would of course have problems if the external network was using the PCP value in some specific way, but that would be external-network dependent and isolated from anything internal to faucet.

Thoughts? Looking for guidance here, and then I can code up the needful.

[anarkiwi]

At the moment yes the parameter is preserved (e.g. you might have two FAUCET stacks under the control of different controllers and configs connected together). So yes an additional port parameter to cause the PCP field to be reset to a configurable value absolutely make sense.

[grafnu]

As per #3302, the "use PCP for loop protection outside of Faucet" was deemed a Bad Idea (TM), but this leaking/override still applies to case 1 (forcing neutral value).