RE: Flexible Packet Matching

If you are trying to telnet from the device itself then you need to go to
another device to do the tests. Try it with another device.

Regards,

Tyson Scott - CCIE #13513 R&S, Security, and SP

Technical Instructor - IPexpert, Inc.

Mailto: <mailto:tscott_at_ipexpert.com> tscott_at_ipexpert.com

Telephone: +1.810.326.1444, ext. 208

Live Assistance, Please visit: <http://www.ipexpert.com/chat>
www.ipexpert.com/chat

eFax: +1.810.454.0130

IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
CCIE (R&S, Voice, Security & Service Provider) certification(s) with
training locations throughout the United States, Europe, South Asia and
Australia. Be sure to visit our online communities at
<http://www.ipexpert.com/communities> www.ipexpert.com/communities and our
public website at <http://www.ipexpert.com/> www.ipexpert.com

From: Sadiq Yakasai [mailto:sadiqtanko_at_gmail.com]
Sent: Friday, March 19, 2010 12:23 PM
To: Tyson Scott
Cc: Cisco certification; Cisco certification
Subject: Re: Flexible Packet Matching

The strange part is that when I apply the service policy on the OUTBOUND
direction, there is just no hit at all. This is when the router or the host
initiates the telnet session!

Any ideas whats going on here?

Router(174.1.38.1) ---------------- host (174.1.38.100)

class-map type stack match-all TEST_DEST
 match field IP protocol eq 0x6 next TCP
 match field TCP dest-port eq 23 next TCP

class-map type stack match-all TEST_SOURCE
 match field IP protocol eq 0x6 next TCP
 match field TCP source-port eq 23 next TCP
!

policy-map type access-control TEST
 class TEST_SOURCE
   drop
 class TEST_DEST
   drop

interface FastEthernet0/0
 ip address 174.1.38.1 255.255.255.0
 duplex auto
 speed auto
 service-policy type access-control input TEST
end

Router#
Router#telnet 174.1.38.100
Trying 174.1.38.100 ...
*Mar 19 15:53:38.454: tcp0: O CLOSED 174.1.38.100:23 174.1.38.1:55778 seq
3674753707
        OPTS 4 SYN WIN 4128
*Mar 19 15:53:40.454: tcp0: R SYNSENT 174.1.38.100:23 174.1.38.1:55778 seq
3674753707
        OPTS 4 SYN WIN 4128
*Mar 19 15:53:44.454: tcp0: R SYNSENT 174.1.38.100:23 174.1.38.1:55778 seq
3674753707
        OPTS 4 SYN WIN 4128
*Mar 19 15:53:52.454: tcp0: R SYNSENT 174.1.38.100:23 174.1.38.1:55778 seq
3674753707
        OPTS 4 SYN WIN 4128
% Connection timed out; remote host not responding

Router#show policy-map type access-control interface f0/0
 FastEthernet0/0

  Service-policy access-control input: TEST

    Class-map: TEST_SOURCE (match-all)
      4 packets, 240 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: field IP protocol eq 0x6 next TCP
      Match: field TCP source-port eq 23 next TCP
      drop

    Class-map: TEST_DEST (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: field IP protocol eq 0x6 next TCP
      Match: field TCP dest-port eq 23 next TCP
      drop

    Class-map: class-default (match-any)
      8 packets, 793 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
Router#
Router#
Router#

On Thu, Mar 18, 2010 at 11:31 PM, Sadiq Yakasai <sadiqtanko_at_gmail.com>
wrote:

Right, thanks Tyson.

I guess it would make more sense to use the second approach and apply the
service-policy in one direction on the interface (yet still drop the telnet
traffic on both directions).

Otherwise to achieve the same results with the first approach, I could
configure 2 classes, each matching the traffic in a direction, and applying
the policy.

A third un-intuitive method would be 2 service-policies, each having a class
matching in each direction I guess.

I will try and give this a whirl in the morning, see how it goes then.

Sadiq

On Thu, Mar 18, 2010 at 10:16 PM, Tyson Scott <tscott_at_ipexpert.com> wrote:

Sadiq,

If you only applied this in one direction on an interface then accounting
for both source eq 23 and dest eq 23 actually would be a good thing.

As I haven't tested the first example I am not positive but I don't know if
the first one will work. It may possibly.

The second example is how I would typically do it.

Regards,
 
Tyson Scott - CCIE #13513 R&S, Security, and SP
Technical Instructor - IPexpert, Inc.

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of

Sadiq Yakasai
Sent: Thursday, March 18, 2010 2:13 PM
To: Cisco certification; Cisco certification
Subject: Re: Flexible Packet Matching

Please ignore the line " match field tcp source-port eq 23" below when
analyzing the config!

On Thu, Mar 18, 2010 at 5:24 PM, Sadiq Yakasai <sadiqtanko_at_gmail.com> wrote:

> All,
>
> So would there be any difference between the 2 solutions below. I dont
have
> the right image to configure and test, so there might be syntax issues
here.
> I am mostly curious about the approach.
>
> Thanks again, as usual.
>
> Sadiq
>
> Solution 1:
> class-map type stack match-all TELNET
> match field ip protocol eq 0x6 next tcp
> match field tcp dest-port eq 23
>
> policy-map type access-control INTERFACE_POLICY
> class TELNET
> drop
>
> Solution 2:
> class-map type access-control match-any TELNET
> match field tcp dest-port eq 23
> match field tcp source-port eq 23
>
> class-map type stack match-all TCP
> match field ip protocol eq 0x6 next tcp
>
> policy-map type access-control BLOCK_TELNET
> class TELNET
> drop
>
> policy-map type access-control INTERFACE_POLICY
> class TCP
> service-policy BLOCK_TELNET
>
> --
> CCIE #19963
>

--
CCIE #19963
Blogs and organic groups at http://www.ccie.net