From: HP-France,ex2 ("SANCHEZ-MONGE,ANTONIO)
Date: Sun Mar 21 2004 - 13:51:50 GMT-3
Hi Ken,
Well... My tests behave differently. In my case, standard ping and telnet
packets DO get classified. Have a look at the test below:
Rack1R2#sh ip route 130.1.26.6
Routing entry for 130.1.26.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 100
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/0
Route metric is 0, traffic share count is 1
Rack1R2#sh policy-map interface
FastEthernet0/0
Service-policy output: test
Class-map: telnet (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 100
Queueing
Output Queue: Conversation 265
Bandwidth 100 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: ping (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 101
Queueing
Output Queue: Conversation 266
Bandwidth 100 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
2 packets, 134 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Rack1R2#
Rack1R2#
Rack1R2#telnet 130.1.26.6
Trying 130.1.26.6 ... Open
User Access Verification
Password:
Password:
Password:
% Bad passwords
[Connection to 130.1.26.6 closed by foreign host]
Rack1R2#sh policy-map interface
FastEthernet0/0
Service-policy output: test
Class-map: telnet (match-all)
15 packets, 909 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 100
Queueing
Output Queue: Conversation 265
Bandwidth 100 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 15/909
(depth/total drops/no-buffer drops) 0/0/0
Class-map: ping (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 101
Queueing
Output Queue: Conversation 266
Bandwidth 100 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
9 packets, 624 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Rack1R2#ping 130.1.26.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 130.1.26.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Rack1R2#sh policy-map interface
FastEthernet0/0
Service-policy output: test
Class-map: telnet (match-all)
15 packets, 909 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 100
Queueing
Output Queue: Conversation 265
Bandwidth 100 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 15/909
(depth/total drops/no-buffer drops) 0/0/0
Class-map: ping (match-all)
5 packets, 570 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 101
Queueing
Output Queue: Conversation 266
Bandwidth 100 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 5/570
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
13 packets, 906 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Rack1R2#
Cheers,
Ato.
-----Original Message-----
From: Kenneth Wygand [mailto:KWygand@customonline.com]
Sent: domingo, 21 de marzo de 2004 17:39
To: Marko Berend; ccielab@groupstudy.com
Subject: RE: Service-policy from the router (Answer Here!)
Richard, Marko and Group,
You have missed an item of critical importance when applying QoS or Access
Lists/Groups to locally originating traffic...
In Marko's example, his tests were "telnet" for which the router will SOURCE
the originating traffic AT the interface which it is sending out the packet.
The order in which packets are processed within the router cause the packet
to actually subvert the access list (or QoS) check on that interface. When
you apply access lists or QoS "out" and interface, it really only applies to
traffic that is FORWARDED out that interface, not ORIGINATING out that
interface. Thus the reason for the "ip local policy" command, which will
"catch" all of the ORIGINATED packets sent out ANY interface by design.
Now if you look, in Richard's example, his extended ping sourced the traffic
from the loopback0 interface. As a result, access-lists and QoS applied
"out" on the interface WILL take effect, because the traffic is actually now
FORWARDED out that interface, not ORIGINATING out it.
Richard - take your example and do a standard ping - you will see your
traffic will NOT be classified.
Marko - take your example and source the traffic from another interface on
the router - you will see that your traffic WILL be classified.
Hope this helps!! :)
Ken
-----Original Message-----
From: nobody@groupstudy.com on behalf of Marko Berend
Sent: Sat 3/20/2004 4:56 AM
To: ccielab@groupstudy.com
Cc:
Subject: RE: Service-policy from the router
class-map match-all telnet
match access-group 103
!
policy-map test
class telnet
set ip precedence 7
!
interface FastEthernet0/0
ip address 139.10.45.4 255.255.255.0
service-policy output test
------------------------
The result:
R4#telnet 139.10.11.11
Trying 139.10.11.11 ...
% Connection refused by remote host
(this is telnet via f0/0)
R4#sh access-lists
Extended IP access list 103
permit tcp any any eq telnet (1 match)
R4#sh policy-map int f0/0
FastEthernet0/0
Service-policy output: test
Class-map: telnet (match-all)
1 packets, 60 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 103
QoS Set
ip precedence 7
Packets marked 0
Class-map: class-default (match-any)
18 packets, 1228 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
As you can see NO packets marked, yet 1 hit in the access list.
-----Original Message-----
From: Richard Dumoulin [mailto:richard.dumoulin@vanco.es]
Sent: Saturday, March 20, 2004 10:36 AM
To: Marko Berend; ccielab@groupstudy.com
Subject: RE: Service-policy from the router
Just an idea. NBAR uses cef, so could you just use an acl to
match your
interesting traffic and see if it works ?
--Richard
-----Mensaje original-----
De: Marko Berend [mailto:marko.berend@storm.hr]
Enviado el: sabado, 20 de marzo de 2004 10:32
Para: ccielab@groupstudy.com
Asunto: RE: Service-policy from the router
Robert,
This does not work either.
My packet decodings look like this:
Type of Service: %00000000
BTW why input when the router is generating the traffic and
sending it
out?
Thanks,
Marko
-----Original Message-----
From: McCallum, Robert [mailto:robert.mccallum@thus.net]
Sent: Saturday, March 20, 2004 10:25 AM
To: Marko Berend; ccielab@groupstudy.com
Subject: RE: Service-policy from the router
You need to do service policy INPUT not output.
Robert McCallum
CCIE #8757 R&S
01415663448
07818002241
> -----Original Message-----
> From: Marko Berend [mailto:marko.berend@storm.hr]
> Sent: 20 March 2004 09:14
> To: ccielab@groupstudy.com
> Subject: RE: Service-policy from the router
>
>
> William,
>
> ACL's are also interface based, yet they don't work for
local
> traffic out. Test the marking with service-policy and see
for
> yourself.
>
> Maybe I am missing something in my config (previous post)?
>
> Thanks, Marko
>
> -----Original Message-----
> From: William Chen [mailto:kwchen@netvigator.com]
> Sent: Friday, March 19, 2004 6:21 PM
> To: SANCHEZ-MONGE,ANTONIO (HP-France,ex2); Marko Berend;
> ccielab@groupstudy.com
> Subject: Re: Service-policy from the router
>
>
> Hi,
>
> If you think of Qos are mostly interface based. You've
> applied a policy to reserve 20% bandwidth to telnet on an
> interface. Do you think that the router will treat any
> difference between locally generated telnet traffic with
> switched telnet traffic that will go out the same
interface?
>
> It is very easy to lab it, and test it. :-)
>
> Best Regards,
> William Chen
>
> ----- Original Message -----
> From: "SANCHEZ-MONGE,ANTONIO (HP-France,ex2)"
> <antonio.sanchez-monge@hp.com>
> To: "'Marko Berend'" <marko.berend@storm.hr>;
<ccielab@groupstudy.com>
> Sent: Saturday, March 20, 2004 1:00 AM
> Subject: RE: Service-policy from the router
>
>
> > Hi Marko,
> >
> > Well with "ip local policy" you can specify a route-map
which can do
> > the marking ("set ip precedence ...").
> >
> > If you want more fancy QoS you can use PBR to redirect
locally
> > originated traffic to the loopback and use a service
policy on it.
> > Never tried it though (too many things to test and only
13 days to
> > take the lab ;)
> >
> > Cheers,
> > Ato.
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com
[mailto:nobody@groupstudy.com] On Behalf
> > Of Marko Berend
> > Sent: jueves, 18 de marzo de 2004 11:16
> > To: ccielab@groupstudy.com
> > Subject: Service-policy from the router
> >
> >
> > Hi,
> >
> > Is there a way to enable servicing traffic originated on
the router?
> > Something like "ip local policy" for PBR?
> >
> > Specificaly I am interested in ways of marking router
originated ip
> traffic
> > (ip precedence) with MQC if possible.
> >
> > Thanks,
> > Marko
> >
> >
>
This archive was generated by hypermail 2.1.4 : Thu Apr 01 2004 - 08:15:43 GMT-3