WAAS: Standard vs Extended ACL's for WCCP Transparent Redirection

I've come across a number of implementations where the ACL's associated with services 61 & 62 are using extended access-list. I am writing with specific reference to wccp configured in promiscuous mode.
Since WCCP will only redirect TCP, and the WAAS solution in general applies only to TCP - then is there really a need for extended acls for redirection?. Furthermore, in a simple implementation you do not need separate acls linked to 61 & 62 - i don't think so.
Standard acls parse the filteration process more quickly than extended.
thanks
Ajaz

The extended access-lists are used because some TCP traffic does not to be optimized (telnet, BGP, SNMP, ...), or some hosts have compressed traffic for any application and need to be excluded from redirection. Besides that standard access-lists can be used.

Similar Messages

Standard and Extended ACLs?

I just want to know that if extended IP access lists can do all tasks, I mean extended access lists have a lot of controlling parameters, then why people use Standard Access lists instead of Extended access lists.
I just want to know that in which scenario we should use STD ACLs instead of EXTD ACLs, what special advantage of using STD over EXTD ACLs,
Please reply.

Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
To summarize what the other posters have already noted, the two principle reasons why one might use a standard ACL (which could also be functionally accomplished) by an extended ACL are 1) some commands that rely on ACLs might still only support standard ACLs (more likely in older IOS versions) and 2) a standard ACL might be just a little clearer to understand.
Another (hopefully needless) reason why you might want to use a standard ACL, when an extended ACL would do, could be the device's processing performance might be better with a standard ACL.
Logically the standard ACL ACE:
access-list 10 permit host 1.1.1.1
should be the same as this extended ACL ACE:
permit ip host 1.1.1.1 any
But a "dumb" implementation of processing the extended ACL might wildcard compare the destination IP and other optional parameters while the standard ACL only examines the source IP. Should this happen? No, but such might happen because of different generations of code and/or different teams working on ACL processing.
BTW, if there is a significant performance difference, it's just as possible extended works better.
Again, this is very extreme and unlikely, but this could be a reason to use one form of ACL vs. the other when both can provide the same filtering. (Also, if this is "discovered", it's very likely to be very device and IOS version specific. Personally I would consider taking "advantage" of such a discovery poor practice, except in extreme situations.)

Extended ACL Issue

I have a question, I am trying to make an extended ACL to deny HTTP, Telnet, and FTP traffic from the internet to PC1 in the one exercise I am doing.
I made the following ACL and applied it to the loopback interface on R2 (where the ISP is coming in from the "cloud") PC1 is connected to R1 which is obviously connected to R2.
ip-access-list extended ACL_TCP
deny tcp 209.165.200.160 0.0.0.31 10.0.0.0 0.0.0.127 established
permit tcp any any established
Is there a better way to do this? Does this extended ACL work for my purpose?

What direction did you apply this? I'm assuming in the inbound direction?
Take the established keyword off. That's generally to allow return traffic on an interface that's denying traffic.
Try the following:
ip access-list ext ACL_TCP
deny tcp 209.165.200.160 0.0.0.31 10.0.0.0 0.0.0.127 eq http
deny tcp 209.165.200.160 0.0.0.31 10.0.0.0 0.0.0.127 eq ftp
deny tcp 209.165.200.160 0.0.0.31 10.0.0.0 0.0.0.127 eq telnet
Apply to your loopback:
ip access-group ACL_TCP in
Next question:
Why do you have an acl applied to your loopback and not the physical interface that your internet connection comes in on? Normally, you would apply to say s0/0 (serial interface) that has your public ip assigned to it. That may be why it's not working. You actually have the acl applied to LoopbackX?
HTH,
John

WCCP Redirect list ACL mask for WAAS

Good day,
I would like to conform if the following would be correct to implement for WCCP redirection list on 6500. We have over 800 branches and we also need to manage the intra-server traffic in the Data Center which we do not want to be re-directed.
ip access-list extended WCCPLIST-61
permit tcp 10.112.0.0 0.0.31.255 any
ip access-list extended WCCPLIST-62
permit tcp any 10.112.0.0 0.0.31.255
So, as an example, would these masks work for us, as the number of entries otherwise would be exhaustive.
Just want to confirm that the mask in the ACL doesn't have to match exactly.
Thanks in advance.

Hi Zach,
Thanks for the response and confirmation.
I was wanting to make sure that it is not required to have the masks match the source masks, resulting in the exhaustive list (operational nightmare).
A quick question on the ACL for WCCP redirect-list. Should we not see hits on specific entry's (e.g.permit tcp 10.113.9.0 0.0.0.31 any for the 61 redirect list, and the same for the permit tcp any 10.113.9.0 0.0.0.31 for the 62 redirect list).
If we don't, no traffic? We see flows on the branch WAE, although very few (not many users), but no hits on the ACL on the DC 6500. Is this due them being handled in hardware maybe, TCAM's?
Any input would be apprecited.
Thanks again.
Paul.

WAAS: ASR for WCCP redirect

Has anyone deployed an ASR for WCCP redirection? How stable is this platform?
Thanks,
DG

DG,
I work for Cisco Systems.
WCCP support on ASR has been there for a while now. Many of our customers do run WCCP on ASR and happy with the stability and performance. As you may know it is a h/w based platform and hence it processes WCCP in h/w. Pl ensure that you are using mask assignment to take advantage of h/w processing on ASR.
thanks
Nat

WAAS with ACE - Use Ace or use WCCP or use PBR?

Wich is better to use, i need use two aces in HA (active x active). But the model of Switch Router is Enterasys and Enterasys dont have WCCP, but have TWCB(Transparent Web Cache Balancing (https://extranet.enterasys.com/sites/dms/DMSAssetLib/Documents/Feature%20Guides/twcbFeatGde041609.pdf), but my questions are:
1) I have two Aces too, the better is use Ace to do this or not? (In reality i think that is not the best way).
2) Somebody can say me if TWCB is the same of WCCP?
3) With PBR can i use two WAAS in active x active mode?
Thanks

