A full understanding of the mechanics of uRPF (the different behaviors of the two modes especially), along with knowing the basic configuration and theory of how VACLs work, so when you are faced with tricky word play / config examples of either on a Cisco exam or while on the job troubleshooting a production network!
Unicast Reverse Path Forward (uRPF)
This is such a small niche subject in ROUTE that I felt it needed a once over here.
uRPF is a Security Feature, as it verifies the path back to the sender before transmitting data to it, which solves the issue of IP Spoofing attacks.
Note – CEF must be running for uRPF to work!
uRPF runs in two different modes, and one “allow-default” option to know of:
“rx” or “Strict Mode” – Data can only be transmitted out of the interface the source IP Address is expected to be on, or it will be dropped!
“any” or “Loose Mode” – Data can be transmitted out of any valid route in the IP Route Table.
“allow-default” – This command almost defeats the purpose of uRPF, as it allows traffic to take a default route or route not necessarily in the IP Route table back to destination.
^^ More on this point in just a moment, first a look at uRPF config on an interface:
R1(config)#int fa0/0
R1(config-if)#ip verify ?
unicast Enable per packet validation for unicast
R1(config-if)#ip verify unicast ?
reverse-path Reverse path validation of source address (old command format)
source Validation of source address
R1(config-if)#ip verify unicast source ?
reachable-via Specify reachability check to apply to the source address
R1(config-if)#ip verify unicast source reachable-via ?
any Source is reachable via any interface
rx Source is reachable via interface on which packet was received
R1(config-if)#ip verify unicast source reachable-via rx ?
<1-199> IP access list (standard or extended)
<1300-2699> IP expanded access list (standard or extended)
allow-default Allow default route to match when checking source address
allow-self-ping Allow router to ping itself (opens vulnerability in
verification)
<cr>
R1(config-if)#ip verify unicast source reachable-via rx allow-default ?
<1-199> IP access list (standard or extended)
<1300-2699> IP expanded access list (standard or extended)
allow-self-ping Allow router to ping itself (opens vulnerability in
verification)
<cr>
R1(config-if)#ip verify unicast source reachable-via rx allow-default
Gotta love that reminder in certain Cisco commands that your lab router is old 🙂
I’ve highlighted in green the “allow-self-ping” option, which Cisco bluntly recommends not using as it may introduce a Denial of Service attack, so I am not sure why it exists and felt that was worth noting.
This command in its entirety is: “ip verify unicast source reachable-via (rx/any)”
To view if uRPF is enabled on the interface, we must check the CEF table:
R1#sh cef interface fa0/0
FastEthernet0/0 is up (if_number 3)
Corresponding hwidb fast_if_number 3
Corresponding hwidb firstsw->if_number 3
Internet address is 10.81.7.118/28
ICMP redirects are always sent
Per packet load-sharing is disabled
IP unicast RPF check is enabled
Inbound access list is not set
Outbound access list is not set
Hardware idb is FastEthernet0/0
Fast switching type 1, interface type 18
IP CEF switching enabled
IP CEF Fast switching turbo vector
Input fast flags 0x0, Input fast flags2 0x0, Output fast flags 0x0
ifindex 1(1)
Slot 0 Slot unit 0 Unit 0 VC -1
Transmit limit accumulator 0x0 (0x0)
IP MTU 1500
R1#
As for the “allow-default” quirks with Strict and Loose modes, Strict mode is still Strict mode, and it will drop traffic trying to leave out any interface than the one in the FIB (CEF) to the verified destination network.
uRPF Allow-Default has a couple use case scenarios:
- With Strict Mode enabled on say an Internet facing interface, and has a single default route pointed at it, it will allow the default route to be used to route traffic
- With Loose Mode enabled you can drop traffic with routes that are not specifically in the IP Route Table, by defining a static route to Null0 (like dropping traffic with Policy Based Routing within the Route-Map)
An example of Loose Mode traffic filtering via uRPF would be:
ip route 10.10.10.0 255.255.255.0 null0
^ This statement + uRPF Loose Mode + allow-default will allow uRPF to find a more specific match in the FIB (CEF) Table and NOT the IP Route Table to use to forward traffic, rather than just using the Default Route in the IP Route Table.
Big takeaways:
- rx = strict mode = Only forwards traffic out of the interface it was received on
- any = loose mode = Traffic forwarded on any matching route in the IP Route Table
- allow-default = Allows for Default Routes / non IP Route Table routes to be used
- FIB / CEF referenced for routes, however Loose Mode allows traffic to be forwarded out any interface with a valid route in the IP Route Table
Given the word play that can be used with Loose Mode using “IP Route Table” routes instead of CEF (FIB Table) routes, I’d expect a question on that on any Cisco exam, and would thoroughly understand that Loose Mode will use IP Route table routes if CEF does not contain the return path to the Destination off the interface data was received on.
VACL Configuration and Verification commands reviewed
I will keep this pretty honed in on the configuration and why configs are done the way they are when configuring a VACL for Layer 2 traffic filtering.
A VACL access-map can be associate to multiple VLANs, and the ACL’s used to define traffic within them can be used multiple times (for Layer 3 ACL, VACL, Route-Map, etc).
Also if not reviewing the configuration explanation, VACLs have an “Implicit Deny” at the end of them, so anything not permitted by the VACL will be implicitly denied!
The logic is the same as a Route-Map where an ACL is used to define traffic to be filtered (generally an Extended ACL), and “permit” must be used in the ACL as the dropping of traffic will be done in the “vlan access-map” sequences as shown below.
The configuration will be broken down here for clarity of each section:
Extended ACL configuration
SW1(config)#
SW1(config)#ip access-list extended Host2HostACL
SW1(config-ext-nacl)#permit ip 10.0.0.1 0.0.0.0 10.0.0.3 0.0.0.0
SW1(config-ext-nacl)#permit ip host 10.0.0.1 host 10.0.0.4
SW1(config-ext-nacl)#exit
SW1(config)#
Host / Wildcard Masks / Any can be used to define traffic, but MUST use “permit” or the VACL access-map itself will not touch the “deny” statements in the ACL!
VLAN Access-Map configuration
SW1(config)#vlan ?
WORD ISL VLAN IDs 1-4094
access-log Configure VACL logging
access-map Create vlan access-map or enter vlan access-map command mode
configuration vlan feature configuration mode
dot1q dot1q parameters
filter Apply a VLAN Map
group Create a vlan group
internal internal VLAN
SW1(config)#vlan access-map ?
WORD Vlan access map tag
SW1(config)#vlan access-map Host2HostACL_VACL
SW1(config-access-map)#
^Note this drops into access-map configuration mode to configure sequences.
We have now created the VLAN access-map that will be applied to a specific VLAN (coming up) to filter Layer 2 traffic within the VLAN.
VACL access-map ACL configuration to define traffic
SW1(config-access-map)#?
Vlan access-map configuration commands:
action Take the action
default Set a command to its defaults
exit Exit from vlan access-map configuration mode
match Match values.
no Negate a command or set its defaults
SW1(config-access-map)#match ?
ip IP based match
mac MAC based match
SW1(config-access-map)#match ip ?
address Match IP address to access control.
SW1(config-access-map)#match ip add ?
<1-199> IP access list (standard or extended)
<1300-2699> IP expanded access list (standard or extended)
WORD Access-list name
SW1(config-access-map)#match ip add Host2HostACL ?
<1-199> IP access list (standard or extended)
<1300-2699> IP expanded access list (standard or extended)
WORD Access-list name
<cr>
SW1(config-access-map)#match ip add Host2HostACL
SW1(config-access-map)#
This tells the VLAN Access-Map to filter traffic defined by this ACL to perform the configured action on for the traffic.
Configuring the “Drop” action for the VACL
SW1(config-access-map)#?
Vlan access-map configuration commands:
action Take the action
default Set a command to its defaults
exit Exit from vlan access-map configuration mode
match Match values.
no Negate a command or set its defaults
SW1(config-access-map)#action ?
drop Drop packets
forward Forward packets
SW1(config-access-map)#action drop ?
log Log dropped packets
<cr>
SW1(config-access-map)#action drop
Keep in mind this is EXACTLY like a Route-Map, so the “match” and “action” both pertain to a single “sequence #” in the VACL, so single sequence number is saying “Any traffic matching the IP Addresses of this ACL will be dropped” per this sequence.
VACL’s run Top Down until they hit a match, or hit the Implicit Deny all at the bottom.
For this reason I exit out of the VACL access-map config, and re-enter it to configure the next sequence (exactly like a Route-Map), only this time adding a simple “action forward” command to put an “Explicit” allow all other traffic to avoid nuking the network.
Explicit Allow all other traffic configuration
SW1(config-access-map)#exit
SW1(config)#
SW1(config)#vlan access-map Host2HostACL_VACL
SW1(config-access-map)#?
Vlan access-map configuration commands:
action Take the action
default Set a command to its defaults
exit Exit from vlan access-map configuration mode
match Match values.
no Negate a command or set its defaults
SW1(config-access-map)#action ?
drop Drop packets
forward Forward packets
SW1(config-access-map)#action forward ?
<cr>
SW1(config-access-map)#action forward
SW1(config-access-map)#exit
SW1(config)#
As can be seen there is really two schools of thought on how to create a VACL, which is to deny certain traffic and permit all (my preferred), or the allow some traffic and deny the rest (which can work but may very well be a gotcha on exam day!).
Verifying the VACL sequences:
SW1(config)#do sh vlan access-map
Vlan access-map “Host2HostACL_VACL” 10
Match clauses:
ip address: Host2HostACL
Action:
drop
Vlan access-map “Host2HostACL_VACL” 20
Match clauses:
Action:
forward
SW1(config)#
Match clause that is empty means it will match anything!
So to verify a VACL, which is a good idea to maybe just give switches a quick verification for VACLs on exam day if the command is available, is “sh vlan access-map” to view.
Finally applying the VACL to a VLAN
SW1(config)#vlan ?
WORD ISL VLAN IDs 1-4094
access-log Configure VACL logging
access-map Create vlan access-map or enter vlan access-map command mode
configuration vlan feature configuration mode
dot1q dot1q parameters
filter Apply a VLAN Map
group Create a vlan group
internal internal VLAN
SW1(config)#vlan filter ?
WORD VLAN map name
SW1(config)#vlan filter Host2HostACL_VACL ?
vlan-list VLANs to apply filter to
SW1(config)#vlan filter Host2HostACL_VACL vlan-list ?
<1-4094> VLAN id
all Add this filter to all VLANs
SW1(config)#vlan filter Host2HostACL_VACL vlan-list 10 ?
, comma
– hyphen
<cr>
SW1(config)#vlan filter Host2HostACL_VACL vlan-list 10
Note that I only applied it to a single VLAN, however there is both commas and hyphens to assign to several different VLANs, as well as ranges of VLANs.
Another configuration note for exam day, I backed out and re-entered the VACL configuration to create sequence 20, however you can insert a sequence specifically like you would with a Route-Map as shown here:
SW1(config)#vlan access-map VACL_LIST ?
<0-65535> Sequence to insert to/delete from existing vlan access-map entry
<cr>
SW1(config)#vlan access-map VACL_LIST 30 ?
<cr>
On exam day when deciding the best course of action, adding a lower # sequence (lower #’s are higher in the VACL sequence list) to permit traffic max fix the issue, or you might just have to remove the VACL all together with “no vlan access-map (name)” command.
You can of course also add sequence # in the ACL as well, as when it matches traffic against the defined ACL, it will search the ACL defining traffic in a top down fashion as well to find the first match and move onto the “action” sequence of the VACL.
This is where things get confusing / gross, as adding an ACL entry of “deny x.x.x.x x.x.x.x” means the VACL will simply ignore that line and keep searching for a permit match, so to negate a VACL from dropping traffic you must do it in the VACL sequences – Not the ACL.
If I were writing a Cisco exam, I would put that question on there, just to torture us CCNP Candidates with the most intricate possible question my cruel mind could contemplate 🙂
One last note for VACL’s which should be obvious – “sh access-list” or “sh run” and check the ACL section if available to see what traffic is defined for the VACL.
Key Takeaways:
- “sh vlan access-map” – Review VACL sequences / matched ACL’s / actions
- “vlan filter (VACL name) vlan-list (vlans)” – Apply VACL to VLANs
- Any traffic not permitted with “action forward” will be dropped
- ACL “deny” lines will just be ignored by VACLs, it will not “permit” the traffic
- Always always always drop the traffic in VACL sequence #’s, not the ACL
- VACL’s can be used on multiple VLANs, ACLs can be used in multiple places
- “no vlan-access map (VACL name)” to get rid of it!
That was a lot of key take aways, but its a big ugly topic of CCNP SWITCH, so I would expect to see it on any Cisco exam that may include VLAN Access-Lists.
The DEVNET GRIND! 