From: Niche (jackyliu419@gmail.com)
Date: Sun Sep 03 2006 - 22:16:17 ART
Hi Petr,
Strange, our configuration look similar indeed... however, ACL hit
count and "show policy-map interface " issues are really confusing me.
My IOS version is 12.3(6a).
Anyway, thanks alot for the configuration sample!
Cheers~
Jacky
On 9/3/06, Petr Lapukhov <petr@internetworkexpert.com> wrote:
>
> Here is a sample configuration. I hope formatting won't die out :)
>
> -------------------------
>
> R4 and R5 are connected via FR cloud with DLCIs 405/504.
>
> R4 is connected via subinterface Serial 0/0.1245.
>
> Tunnel0 is used to tunnel traffic between VLAN4 to VLAN5 over
> FR (VLAN4: 10.4.4.0/24 <-> VLAN5: 10.5.5.0/24).
>
> The goal is to provide priority treatment of ICMP traffic between
> VLAN4 and VLAN5. MQC FRTS is used on subinterface.
>
> R4:
>
>
>
> interface Tunnel0
> tunnel source Loopback0
> tunnel destination 150.1.5.5
> ip address 45.45.45.4 255.255.255.0
> !
> ip access-list extended VLAN4_TO_VLAN5
> permit icmp 10.4.4.0 0.0.0.255 10.5.5.0 0.0.0.255
> !
> class-map VPN_ICMP
> match access-group name VLAN4_TO_VLAN5
> !
> policy-map VPN_QOS
> class VPN_ICMP
> priority 16
> !
> policy-map POLICY_TO_R5
> class class-default
> shape average 64000
> service-policy VPN_QOS
> !
> map-class frame-relay PVC_405
> service-policy output POLICY_TO_R5
> !
> interface Serial 0/0.1245
> frame-relay class PVC_405
> !
> interface Tunnel0
> qos pre-classify
>
> Verification:---------------------------------
>
>
>
> Rack1R4#ping 10.5.5.5 source 10.4.4.4 repeat 100
>
>
>
> Type escape sequence to abort.
>
> Sending 100, 100-byte ICMP Echos to 10.5.5.5, timeout is 2 seconds:
>
> Packet sent with a source address of 10.4.4.4
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> Success rate is 100 percent (100/100), round-trip min/avg/max = 72/72/92 ms
>
>
>
> Rack1R4#show policy-map interface serial 0/0.1245
>
> Serial0/0.1245: DLCI 405 -
>
>
>
> Service-policy output: POLICY_TO_R5
>
>
>
> Class-map: class-default (match-any)
>
> 102 packets, 12964 bytes
>
> 5 minute offered rate 2000 bps, drop rate 0 bps
>
> Match: any
>
> Traffic Shaping
>
> Target/Average Byte Sustain Excess Interval Increment
>
> Rate Limit bits/int bits/int (ms) (bytes)
>
> 64000/64000 2000 8000 8000 125 1000
>
>
>
> Adapt Queue Packets Bytes Packets Bytes Shaping
>
> Active Depth Delayed Delayed Active
>
> - 0 102 12964 0 0 no
>
>
>
> Service-policy : VPN_QOS
>
>
>
> Class-map: ICMP (match-all)
>
> 100 packets, 12800 bytes
>
> 5 minute offered rate 2000 bps, drop rate 0 bps
>
> Match: access-group name VLAN4_TO_VLAN5
>
> Queueing
>
> Strict Priority
>
> Output Queue: Conversation 24
>
> Bandwidth 16 (kbps) Burst 400 (Bytes)
>
> (pkts matched/bytes matched) 0/0
>
> (total drops/bytes drops) 0/0
>
>
>
> Class-map: class-default (match-any)
>
> 2 packets, 164 bytes
>
> 5 minute offered rate 0 bps, drop rate 0 bps
>
> Match: any
>
>
> Rack1R4#show interfaces tunnel 0
>
> Tunnel0 is up, line protocol is up
>
> Hardware is Tunnel
>
> Internet address is 45.45.45.4/24
>
> MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
>
> reliability 255/255, txload 28/255, rxload 28/255
>
> Encapsulation TUNNEL, loopback not set
>
> Keepalive not set
>
> Tunnel source 150.1.4.4 (Loopback0), destination 150.1.5.5
>
> Tunnel protocol/transport GRE/IP
>
> Key disabled, sequencing disabled
>
> Checksumming of packets disabled
>
> Tunnel TTL 255
>
> Fast tunneling enabled
>
> Tunnel transmit bandwidth 8000 (kbps)
>
> Tunnel receive bandwidth 8000 (kbps)
>
> Last input 00:00:08, output 00:00:08, output hang never
>
> Last clearing of "show interface" counters never
>
> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 3
>
> Queueing strategy: fifo (QOS pre-classification)
>
> Output queue: 0/0 (size/max)
>
> 5 minute input rate 1000 bits/sec, 1 packets/sec
>
> 5 minute output rate 1000 bits/sec, 1 packets/sec
>
> 614 packets input, 75464 bytes, 0 no buffer
>
> Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
>
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
>
> 615 packets output, 75540 bytes, 0 underruns
>
> 0 output errors, 0 collisions, 0 interface resets 0 output buffer
> failures, 0 output buffers swapped out
>
> Petr Lapukhov, CCIE #16379
> petr@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987
> Outside US: 775-826-4344
>
> ----- Original Message -----
> From: "Niche" <jackyliu419@gmail.com>
> To: "Petr Lapukhov" <petr@internetworkexpert.com>
> Cc: <ccielab@groupstudy.com>
> Sent: Sunday, September 03, 2006 6:36 PM
> Subject: Re: The doubt about "qos-preclassify" command
>
> > Hi Petr,
> >
> > So, you mean I should get hit count increase for the matching ACL,
> > right? If that's the case, would you mind sharing a sample
> > configuration so I can count check mine.
> >
> > Thanks alot!
> >
> > Best Regards,
> > Jacky
> >
> > On 9/3/06, Petr Lapukhov <petr@internetworkexpert.com> wrote:
> >> I tried QoS pre-classify in my labs (GRE Tunnel, IPsec,
> Virtual-Templates),
> >> and it worked seamlessly with physical interfaces as well as with
> logical
> >> subinterfaces.
> >>
> >> The only problem I once had on 12.3(14)T 3640 is that QoS Pre-Classify
> >> didn't work with CEF enabled ;)
> >>
> >> HTH
> >>
> >> 2006/9/3, Niche <jackyliu419@gmail.com>:
> >> >
> >> Hi guys,
> >>
> >> The command should be "qos pre-classify", my mistake =P
> >>
> >> Cheers~
> >> Jacky
> >>
> >> On 9/3/06, Niche <jackyliu419@gmail.com> wrote:
> >> > Hi guys,
> >> >
> >> > Two sites are being connected via GRE tunnel, and using OSPF for
> >> > routing information exchange.
> >> >
> >> > Requirement - QoS for traffic control but many of you may already know
> >> > there are not much QoS can do to the GRE tunnel. So I used
> >> > "qos-preclassify" command on the tunnel interface and configure
> >> > appropriate QoS configuration in the service policy for the physical
> >> > interfaces at both sites. The matching method is simple access-group
> >> > with protocol type and ip addresses, and here come the odd...
> >> >
> >> > When I check the hit count of the ACLs that are being used by the
> >> > service policy, the number is zero. I am sure there are matching
> >> > traffic types passing throught the interface, so it make me wonder
> >> > what's wrong.
> >> >
> >> > Ok, according to Cisco web information, only term "physical interface"
> >> > is mentioned in the article. So, how about logical interface? e.g.
> >> > multilink interface, FR sub-interface..etc. I confess that the service
> >> > policies for both of sites are being bound on logical interfaces
> >> > instead of physical one.
> >> >
> >> > Cheers~
> >> > Jacky
> >>
> >>
> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >>
> >> --
> >> Petr Lapukhov, CCIE #16379
> >> petr@internetworkexpert.com
> >>
> >> Internetwork Expert, Inc.
> >> http://www.InternetworkExpert.com
> >> Toll Free: 877-224-8987
> >> Outside US: 775-826-4344
This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:39 ART