I assume you're asking to compare Cisco Access Control Lists (ACL) and Cisco Flexible Packet Matching (FPM).
Packets contain a number of fields, such as:
- IP source address
- IP destination address
- TCP Source Port
- TCP Destination Port
- UDP Source Port
- UDP Destination Port
ACLs
Traditional ACLs can only permit or deny based on a limited number of fields (some of most commonly used fields are listed above); these fields are well-known throughout the internet. However, traditional ACLs cannot filter inside the payload of an IP packet, for instance if someone wanted to block certain kinds of Tibco RV UDP Multicast payloads, it's impossible to do so with traditional ACLs. Traditional ACLs look like this...
! Note: this ACL is only granular to a TCP port
access-list 102 permit tcp any any eq 80
access-list 102 permit tcp any any eq 443
access-list 102 permit tcp any any eq 23
access-list 102 permit tcp any any eq 25
access-list 102 permit tcp any any eq 110
access-list 102 deny ip any any log
!
interface FastEthernet0/0
ip access-group 102 in
FPM
However, FPM can block / allow on any bit inside a single packet header or payload1, as long as there is a valid PHDL file loaded for the field that needs to be blocked or allowed. FPM can define a hierarchy of classes and policies to implement very granular control over the packets that are allowed or denied.
This is an example policy, taken from the FPM docs, which matches a UDP packets sent by the Slammer Worm. It would be impossible to block the hosts infected with the Slammer Worm using ACLs unless you block both good and bad SQL traffic by individual IP source addresses.
load protocol disk2:ip.phdf
load protocol disk2:udp.phdf
!
class-map type stack match-all ip-udp
description "match UDP over IP packets"
match field ip protocol eq 0x11 next udp
!
class-map type access-control match-all slammer
description "match on slammer packets"
match field udp dest-port eq 0x59A
match field ip length eq 0x194
match start l3-start offset 224 size 4 eq 0x4011010
!
policy-map type access-control fpm-udp-policy
description "policy for UDP based attacks"
class slammer
drop
!
policy-map type access-control fpm-policy
description "drop worms and malicious attacks"
class ip-udp
service-policy fpm-udp-policy
!
interface GigabitEthernet0/1
service-policy type access-control input fpm-policy
End Notes:
1 FPM's limitation of inspecting a single IP packet is non-trivial, since that means it's possible to circumvent FPM if an attack manages to split the attack signatures across multiple IP fragments, or TCP packets (since the TCP stream is reassembled at the receiver). That said, it's a still very powerful tool as long as you understand the limitations of the technology.
Yes, generally you need at least one WAE device for the head-end or Core. For a very simple point to point scenario it is possible to use two routers running Express, but the optimization will be relatively low since DRE won't be used.
As far as I recall the software version in the 1941 is only WAAS Express, which does not save the data to disk. This has major limitations because a feature like DRE which is deduplication needs quite large disk space to work most efficiently. Due to memory limitations, DRE is disabled on the 1921, which further limits the efficiency of the optimization.
The WAE/WAVE appliances are the real deal that provide the full feature set. A while ago Cisco had a few small WAE modules for the first generation ISR's like the 2800. These modules had a CPU and laptop hard drive which provided the required resources for the advanced features.
If you want a minimal and simple Wan Optimization solution, then the WAAS Express could be an option. If the requirement is to reduce network traffic volumes, look for something that stores the deduplication data on disk.
Best Answer
GRF is the global routing and forwarding table. Also known as the default VRF in other vendors. It's simply the regular RIB used when no VRFs are used, or the original VRF when other VRFs are used.
A VRF is a virtual routing and forwarding table which allows a physical router to run a 'virutal' router with it's own RIB and FIB and routing protocols.