[c-nsp] 7609 ES+, WS marking behaviour

Victor Lyapunov victor.lyapunov at gmail.com
Wed Apr 9 03:03:14 EDT 2014


Hello Tony and thank you for the input

Unfortunately I can not get rid of the Port-Channel in my setup, byt still
performed the test with:

physical-interface: GigE interface / switchport
Logical-interface: SVI

And got the same results though. I can not though understand the
behaviour of ES+ regarding mls in a scenario with a box with mixed
cards (ES+ & WS_67xx)

The output for a show mls qos queuing for an ES+ interface (in
switchport) depicts the

port as untrusted


#sh mls qos queuing interface tenGigabitEthernet 4/1
 Weighted Round-Robin
  Port QoS is enabled
  Port is untrusted
  Extend trust state: not trusted [COS = 0]
  Default COS is 0


#show tcam interface te 4/1 qos type1 ip

* Global Defaults not shared

------------------------------------------------------
QOS Results:
A - Aggregate Policing       F - Microflow Policing
M - Mark                     T - Trust
U - Untrust
------------------------------------------------------

>From this output does it means that the internal DSCP value assigned
to the packet

will be 0 and so an ip packet arriving in an ES+ cardfor a destination
behind WS_67xx

will have both DSCP=0 and 802.1p = 0?

(from what I have seen only 802.1p = 0, DSCP is unchanged)



Thanx Victor




> Hi Victor,
>
> Is it possible to use an ingress policy on the ES card to match the DSCP
> values and explicitly set the 802.1p value based on matching the
> corresponding DSCP ? This way you will know that it is set and not
> expecting it happen by the PFC/DFC as part of the egress qos on the line
> card.
>
> It is also possible that having a port-channel as the logical egress
> interface is causing some problem, have you tried it without the
> port-channel ? Port-channels do strange things with QoS in general.
>
>
> regards,
> Tony.
>
>
>
>> On Mon, 07 Apr 2014 07:08:11 +1000, Victor Lyapunov
>> <victor.lyapunov at gmail.com <https://puck.nether.net/mailman/listinfo/cisco-nsp>> wrote:
>>
>>* Have not correcty described the setup:
*>>>>* (egress) Physical : Portchannel Switch port belonging to a WS_6724 card
*>>* (egress) Logical : SVI interface (802.1q encapsulation) for L3
*>>* termination
*>>>>* (ingress) Physical / Logical: Routed interface belonging to a ES+ card
*>>* (no
*>>* 802.1q encapsulation)
*>>>>* We see that traffic that is forwarded through the WS card has 802.1p = 0
*>>* regardless of dscp value
*>>* But If theout going interface is also in a ES+ card then the output
*>>* 802.1p
*>>* corresponds to the packets DSCP value
*>>>>* In ES+ a L3 interface is Dscp tust, was mistaken earlier. Indeed this
*>>* value
*>>* is retained (we see it in the corresponding
*>>* output packets of the WS card) but the derived 802.p =0. Need to find a
*>>* way
*>>* to make this derived 802.1p value to
*>>* correspond to the packet's DSCP when the egress interface belongs to a
*>>* WS_67xx card
*>>


More information about the cisco-nsp mailing list