RE: Service-policy from the router (Answer Here!)

From: HP-France,ex2 ("SANCHEZ-MONGE,ANTONIO)
Date: Sun Mar 21 2004 - 14:30:44 GMT-3


Yes that's correct, with NBAR locally generated traffic is not classified (I
tested too)

 -----Original Message-----
From: Richard Dumoulin [mailto:richard.dumoulin@vanco.es]
Sent: domingo, 21 de marzo de 2004 18:29
To: Richard Dumoulin; SANCHEZ-MONGE,ANTONIO (HP-France,ex2); 'Kenneth
Wygand'; Marko Berend; ccielab@groupstudy.com
Subject: RE: Service-policy from the router (Answer Here!)

So I think that when using acl's to match the traffic, the packets are
process switched and they are effectively marked. With NBAR, an entry is not
present int the cef table so NBAR does not work for locally generated
traffic,
--Richard
-----Mensaje original-----
De: Richard Dumoulin
Enviado el: domingo, 21 de marzo de 2004 18:23
Para: 'SANCHEZ-MONGE,ANTONIO (HP-France,ex2)'; 'Kenneth Wygand'; Marko
Berend; ccielab@groupstudy.com
Asunto: RE: Service-policy from the router (Answer Here!)

Antonio, I just used NBAR now and it does not work anymore. So for locally
generated traffic NBAR is of no use. Can you set this up yourself to double
check ?
Regards
--Richard
-----Mensaje original-----
De: SANCHEZ-MONGE,ANTONIO (HP-France,ex2)
[mailto:antonio.sanchez-monge@hp.com]
Enviado el: domingo, 21 de marzo de 2004 17:52
Para: 'Kenneth Wygand'; Marko Berend; ccielab@groupstudy.com
Asunto: RE: Service-policy from the router (Answer Here!)

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