Hi Luciano,
I tried to open the link you provided, but it's asking me for an Enterasys username and password so I couldn't find out what exactly this feature is. My guess is that it allows some transparent redirection similar to WCCP, but I have no clue how this is achieved. Therefore, I'm just going to speak about the other options.
The first thing I would like to say is that, if you have to choose between PBR and ACE, I would recommend you to use the ACE. The main problem of PBR is that the redirection needs to be statically configured based on ACLs maching on the source or destination addresses, so, you don't have any kind of redundancy if a WAE goes down, and you may have to rewrite the ACLs if something changes in your environment. With the ACE, the load-balancing is dynamically done, so, if one of the WAE fails or the traffic patterns change, the load distribution will be dynamically adjusted
Regards
Daniel

Catalyst 3560 Extended ACLs

I have a VoIP / QoS situation I just discovered on the Cat 3560's. In this case, a particular manufacturer's IP Phones do not tag CoS or DSCP. As such, I have defined extended ACL's/Policies on the Cat 3560 switches to detect and mark traffic from the IP Phones. My policies are designed to identify and mark Call Bearer with DSCP 46 and Call Control traffic with DSCP 26 based upon source address and UDP port. What I see however, is that all VoIP traffic is marked at DSCP 46, and nothing is marked at 26. (It's not so bad having control and bearer marked with DSCP EF, but I like to put call control in a different queue when possible.)
I am looking for confirmaton of the following theory. I suspect that the 3560's ((C3560-IPBASEK9-M), Version 12.2(25)SED) are not layer 4 aware, thus extended access lists function only as standard access lists - (even though the switch allows me to create an extended ACL). As such, my attempt to identify call bearer and call signalling based upon UDP port will not work.
Below is the ACL / Policy config. Note that on downstream routers, I only see DSCP 46 and never match DSCP 26 (af31). From the switch, using "sh mls qos interface statistics", I see no traffic with DSCP 26 at all (output attached).
I believe this is because the switch is only reading the layer 3 portion of the ACL. Since both ACL 101 and ACL 102 have the same layer 3 source adress, then all classified traffic will match class "IngressVoiceBearer" and get marked with 46.
access-list 101 remark Voice Bearer Signalling
access-list 101 permit udp 192.168.100.0 0.0.0.255 any eq 5004
access-list 102 remark Call Control Signalling (udp 5440-5445)
access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5440
access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5441
access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5442
access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5443
access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5444
access-list 102 permit udp 192.168.100.0 0.0.0.255 any eq 5445
class-map match-any IngressCallControlSignalling
match access-group 102
class-map match-any IngressVoiceBearer
description All Inbound Voice Bearer traffic on UDP 5004
match access-group 101
policy-map IngressVoIP
class IngressVoiceBearer
set dscp ef
class IngressCallControlSignalling
set dscp af31
class class-default
set dscp default
Switch Output:
switch#sh mls qos int g0/1 statistics
GigabitEthernet0/1
dscp: outgoing
0 - 4 : 12359302 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 1837749 0 9716 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0

