In this small post i want to clarify the use of the “ip verify” command.
There has been some confusion on the usage of this command, especially in conjunction with the access-list parameter. I would like to clarify this here.
The command is basically a way to mitigate spoofing. You want to make sure that the source of the packet is received from the correct path, meaning interface.
First off the topology:
We only have two routers here. R1 and R2.
R1 has a loopback0 interface with the 100.100.100.100/32 address.
R2 has two loopback interfaces. Loopback0, also with 100.100.100.100/32 and loopback200 with address 200.200.200.200/32.
R1 has a default route pointing to R2 (192.168.12.2):
Reachability in this example is not important, but the output of R2 is. So lets turn on debugging on R2:
So lets start with something that should work, namely a ping from R1 to R2. Without any parameters the ping will be sourced with 192.168.12.1:
And we can see on R2 that everything is as we expect:
Now for the next part, we wont actually get a response back from R2. The reason for this is ofcourse that the source address is locally defined as the loopback0 interface. However it does demonstrates that R2 accepts the packet:
And on R2:
The command itself is interface specific. It also has an older version which accomplish the same but i wont cover (all interface is on R2 s0/0):
Digging a bit deeper we get:
The any option basically tells the router to accept the packet if any known route to the source exists. The RX option will only accept the packet if the source of the packet is reachable through the received interface.
For this test, remember that R2 thinks that the correct path to reach 100.100.100.100 is on its loopback0 interface:
And lets try from R1 again, using 100.100.100.100 as the source:
And on R2 nothing happens.
It is simply denying the packet.
Modifying the command on R2 to:
And again from R1:
And on R2 we now see we get a reply. R2 does have a route to 100.100.100.100, even though it is its own loopback interface.
Lets modify the R2 config back to RX mode but also see what options we have:
Hmm. the access-list. How does that work?
It works in the following way, when a packet fails the verification, and only then, it goes through a second check. It checks the access-list to see if by any chance the source of this packet should be allowed anyways. If there is a permit for the source, it wont get dropped even though it failed the initial verification.
So lets write a simply standard access-list for our 100.100.100.100 network:
(please note that the explicit deny is not nessecary).
And lets attach it to the command:
Now once again, lets try from R1:
And the output on R2:
So there we have it. It fails the first verification, but after checking the ACL it allows the the packet to go through anyways because of the permit statement.
A last note, the allow-default parameter makes it so it will take a default route into account. The allow-self-ping makes it so the router can actually ping its own interface without failing the verification.
Hope this shed some light on this command.