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

[Thomas Sillaber]

Hi Victor,

the ES+ does not use pfc qos (mls qos commands). Qos in handled locally on
the lc. Per Default without marking configuration the ES+ should act in
"trust dscp" mode. The ingress ES+ should set dbus-cos to inform pfc about
cos values. Without ingress COS in case of routed interface you can try to
set the cos values (or dbus_cos) on ingress:

"The ES+ line card marks a packet as trust cos when ingress marking for CoS
is configured for a routed interface. Hence, the CoS value configured using
the set cos value command is retained on the outgoing packet. This cos value
is not overwritten by earl or derived from dscp."

Hope this helps

Thomas

-----Ursprüngliche Nachricht-----
Von: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von
Victor Lyapunov
Gesendet: Mittwoch, 9. April 2014 09:03
An: cisco-nsp
Betreff: Re: [c-nsp] 7609 ES+, WS marking behaviour

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
*>>
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/