Are the ports correct for the call control ACL? In the Cisco VoIP world we use an ACL like this for call control:
ip access-list extended VOICE-CONTROL
permit tcp any any range 2000 2002
permit tcp any range 2000 2002 any
permit tcp any any range 11000 11999
permit tcp any any range 1718 1720
permit udp any any range 1718 1719
permit udp any any range 2427 2428
permit tcp any any range 2443 2445
permit tcp any any range 5555 5599
But Cisco uses different protocols. Your ACL is configured correctly and the 3560 is supposed to support extended ACLs. Does your 3560 have an enhanced image or a standard image?
Are these Avaya phones? I have had to do software updates on Avaya phones to get them to behave correctly.
-Mark

Use extended ACL with NAT

Believe it or not, once in a while, i fumble with some basic concepts. Here is one, on our perimeter FW, ASA, there are these NATTING configured.
I just couldnt figure out why they use extended ACL for the sources? isnt the standard one good enough?
thanks in advance,
Han
access-list dmz_nat0_outbound extended permit ip any 1XX.169.0.0 255.255.0.0
access-list dmz_nat0_outbound extended permit ip any 10.48.240.0 255.255.255.0
access-list dmz_nat0_outbound extended permit ip any 10.48.243.0 255.255.255.0
access-list inside_nat0_outbound_5 extended permit ip any 172.17.13.0 255.255.255.0
access-list inside_nat0_outbound_5 extended permit ip any 192.168.12.0 255.255.255.0
access-list inside_nat0_outbound_5 extended permit ip any 192.168.221.0 255.255.255.0
global (Outside) 2 2XX.YY.13.244 netmask 255.255.255.0
global (Outside) 1 2XX.YY.13.12 netmask 255.255.255.255
nat (inside) 0 access-list inside_nat0_outbound_5
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz) 0 access-list dmz_nat0_outbound
nat (dmz) 2 0.0.0.0 0.0.0.0

Hi Han,
If you go for the standard ACL then you cannot specify the destination subnets and ports. You can specify only the source and the destination is considered any by default.
standard ACL:
access-list 10 standard permit ip 172.16.0.0
Extended ACL:
access-list abc permit tcp 172.16.0.0 255.255.255.0 10.0.0.0 255.255.255.0 eq 80
This is how it differs. In your scenario destination is specific rather the source is any. So you have the extended ACL in picture for that. Hope this clears you.
Please do rate if the given information helps.
By
Karthik

Extended Life Battery for Palm Pre

I apologize if this has already been cussed and discussed. I searched for an answer but didn't find it.
If I were to buy and install an extended life battery for my Pre, will that void or otherwise affect my warranty. I've had my Pre about 2 months and like except for constantly recharging the battery. I found a battery that supposedly has 126% capacity of the standard phone.
I called customer service but I'm not convinced he understood my question.
Thanks
Post relates to: Pre p100eww (Sprint)

yeah....i'm sure it would work, but 1750 won't get you that much more life. this is what i got:
http://cgi.ebay.com/2x-BATTERY-CHARGER-VERIZON-HTC-DROID-INCREDIBLE-/250637825293?cmd=ViewItem&pt=PDA_Accessories&hash=item3a5b2db50d
15 bucks and you'll never have to plug in the phone again. you'll have 3 batteries to rotate. i jus chage the battery when i get up each morning.

Have been using successfully Acrobat 8 Standard, version 8.3.1 for years. Suddenly can not digitally sign anything because software can not find "existing digital ID file?

Have been using successfully Acrobat 8 Standard, version 8.3.1 for years. Suddenly can not digitally sign anything because software can not find "existing digital ID file?

Are you still using Acrobat 8? If not read further.
All Acrobat versions prior to 11.0.07 had a security flaw that they allows signing with certificates that had "Extended Key Usage" (EKU) restricted to certain certificate uses and those did not include document signing. Most frequently those were certificates with "Client Auth" or "Server Auth" in EKU. Acrobat/Reader 11.0.07 fixed this problem, which also means that while previous versions accepted such certificates for signing 11.0.07 and later do not.

SRE External Gig port for WCCP traffic?

Has anyone been successful with using the external Gig port on the SRE modules for WCCP traffic? Has anyone tried it?
I'd like to reduce the CPU on my ISR-G2 routers that have the SRE modules running WCCP GRE. I'd like to use the external gig port on the SRE module for the WCCP traffic, which will allow me to use WCCP L2. Is this even feasible? Or maybe I just need to add WCCP L2 on an SRE as a New Feature request to Cisco?
According the to Cisco documentation....
The external service-module interface can be used to monitor LAN traffic. You can also select the external interface as the management interface for the SM. The external interface cannot be used for downloading applications.
Visible only to the SM software on the Cisco SM-SRE, the external service-module interface is the Gigabit Ethernet interface connector on the Cisco SM-SRE faceplate. The external interface supports data requests and data transfers from outside sources, and it provides direct connectivity to the LAN through an RJ-45 connector.

