Hi, A few ideas - don't know if they will work for you:
1) Have you considered or verified if local switching is available on this router/IOS? This would allow you to "connect" the two interfaces together - essentially bridging them, though I believe there is no mac learning with local switching, so it would just forward the packets, not learn destination macs. 2) Regarding the QoS - I've seen some cases where you need to put the policy-map on the main interface. This was on a GSR and a particular linecard - but may be worth a try. It could just be it won't work properly with the way your doing bridging. 3) Have you done any debugs? On Wed, May 4, 2011 at 7:11 PM, Robert Johnson <[email protected]>wrote: > IOS 12.4 advanced enterprise on a 3745. I have two fast ethernet > interfaces, each with a set of 802.1q subinterfaces. Each subinterface > has a bridge-group assigned to it so that select VLANS on each FE port > are bridged. I'd like to apply a policy-map to one of the outbound > subinterfaces that looks at the DSCP value of outbound IP packets and > sets an 802.1p COS according to the DSCP value found. Here's the > relevant part of the configuration: > > > class-map match-all assure > match ip dscp af31 > class-map match-all critical > match ip dscp cs6 > class-map match-all expedite > match ip dscp ef > ! > policy-map output-cos > class expedite > set cos 6 > class assure > set cos 5 > class critical > set cos 7 > ! > interface FastEthernet1/0 > description Trunk to switch 1 > no ip address > full-duplex > ! > interface FastEthernet1/0.500 > encapsulation dot1Q 500 > bridge-group 100 > service-policy output output-cos > ! > interface FastEthernet2/0 > description trunk to cheverly-md-s1b > no ip address > full-duplex > ! > interface FastEthernet2/0.500 > description Customer access > encapsulation dot1Q 500 > bridge-group 100 > service-policy output output-cos > ! > interface BVI100 > ip address x.x.x.x y.y.y.y > ip verify unicast reverse-path > ! > bridge 100 protocol ieee > bridge 100 route ip > > > The policy-map can't be applied to the BVI since it's not handling > VLAN tagging. However, the above configuration doesn't pick up any of > the traffic marked with the DSCPs specified in the class-map: > > #sho policy-map int f1/0.500 > FastEthernet1/0.500 > > Service-policy output: output-cos > > Class-map: expedite (match-all) > 0 packets, 0 bytes > 5 minute offered rate 0 bps, drop rate 0 bps > Match: ip dscp ef (46) > QoS Set > cos 6 > Packets marked 0 > > Class-map: assure (match-all) > 0 packets, 0 bytes > 5 minute offered rate 0 bps, drop rate 0 bps > Match: ip dscp af31 (26) > QoS Set > cos 5 > Packets marked 0 > > Class-map: critical (match-all) > 0 packets, 0 bytes > 5 minute offered rate 0 bps, drop rate 0 bps > Match: ip dscp cs6 (48) > QoS Set > cos 7 > Packets marked 0 > > Class-map: class-default (match-any) > 4380 packets, 297206 bytes > 5 minute offered rate 0 bps, drop rate 0 bps > Match: any > > Also, the class-default class does not seem to be counting in tune > with the actual traffic flowing across the subinterface. > > This configuration works if the BVI is removed and IP addresses are > assigned directly to the subinterfaces. Unfortunately this is not a > practical solution due to other design considerations. > > Ideas? TIA. > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
