I had the same problem when using 'match protocol HTTP'. It would seem that
there is something in that nbar protocol identifier that is looking for more
then just a TCP SYN to port 80. I remapped the HTTP protocol to a different
port (1000) and created a custom nbar protocol called 'WEB' and it worked.
ip
nbar port-map http tcp 1000
ip nbar custom WEB tcp 80
Make a small loan,
Make a big difference - Kiva.org
________________________________
From:
Garth Bryden <hacked.the.planet.on.28.8k.dialup_at_gmail.com>
To: Cisco
certification <ccielab_at_groupstudy.com>
Sent: Mon, October 18, 2010 10:06:23 AM
Subject: FPM
Hello Group,
I had a task today, to implement a traffic filter
without using
access-lists, after quick exploration of the doc cd I decided
flexible
packet matching was the way to go, oh boy was it fun!
Well I created
my filter and it did not work, my topology is as follows
<R4> ----------
<R5> -------------- <R3>
On R5 I have the following configured to block http
traffic.
load protocol system:fpm/phdf/tcp.phdf
load protocol
system:fpm/phdf/ip.phdf
!
!
class-map type access-control match-all HTTP
match
field TCP dest-port eq 80
class-map type stack match-all ip_tcp
match field IP
protocol eq 0x6 next TCP
!
!
policy-map type access-control HTTP
class HTTP
drop
policy-map type access-control fpm_policy
class ip_tcp
service-policy
HTTP
!
interface FastEthernet0/1.45
encapsulation dot1Q 45
ip address
130.9.45.5 255.255.255.0
ipv6 address 2001:130:9:45::5/64
service-policy type
access-control input fpm_policy
end
I'm using R3 as the HTTP Server and R4 to
act as the HTTP client.
So its all configured and I jump onto R4 to initiate
a connection and what
do you know, it doesn't work!?!!
Rack9R4#telnet
130.9.35.3 80
Trying 130.9.35.3, 80 ... Open
^C
HTTP/1.1 400 Bad Request
Date:
Mon, 18 Oct 2010 06:41:35 GMT
Server: cisco-IOS
Accept-Ranges: none
400 Bad
Request
[Connection to 130.9.35.3 closed by foreign host]
Rack9R4#
Rack9R5#show policy-map type access-control interface fa0/1.45
FastEthernet0/1.45
Service-policy access-control input: fpm_policy
Class-map: ip_tcp (match-all)
0 packets, 0 bytes
5 minute offered
rate 0 bps
Match: field IP protocol eq 0x6 next TCP
Service-policy access-control : HTTP
Class-map: HTTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: field TCP dest-port eq 80
drop
Class-map: class-default
(match-any)
0 packets, 0 bytes
5 minute offered rate 0
bps, drop rate 0 bps
Match: any
Class-map: class-default
(match-any)
12 packets, 944 bytes
5 minute offered rate 0 bps,
drop rate 0 bps
Match: any
Rack9R5#
I checked R5 and it looks like all
the packets went into the class-default
and didn't hit the FPM!?... After a
while of tinkering, I thought it was my
match statements were not correct, so
I decided to do a debug ip packet..
turned of route-caching on the interface
so the packets are sent to the
processor and what do you know, they start
hitting the fpm and it is
blocking traffic?
RSRack7AS>R4
Trying R4 (1.1.1.1,
2004)... Open
telnet 130.9.35.3 80
Trying 130.9.35.3, 80 ...
RSRack7AS>discon
Closing connection to R4 [confirm]
RSRack7AS>
Rack9R5#show policy-map type
access-control interface fa0/1.45
FastEthernet0/1.45
Service-policy
access-control input: fpm_policy
Class-map: ip_tcp (match-all)
7
packets, 446 bytes
5 minute offered rate 0 bps
Match: field IP
protocol eq 0x6 next TCP
Service-policy access-control : HTTP
Class-map: HTTP (match-all)
4 packets, 240 bytes
5 minute
offered rate 0 bps
Match: field TCP dest-port eq 80
drop
Class-map: class-default (match-any)
3 packets, 206 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Class-map: class-default (match-any)
104 packets, 8728 bytes
5
minute offered rate 0 bps, drop rate 0 bps
Match: any
Rack9R5#
I've
looked at the documentation and I can't see that I am hitting any of
the
restrictions... I'm not sure why this is happening... for some reason I
thought FPM traffic would work only for Data Plane traffic and not process
switched data? I'm wondering if anyone else has any idea's?
Cheers,
Garth
Blogs and organic groups at http://www.ccie.net
Received on Tue Oct 19 2010 - 17:36:41 ART
This archive was generated by hypermail 2.2.0 : Mon Nov 01 2010 - 06:42:06 ART