From: asadovnikov (asadovnikov@comcast.net)
Date: Thu Aug 04 2005 - 03:44:07 GMT-3
Jody,
Wording of 14.12.1 may be not perfectly clear.
"R5 must accept packets sourced from AS400 networks advertised in a previous
task from R4 only."
What it meant to say that R5 should accept packets sourced from AS400
networks only if the packets arrive via R4 (versus to packets sourced from
AS400 and arriving via R2).
I think you may have read it differently and it resulted in your ACL to be
mirror image of what is in the answer key.
Let us start with normal network conditions (no failures) and look at 4.12.1
& 4.12.2
Router R5 would have IP route for the network 192.168.100.0/24 pointing to
R4:
------------------------------R5------------------------------
R5#show ip route | i 192.168.100.0
B 192.168.100.0/24 [20/0] via 172.16.45.4, 11:25:52
Let us follow the quote from documentation in your email, and look at the
unicast RPF check configured on S1/0 (R2 connection)
interface Serial1/0
ip address 172.16.25.5 255.255.255.0
ip verify unicast reverse-path 107
!
access-list 107 deny ip 192.168.100.64 0.0.0.63 any
access-list 107 permit ip any any
The uRPF check will fail, and the packets from AS 400 will be denied (all
other packets are permitted as there is no restriction for traffic not
sourced from AS 400). The configuration above will deny traffic in question
from R2.
Now, if we look at Fa0/0.50
interface FastEthernet0/0.50
encapsulation dot1Q 50
ip address 172.16.45.5 255.255.255.0
ip verify unicast reverse-path 107
!
the uRPF check will not fail on this interface for packets from AS 400, and
subsequently the packets will be allowed in as ACL attached to uRPF is not
interrogated for packets passing uRPF check.
Let us now move to network failure situation (i.e. R4-R5 link is down) and
look at 4.12.3
R5 will now have the route pointing to R2 which will make packets from AS
400 pass uRPF check and allowed in.
In the fact the way section 4.12 is put now uRPF configuration is only
required on S1/0 and not on Fa0/0.50. The intention here was to follow
routing and to allow for indirect failures to be accommodated in the check.
I will follow up to get section reviewed to reflect that.
Best Regards,
Alexei
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Jody
Davis (joddavis)
Sent: Tuesday, August 02, 2005 1:12 PM
To: ccielab@groupstudy.com
Subject: FW: Doit Lab Security Section Question...
All,
Doit Lab 4, 4.12 Security states:
* R5 must accept packets sourced from AS400 networks advertised in
a previous task from R4 only.
* Do not use "ip access-group" to accomplish this task
The network from AS400 are the 192.168.100.64 --> 192.168.100.127
Since we want to "only allow networks from AS400", would this be the
correct configuration?
int vlan50
ip verify unicast reverse-path 197
!
access-list 197 permit ip 192.168.100.64 0.0.0.63
access-lust 197 deny ip any any
The netmasters "Showit" Example shows that just the opposite with the
acl..
access-list 197 deny ip 192.168.100.64 0.0.0.63
access-lust 197 permit ip any any
________________________________
Access Control Lists and Logging
If an ACL is specified in the command, then when (and only when) a
packet fails the Unicast RPF check, the ACL is checked to see if the
packet should be dropped (using a deny statement in the ACL) or
forwarded (using a permit statement in the ACL). Whether a packet is
dropped or forwarded, the packet is counted in the global IP traffic
statistics for Unicast RPF drops and in the interface statistics for
Unicast RPF.
If no ACL is specified in the Unicast RPF command, the router drops the
forged or malformed packet immediately and no ACL logging occurs. The
router and interface Unicast RPF counters are updated.
Unicast RPF events can be logged by specifying the logging option for
the ACL entries used by the Unicast RPF command. Using the log
information, administrators can see what source addresses are being used
in the attack, the time the packets arrived at the interface, and so on.
Jody
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:01:18 GMT-3