Tammy,
What is preventing you from configuing WAAS on SRE with L2 WCCP / Mask assignment via the internal interface? This is totally feasible.
If you are trying to decrease CPU utilization on your router, don't expect switching from GRE to L2 to make a drastic difference. The ISR G2 is a software based platform, as such WCCP (whether L2 or GRE) is processed by the CPU with CEF assistance.
True removing the GRE encapsulation will save some processing overhead, but in the end it's the PPS (packets per second) your router is handling that's driving the CPU.
Remember when you add WCCP / WAAS to the flow it's no longer packet in/ packet out on the router. Compressed data in on WAN, out to WAAS, uncompressed from WAAS back to Router, out on the LAN, then the reverse... uncompressed data on the LAN in to the router, out to WAAS, compressed from WAAS out to the router, then out on the WAN. So depending on the compression observed you will see > 2x the amount of traffic being processed by the router.

Extended ACL permit ip and allowed ports

Hi everyone
Need to confirm if we have extended ACL with object group below
access-list xy_access_in extended permit ip object-group xy_subnets object-group cisco_ynetworks
will above ACL allow all the ports on the destination object group?
Thanks
mahesh

And to illustrate the situation above
Situation 1 - Only allow rule exists on the ACL
object-group network SOURCE
network-object 10.10.10.0 255.255.255.0
network-object 10.10.20.0 255.255.255.0
object-group network DESTINATION
network-object 10.10.100.0 255.255.255.0
network-object 10.10.200.0 255.255.255.0
access-list SOURCE-IN permit ip object-group SOURCE object-group DESTINATION
The above ACL would
Allow ALL TCP/UDP source and destination ports
Allow those from the source networks of SOURCE to the destination networks of DESTINATION
Situation 2 - Deny rules exist before the allowing rule
object-group network SOURCE
network-object 10.10.10.0 255.255.255.0
network-object 10.10.20.0 255.255.255.0
object-group network DESTINATION
network-object 10.10.100.0 255.255.255.0
network-object 10.10.200.0 255.255.255.0
access-list SOURCE-IN deny ip host 10.10.10.10 host 10.10.100.100
access-list SOURCE-IN deny tcp host 10.10.10.10 host 10.10.200.200 eq 80
access-list SOURCE-IN permit ip object-group SOURCE object-group DESTINATION
The above ACL would
First block ALL TCP/UDP traffic from host 10.10.10.10 to host 10.10.100.100
It would also block TCP traffic from host 10.10.10.10 to host 10.10.200.200 on the destination port TCP/80
It would then allow ALL TCP/UDP traffic from the source networks of SOURCE to the destination networks of DESTINATION
The key thing to notice ofcourse would be that we have blocked some traffic on the first 2 lines of the ACL and then allowed ALL TCP/UDP traffic.
So host 10.10.10.10 cant communicate with host 10.10.100.100 on any port since the "deny" rule for that is at the top of the ACL BEFORE the rule that allows ALL TCP/UDP traffic between these networks.
In the other case the TCP/80 destination traffic from host 10.10.10.10 to host 10.10.200.200 would be blocked BUT rest of the TCP/UDP traffic would be allowed by the rule using the "object-group"
- Jouni

Extended battery case for the Thunderbolt

I just got the Seidio BD4-HKR5HTMECX CONVERT Extended Life Batteries for HTC ThunderBolt - Retail Packaging - Black from Amazon. Cost about 49.00. Must of been designed for the military because it is total protected. Has a cover for the camera, charging port, and covers the volume and on and off switch. Amazing. Aside good job. It was worth the wait.

Hi fletcher55. I'm glad you're getting the extra battery life out of the extended battery. It is pretty normal for a phone to get warm while charging or in use. I double checked for any known issues on extreme heat on the Thunderbolt with an extended or standard battery and the good news is that the phone seems to have no other reports like what you've mentioned. Where did you get the extended HD battery from? If you're using a battery or charger that was purchased from a third party (not Verizon Wireless or HTC) there's a better chance there may be some extra warmth to the device that may even cause the phone to malfunction. If it continues to get extremely hot, I would recommend returning the battery to the place of purchase. If it was at a Verizon store, please make sure to bring the phone, all your batteries, and chargers with too.
Thank you
JenniferH_VZW
Please follow us on Twitter @vzwsupport

