From: Niche (jackyliu419@gmail.com)
Date: Mon Sep 04 2006 - 10:46:40 ART
Hi Sean,
Thanks for the information, guess I should take that into the
consideration.. polly need a test. Hopefully can post the result soon.
Cheers~
Jacky
On 9/5/06, Sean C. <Upp_and_Upp@hotmail.com> wrote:
> Hi Jacky,
>
> I can't confirm if it made a difference in your scenario, but I have seen
> some instances where applying an IP addy for as a tunnel source has caused
> different results than applying a source interface.
>
> Sean
> ----- Original Message -----
> From: "Niche" <jackyliu419@gmail.com>
> To: "Petr Lapukhov" <petr@internetworkexpert.com>
> Cc: <ccielab@groupstudy.com>
> Sent: Monday, September 04, 2006 4:26 AM
> Subject: Re: The doubt about "qos-preclassify" command
>
>
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:39 ART