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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
