ip verify unicast source reachable-via any - sub-interfaces

[wherewolf]

Using a 1001x ASR and my 3 ISP outside connections, plus my inside interfaces toward the firewall are all via sub-interfaces on a 10 gig link. I looking for best practice on implementing uRPF on my router  -  would I apply ip verify unicast source reachable-via any on the MAIN OUTSIDE and MAIN INSIDE?  or apply it individually to each sub-interface?  all the interfaces? or just some?

Note:  I should also mention that I'm peered with the CYMRU ipv4 and ipv6 bogon BGP servers and have a 192.0.2.1 Null0 route for dropping traffic.  I also use a private internal BGP server to feed this edge router addresses and networks to be dropped/banned  based on what our firewall determines are bad actors.   

Thank you for any wisdom you can share!

Here is my setup:   

My Inside DMZ (both IPV4 and IPV6) is via Te0/0/1  with sub-int .101 (ipv4) and .106 (ipv6)

My ISP facing int is Te0/0/0 with sub-int .102, .103, and .104 (.103 and .104 are dual stacked) 

interface TenGigabitEthernet0/0/0
description OUTSIDE - MAIN INTERFACE
bandwidth 4000000
no ip address
cdp enable
ipv6 enable
!
interface TenGigabitEthernet0/0/0.102
description ISP1 HANDOFF
encapsulation dot1Q 102
ip flow monitor NETFLOW-MONITOR input
ip address xx.xx.xx.xx 255.255.255.252
ip access-group BLOCKOUTSIDE1 in
!
interface TenGigabitEthernet0/0/0.103
description ISP2 Handoff
bandwidth 2000000
encapsulation dot1Q 103
ip address xx.xx.xx.xx 255.255.255.254
ip access-group BLOCKOUTSIDE1 in
ipv6 address aaaa:bbbb::/127
ipv6 enable
!
interface TenGigabitEthernet0/0/0.104
description ISP3 HANDOFF
bandwidth 2000000
encapsulation dot1Q 104
ip address xx.xx.xx.xx 255.255.255.252
ip access-group BLOCKOUTSIDE1 in
ipv6 address bbbb:cccc::/126
ipv6 enable
!

interface TenGigabitEthernet0/0/1
description INSIDE MAIN INTERFACE
no ip address
cdp enable
ipv6 enable
!
interface TenGigabitEthernet0/0/1.101
description DMZ IPV4 INSIDE VLAN101
bandwidth 4000000
encapsulation dot1Q 101
ip address xx.xx.xx.xx 255.255.255.0
ip access-group BLOCKINSIDE1 in
!
interface TenGigabitEthernet0/0/1.106
description DMZ IPV6 INSIDE VLAN106
encapsulation dot1Q 106
cdp enable
ipv6 address cccc:dddd::/56
ipv6 enable
!

[chrihussey]

Just my opinion, apply the uRPF to just the inside sub-interfaces where I assume the originating / source IP addresses are known and not subject to change. If you apply it to the ISP interfaces, there is a chance traffic from the Internet may not come in from the expected ISP in which case it would be dropped.  

[wherewolf]

I am thinking (after much reading of documentation that doesn't quite give one the answers one is seeking) that the ip verify unicast source reachable-via *any* on the ISP facing interfaces should allow for the possibility of asymmetric traffic (multiple carriers inbound, normal for my situation - dual routers, multiple routes between the internet and the firewall) but yet be able to check sources against the routing tables which will include the team cymru bgp feed of bogon and martian lists, plus my own internal bgp feed of bad addresses/networks to drop.   Inbound traffic will be checked no matter what interface it comes in, and outbound would obviously hit the routing table also.  Any network/32 and above pointed to the NULL0 in the routing tables would be more specific/higher priority than the BGP weight of 20 and get dropped.    

[paul driver]

Hello
If you going to apply this on the wan interfaces be mindful of prefixes that fall into any default route, as such you will need to append "allow-default"

As for your lan interfaces you could become a more restrictive as I assume there is only one way in/out.

[MHM Cisco World]

I need to run lab to see effect of apply it on sub-interface. 
but as I know the sub-interfaces is separate from the view of uRPF, i.e. if the traffic enter in one sub-interface it can out through other sub-interface. 
but let me sure. 
update you soon

[wherewolf]

Thank you so much for assisting!   I don't have a lab setup, so testing things like this are risky in a production environment LOL!

[paul driver]

Hello
Using uRPF any function will allow return traffic from "any" interface as long as the rtr has a route in its route table for the destination return traffic, however it will fail if you are using a default route, but this can be overcome if you are using a default with " any allow-default"

Using the more restrictive RX function can prohibit traffic you may want to allow as it will only allow return traffic on the expected interface path its used to reach its intended host in the first place, Again this can be negated/bypassed by incorporating an permitted access-list stating the specific return traffic allowing to bypass the most restrictive RX uRPF function.

Example:
int x/x
ip verify unicast source reachable-via any
ip verify unicast source reachable-via any allow-default
ip verify unicast source reachable-via rx
ip verify unicast source reachable-via rx  xx  <permitted acl>

[wherewolf]

Thank you for your input - I think I've determined that "any" is the way to go here since I have multiple inbound routes (possible asymmetric) , and "load balanced" - ECMP outbound routes with full BGP routing tables, plus a few extra tables fed via BGP for security reasons (drop lists and bogon/martian feeds.)  Still not clear if I need this on the ISP facing interfaces or just the "inside" interfaces, but I guess trial-and-error is a valid testing method; just not the recommended one.... 

[wherewolf]

To summarize my working solution:

1.  applied ip verify unicast source reachable-via any to all my ipv4 sub-interfaces facing the ISP's  (I have full BGP routers IPV4) and on the DMZ inside interfaces. (also ipv6 verify unicast source reachable-via any to the inside IPv6 int)

2.  applied ipv6 verify unicast source reachable-via any allow-default to the ipv6 sub-interfaces facing the ISP's (BGP peers are only sending me a default route) 

This the best of my knowledge and testing, this configuration allows for asymmetrical traffic (due to multipaths inbound and ECMP outbound) but still allows for checking the routing tables for the null0 routes I have setup in BGP for DBL lists, bogons and martians, and RTBH triggers from my internal BGP peering server.  This configuration covers both inbound and outbound traffic.    Thank you to all contributors! 

[MHM Cisco World]

Thanks for update us, 

I was looking for modes

Loose and strict mode and it compatibility with asymmetrical routing. 

Sorry I late and until now I dont get confirm answer. 

When I get I will share here. 

Thanks 

MHM