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 On Sun, Apr 6, 2014 at 11:43 PM, Victor Lyapunov <[email protected]>wrote: > Hello > > Have a question about 7609/RSP720 platform marking operation with mixed > linecard types. In the setup we are testing uplinks are > implemented in ES+ while customer facing interfaces in WS cards. > > The egress traffic is forwarded out of the WS cards through a Port-channel > interface switchport with 802.1q encapsulation (SVI interface) > We would like to be able to have the 802.1p values correspond to the DSCP > of the ip packets. > > Normally for a WS_Card the 802.1p (CoS) value is generated based on the > internal DSCP value of the packets (PFC based). I am not > sure what is the case when the ingress interface belongs to an ES+ card? > (Is an ES+ interface considered untrusted so internal > dscp = 0 always?) > > Currently focused on mls qos commands to solve this but no luck so far. Is > this course of action a dead end? > > Thanks for your help > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
