From: Niche (jackyliu419@gmail.com)
Date: Mon Sep 04 2006 - 08:26:48 ART
Hi Petr,
I found another different between mine and your configuration. The
tunnel source was bound on interface (yours) or bound on interface's
ip address (mine).. anyone know would that make a different?
Cheers~
Jacky
On 9/4/06, Niche <jackyliu419@gmail.com> wrote:
> 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