From: Antonio Soares (amsoares@netcabo.pt)
Date: Sat Jul 07 2007 - 15:43:44 ART
Hi Mike,
The "allow-self-ping" option is available with the old sintax:
++++++++++++++++++++++++++++++++++++++
R6#sh runn int f0/0
Building configuration...
Current configuration : 127 bytes
!
interface FastEthernet0/0
ip address 67.67.67.6 255.255.255.0
ip verify unicast reverse-path
duplex auto
speed auto
end
++++++++++++++++++++++++++++++++++++++
R6#ping 67.67.67.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 67.67.67.6, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
++++++++++++++++++++++++++++++++++++++
R6#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R6(config)#int f0/0
R6(config-if)# ip verify unicast reverse-path a
R6(config-if)# ip verify unicast reverse-path allow-self-ping
R6(config-if)#end
R6#
++++++++++++++++++++++++++++++++++++++
R6#
R6#ping 67.67.67.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 67.67.67.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R6#
++++++++++++++++++++++++++++++++++++++
But yes, i agree we may need to use the new sintax depending on the
requirements.
Thanks,
Antonio
-----Original Message-----
From: Mike Kraus (mikraus) [mailto:mikraus@cisco.com]
Sent: sabado, 7 de Julho de 2007 16:27
To: Antonio Soares; ccielab@groupstudy.com
Subject: RE: Configuring Unicast Reverse Path Forwarding
I'd say it all depends on the requirements of the question. If you meet the
requirements, the "old way" would still be fine.
But, say the question said that you want to allow the router to ping its own
interface or to allow traffic to pass the RPF check as long as it is
reachable by any interface (not just the one it was received on), then you
would be forced into using the new command.
There is more than one right answer to any given question... At the same
time, as long as you are able to talk intelligently about both methods, you
could certainly ask the proctor if they had a preference and they may be
able to guide you.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Antonio Soares
Sent: Saturday, July 07, 2007 8:53 AM
To: ccielab@groupstudy.com
Subject: Configuring Unicast Reverse Path Forwarding
Hello group,
I want to share my findings about this feature and i also have a question.
There are at least 5 ways to configure it:
1) Silently drop all packets that fail the uRPF Check:
!
interface Serial1/3
ip address 23.23.23.3 255.255.255.0
ip verify unicast reverse-path
!
2) Forward all packets that fail the uRPF Check:
!
interface Serial1/3
ip address 23.23.23.3 255.255.255.0
ip verify unicast reverse-path 3
!
access-list 3 permit any
!
3) Forward and log all packets that fail the uRPF Check:
!
interface Serial1/3
ip address 23.23.23.3 255.255.255.0
ip verify unicast reverse-path 3
!
access-list 3 permit any log
!
4) Drop all packets that fail the uRPF Check:
!
interface Serial1/3
ip address 23.23.23.3 255.255.255.0
ip verify unicast reverse-path 3
!
access-list 3 deny any
!
5) Drop and log all packets that fail the uRPF Check:
!
interface Serial1/3
ip address 23.23.23.3 255.255.255.0
ip verify unicast reverse-path 3
!
access-list 3 deny any log
!
The command reference says that the "ip verify unicast reverse-path" was
replaced by the new "ip verify unicast source reachable-via" command but i
see that in 12.4 both commands are still available.
In the lab, it's ok to use the old format ?
Thanks,
Antonio
This archive was generated by hypermail 2.1.4 : Sat Aug 18 2007 - 08:17:40 ART