WAAS - WCCP L2-redirection in WS-C6509-E

Hi,
I have a costumer with three offices, one is the data center. The other two offices get information from the data center and between them.
Each one of these remotes offices go through two different SP to the data center, and each one is received in his own router. The core of the data center is a switch WS-C6509-E (IOS s72033-entservicesk9_wan-vz.122-18.SXF7.bin).
Because there are two different SP in the data center, the traffic redirection must be done in the switch c6500. I think that the following configuration is the correct one:
ip wccp version 2
ip wccp 61 redirect-list 101
ip wccp 62 redirect-list 101
interface Vlan1
description *** WAN routers and users ***
ip address 10.0.16.1 255.255.240.0
ip wccp 62 redirect out
ip wccp 61 redirect in
interface Vlan 200
description *** WAEs ***
ip address 10.34.114.65 255.255.255.252
ip wccp redirect exclude in
interface Vlan201
description *** Servers and Users 1 ***
ip address 10.15.240.1 255.255.240.0
ip wccp 61 redirect in
interface Vlan202
description *** Servers and Users 2 ***
ip address 10.16.128.1 255.255.240.0
ip wccp 61 redirect in
But now I read about the problems using GRE redirection in the switch c6500. I read too that the best way to do this is using L2-redirection, but I don't have any idea of how to do this. I am using the WAAS version 4.1.1.
Can anybody help me with explaining me the way to configure that?

Dan,
I think that the best option for this network is number one, use WCCP on the two 7206VXRs, and redirect the traffic to a single WAE in the same subnet of the hosts.
But now, I don't understand the implications of use the command âegress-method negotiated-return intercept-method wccpâ. What else should I consider or configure (in the router or in the WAE) to make this interception works?
I think that the configuration on the routers and in the WAE should be something like this:
--- Router 1
ip wccp version 2
ip wccp 61 redirect-list 101
ip wccp 62 redirect-list 101
interface Serial3/3:1
ip address 10.34.113.213 255.255.255.252
ip wccp 61 redirect in
ip wccp 62 redirect in
interface GigabitEthernet0/1
ip address 10.0.16.2 255.255.240.0
ip wccp redirect exclude in
--- Router 2
ip wccp version 2
ip wccp 61 redirect-list 101
ip wccp 62 redirect-list 101
interface Serial3/3:1
ip address 10.134.143.217 255.255.255.252
ip wccp 61 redirect in
ip wccp 62 redirect in
interface GigabitEthernet0/1
ip address 10.0.16.3 255.255.240.0
ip wccp redirect exclude in
--- WAE
interface GigabitEthernet 1/0
ip address 10.0.16.4 255.255.255.0
exit
egress-method negotiated-return intercept-method wccp
wccp router-list 1 10.0.16.2 10.0.16.3
wccp tcp-promiscuous router-list-num 1
Thanks and Regards,
Pablo

Applying Extended ACL close to Destination

Hi Everyone,
Need to share something here.Mostly we use extended ACL close to the source.
Here is this scenario i need to use the extended ACL close to destination to fix the issue.
Here is info
Server 1 connected to interface X ASA1 it has wan connection to ASA2---ASA2 has connection to ASA3.
Now ASA3 is learning source server IP via its Y interface.
In order to reach the destination server ASA3 has to through its interface Z.
Now there was ACL on ASA3 which denies traffic from source server IP to destination IP on interface Y.
I apply the ACL on ASA3 to allow the traffic and it worked.
Dooes someone elase also has seen this behaviour?
Regards
Mahesh

Hi,
The thing depends on the fact if I understood your setup correctly. If you have traffic flowing through 3 different firewalls to reach its final destination then naturally you have to make sure that each of those firewalls allow that traffic. Even if the first ASA1 allows this connections in its ACL rules it might still be that ASA2 or ASA3 has a configuration that doesnt allow this traffic (like it seemed to be originally in your situation). The fact that ASA1 allowed the connection attempt through itself doesnt mean that it would reach its destination as there are differen firewalls on the way.
Just as an example I could mention one real life setup that I manage.
The setup contains 4 firewalls always (at minimum)
One is customer firewall/vpn device
One is our vpn device
One is our firewall device
One is our partner firewall device
This means essentially that for the Customer to reach the Partner sites servers the traffic has to go through 4 firewalls atleast. Because of the policy chosen we only have to make sure that the Customer and the Partner firewall allows the traffic as Our firewalls dont do any access control (just provide the connectivity between sites)
- Jouni

WAAS: Standard vs Extended ACL's for WCCP Transparent Redirection

Similar Messages

Maybe you are looking for