Wednesday, April 19, 2006
Access Lists. (Question #55)
Assume that the 192.168.15.16/28 network has a collection of Linux and Windows PCs on it. The addressing scheme is such that the Linux PCs have the addresses
192.168.15.17
192.168.15.19
192.168.15.21
and so on through to 192.168.15.29 while the Windows PCs have the addresses
192.168.15.18
192.168.15.20
192.168.15.22
and so on through to 192.168.15.30.
All the PCs connect to the core network via a router on the same subnet.
One day all the Windows PCs get infected by a virus and start sourcing large amounts of network traffic. Your task is to create an access list to be used on the router for the subnet which drops all network traffic from the Windows PCs while allowing traffic from the Linux PCs.
Can you create an ACL with just two access list entries that will match traffic sourced from all the Windows PCs and drop them while allowing all other traffic?
192.168.15.17
192.168.15.19
192.168.15.21
and so on through to 192.168.15.29 while the Windows PCs have the addresses
192.168.15.18
192.168.15.20
192.168.15.22
and so on through to 192.168.15.30.
All the PCs connect to the core network via a router on the same subnet.
One day all the Windows PCs get infected by a virus and start sourcing large amounts of network traffic. Your task is to create an access list to be used on the router for the subnet which drops all network traffic from the Windows PCs while allowing traffic from the Linux PCs.
Can you create an ACL with just two access list entries that will match traffic sourced from all the Windows PCs and drop them while allowing all other traffic?
Comments:
<< Home
Ryan's suggestion looks good to me. I personally find it easier to just use the "standard" deny even's with (easy for me to always remember this and the "standard" odd)
deny 192.168.15.0 0.0.0.254
and then allow what falls though to the /28 network as Ryan has.
permit 192.168.15.16 0.0.0.15
deny 192.168.15.0 0.0.0.254
and then allow what falls though to the /28 network as Ryan has.
permit 192.168.15.16 0.0.0.15
The answer I had in mind when I framed the question was the following.
access-list 10 permit 192.168.15.17 0.0.0.14
will match all the PCs with odd addresses (Linux PCs).
access-list 10 permit 192.168.15.16 0.0.0.14
will match all the PCs with even addresses (Windows PCs).
So, to match the Windows PCs traffic in order to deny them one would do something like
access-list 10 deny 192.168.15.16 0.0.0.14
access-list 10 permit any
However, I liked Ryan's final attempt at the answer with the single statement that relies on the implict deny at the end
access-list 10 permit 192.168.15.17 0.0.0.14
This was basically an attempt on my part to elicit the trick with matching odd or even networks by framing something like a real world problem where that knowledge could have been applied fruitfully.
access-list 10 permit 192.168.15.17 0.0.0.14
will match all the PCs with odd addresses (Linux PCs).
access-list 10 permit 192.168.15.16 0.0.0.14
will match all the PCs with even addresses (Windows PCs).
So, to match the Windows PCs traffic in order to deny them one would do something like
access-list 10 deny 192.168.15.16 0.0.0.14
access-list 10 permit any
However, I liked Ryan's final attempt at the answer with the single statement that relies on the implict deny at the end
access-list 10 permit 192.168.15.17 0.0.0.14
This was basically an attempt on my part to elicit the trick with matching odd or even networks by framing something like a real world problem where that knowledge could have been applied fruitfully.
isn't 192.168.15.18 0.0.0.30 matching all even numbers between 18 and 30? since 16 is the network number and will be dropped by the router if it's sourced from the inside the subnet therefire it should cover the requirement?
192.168.15.18 0.0.0.30 does match all the even networks of interest and so it would work but it also matches much more. For instance it would also match 192.168.15.2. I guess with ACLs it's usually best to be as restrictive as possible and only allow what should be allowed and nothing else. That assumption was implicit in the question but your answer would also work for the question as it is currently stated.
It occurs to me after having run into such alternate answers from readers more than once that even on the real Cisco exam people must be coming up with answers that are right but not the "expected" answer. One hopes that the Cisco exam folks take that into account and do give credit where credit is due with such alternate correct answers when there is some ambiguity in the question itself.
Post a Comment
It occurs to me after having run into such alternate answers from readers more than once that even on the real Cisco exam people must be coming up with answers that are right but not the "expected" answer. One hopes that the Cisco exam folks take that into account and do give credit where credit is due with such alternate correct answers when there is some ambiguity in the question itself.
<< Home