Unicast Reverse Path Forwarding

Topology

bfd

Test scenario
1. R1 will be sending traffic towards 1.1.1.1 via R2.
2. First is to test uRPF strict mode by sending traffic towards 1.1.1.1 using R1’s interface e0/0 ip address.
3. Second is to test uRPF loose mode by sending traffic towards 1.1.1.1 using R1’s interface e0/1 ip address.

Strict Mode

Configure R2’s e0/0 in uRPF strict mode. In order for bfd and uRPF to work together, I need to disable bfd echo.


R2#sh run int e0/0
!
interface Ethernet0/0
 ip address 192.168.1.2 255.255.255.252
 no ip redirects
 ip verify unicast source reachable-via rx
 bfd interval 500 min_rx 500 multiplier 3
 no bfd echo
end

In strict mode the R2 verifies the source address from R1 is reachable by its interface Ethernet 0/0. this is the current R2's route in the routing table


R2#sh ip route

      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
      2.0.0.0/32 is subnetted, 1 subnets
S        2.2.2.2 [1/0] via 192.168.1.1, Ethernet0/0
      192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks
C        192.168.1.0/30 is directly connected, Ethernet0/0
L        192.168.1.2/32 is directly connected, Ethernet0/0
C        192.168.1.4/30 is directly connected, Ethernet0/1
L        192.168.1.6/32 is directly connected, Ethernet0/1

R2's interface E0/0 will accept traffic from source address 2.2.2.2 and 192.168.1.1 because these addresses are reachable by R2's interface e0/0.

Let's test this from R1 by using loopback 0 and Ethernet0/0 as the source address.


R1#ping 1.1.1.1 source lo0  repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/1/1 ms
R1#

R1#ping 1.1.1.1 source e0/0  repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/1/1 ms
R1#

Let's test from R1 by using address that are not reachable from R2's Ethernet0/0


R1#ping 1.1.1.1 source e0/1  repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.5
.....................................................
Success rate is 0 percent (0/53)

Because the network 192.168.1.4/30 is not reachable via R2's E0/0 the traffic is dropped. See R2's verification drops, verification drops increased when the source address verification failed.


R2#sh ip int e0/0 | in drop
   4 verification drops
   0 suppressed verification drops
   0 verification drop-rate
R2#sh ip int e0/0 | in drop
   5 verification drops
   0 suppressed verification drops
   0 verification drop-rate
R2#sh ip int e0/0 | in drop
   5 verification drops
   0 suppressed verification drops
   0 verification drop-rate
R2#sh ip int e0/0 | in drop
   5 verification drops
   0 suppressed verification drops
   0 verification drop-rate
R2#sh ip int e0/0 | in drop
   6 verification drops
   0 suppressed verification drops
   0 verification drop-rate

uRPF strict mode impact a network having asymmetric routes. Hence for network that has asymmetric routes, loose mode is use.

Loose mode
Source address verification will pass if the source address exists in R2's routing table.


R2(config)#int e0/0
R2(config-if)#ip verify unicast source reach any

Let's test from R1 using its e0/1 address which failed ping test previously when R2's E0/0 was using uRPF strict mode


R1#ping 1.1.1.1 source e0/1  repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.5
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/1/1 ms
R1#

From R2's interface we will see an increase of 100 suppressed verification drops. Suppressed verification drops mean those traffic that supposed to fail verification check is allowed by ACL or by Loose mode.


R2#sh ip int e0/0 | in drop
   8 verification drops
   100 suppressed verification drops
   0 verification drop-rate
R2#

Let's try from R1's loopback2 address that is not even in R2's routing table.


R1#ping 1.1.1.1 source lo2  repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
.........
Success rate is 0 percent (0/9)

From R2's interface drop counters:


R2#sh ip int e0/0 | in drop
   17 verification drops
   100 suppressed verification drops
   0 verification drop-rate
R2#

As observed from above there was increase in verification drops from R2's interface E0/0.

Advertisements
This entry was posted in General stuffs, Security and tagged , , , , . Bookmark the permalink.

2 Responses to Unicast Reverse Path Forwarding

  1. Ram says:

    thanks ……………..

  2. Slevin says:

    I see you are using unetlab also, im quite a gns3 junky, but unet is more cloud based, accesible from anywhere, u fancy helping me with some broadcast domains in unet, i can give access to my lab if needs to be

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s