No ACL on int with Compression?

[djmlmco]

Is there any documentation anywhere that states an ACL will not work when compress stac is turned on for a synch serial interface? Is there any way to circumvent this behavior to be able to use an ACL and compression?

Kind regards in advance.

[colin]

Hello,

I don't find this to be the case:

interface Serial0

ip address 1.1.1.1 255.255.255.252

ip access-group 101 in

encapsulation ppp

compress stac

serial restart-delay 0

access-list 101 deny ip 3.0.0.0 0.255.255.255 any log

access-list 101 permit ip any any

Router#sh compress

Serial0

Software compression enabled

uncompressed bytes xmt/rcv 3008/4299

compressed bytes xmt/rcv 912/1235

Compressed bytes sent: 912 bytes 0 Kbits/sec ratio: 3.298

Compressed bytes recv: 1235 bytes 0 Kbits/sec ratio: 3.480

1 min avg ratio xmt/rcv 0.340/0.621

5 min avg ratio xmt/rcv 0.506/0.757

10 min avg ratio xmt/rcv 0.506/0.757

no bufs xmt 0 no bufs rcv 0

resyncs 0

Additional Stac Stats:

Transmit bytes: Uncompressed = 0 Compressed = 912

Received bytes: Compressed = 1284 Uncompressed = 0

*Aug 23 03:50:33.019: %SEC-6-IPACCESSLOGDP: list 101 denied icmp 3.3.3.1 -> 2.2.2.1 (0/0), 1 packet

What software version are you using?

Cheers,

-colin.

[djmlmco]

Well... Maybe that is the case and I probably didn't explain the setup well enough.

First of all the ACL is called from a service policy, which is also an 'out' and not an 'in'.

Example:

!

!

class-map match-any Class_1

match access-group 101

!

!

policy-map Policy

class Class_1

bandwidth percent 50

!

!

policy-map Shape_256

class class-default

shape average 256000

service-policy Policy

!

!

interface Serial1/0

ip address 192.168.X.X 255.255.255.X

service-policy output Shape_256

encapsulation XXX

no ip mroute-cache

no keepalive

compress stac

no cdp enable

!

!

So... What I'm doing is running the service policy on the outbound traffic. Then I shape the traffic, because I need to control the data to the DCE device and not flood it. After it's shaped it gets run through a more extensive policy map than is shown. That's when it hits the ACL(s). But - when I enable compression my policy maps dont seem to catch traffic. I figured, maybe it was the end portion of the config - the ACLs.

Any other thoughts?

Thanks!

[colin]

Ah - that is very much different to the question you asked. :-)

Tested it here, yeah, it's busted. It's a bug (quel surprise). It could be the order in which the packet is handled by the code - if it compresses it before it hits the access-list to match, it's no longer seen as a packet that matches, or something like that.

Log a case with the TAC, give them as much information (if you want it from me to give to them, just ask) as you can, and ask them to raise a DDTS on it.

And don't run compression. :-)

Cheers,

-colin.

[djmlmco]

Detail, schmetails. :)

Thanks for reassuring my doubt in what I was doing. I had tested this on a few 12.2 and 12.3 trains, so it's been b0rked for a while now.

I've opened more TAC cases.

Thanks Colin!

[djmlmco]

And actually Colin - if you'd like, go ahead and open the TAC. I won't have time until the end of the week. The thing is, I *need* this compression with QoS because of the sensitivity of the data...

Thanks again!

Kind regards,

Dave

[colin]

Hey Dave,

There is a really old bug (CSCdj45401) which indicates that any sort of queuing won't work with software compression, due to the fact that the compression alters the packet...

I've been trying to log a TAC case, but can't.. :-)

I'll let you know.

-colin.

[djmlmco]

Doh. :)

So you can't open TAC for some odd reason, or they won't accept that case again?

Thanks Colin!

Regards,

Dave

[colin]

I've tried three times today, and it's probably due to my profile being busted. I tried to log it via email, and I can't - I think I have raised three cases just trying to log a case. cisco ain't the place it used to be.

I think that this issue could go a lot deeper than just the QoS Dave. It breaks almost everything - rate limiting, anything that is inspected after a packet has been compressed. The only thing that is not broken is if the ACL is applied to the interface.

This means things like NBAR, stuff that has to post process prior to enqueuing a packet on the egress port (probably for everything apart from ethernet) is broken..

How do you spell possible security issues?

-colin.

[djmlmco]

Yeah, that's really sad. I have some time today, maybe I'll open it up. When I do I'll post what it's logged under and see how quick they close it to say "Yeah - we know." and that'll be the end of it... :) The funny thing is that Cisco has that QoS for VPNs. Seems like the preprocess the packet before it hits the encryption. They need to do QoS for compression now!

Reference:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t2/ftqosvpn.htm

Thanks Colin!

Dave

[Michael Stuckey]

Why don't you create a GRE tunnel put your data across it. Then still do the compression. I would bet this work and still give you the security you need.