chapter 2: Access-list Basics
Friday, March 27, 2009
chapter 2: Access-list Basics
-----------------------------
Two basic access-list type:
> The first kind of access-list is standard access-list used to build policy set of ip
address or ip networks
> Standard access-list cannot do all policies we may wish to specify , particularly when we
want to do packet filetering
> Extended access-list extends the format of the standard access-list to specify packet
filtering policies
2.1 Standard access lists:
--------------------------
A network administrator typically uses standard access-list to implement three types of
policy controls:
> access to router resources
> route distribution
> packets passing through a router
These policy controls use / require policy sets of ip addresses or network numbers , so the
standard access-list is used to build policy sets of either ip addresses or numbers
example 1:
---------
policy set 1: ip address 192.168.30.1
policy set 1: ip address 192.168.33.5
policy set 1: deny others
how does this policy set map to acutal access-list?
access-list 1 permit 192.168.30.1
access-list 1 permit 192.168.33.5
access-list 1 deny 0.0.0.0 255.255.255.255
> The number after access-list keyword is access-list number . In this case it is 1
The number also specifies what kind of access-list it is
> Different types of access-list for different network protocols uses different ranges of
access-list numbers
ip uses 1-99 for standard access-list
100-199 for extended access-list
ipx uses 800-899 for its standard acl
decnet uses 300-399
> The permit keyword includes ip address in the policy set
The deny key word excludes the ip address following from the policy set
if we want to control router-login access
line vty 0 4
access-class 1 in
2.1.1 The implicit deny
-----------------------
access-list 2 deny 192.168.30.1
access-list 2 permit 192.168.33.5
this can also be written (or same as)
access-list 2 permit 192.168.33.5
> This is beacuse access-lists have an implicit deny at the end of them . everthing not
explicitly permitted in standard acl is denied
2.1.2 Standard access-list and route filtering
----------------------------------------------
follow the example from the labbing here are the outputs
r0#show access-list
Standard IP access list 1
10 permit 1.1.1.1 (10 matches)
20 permit 3.3.3.3 (10 matches)
30 permit 7.7.7.7 (4 matches)
40 permit 1.1.1.0
50 permit 5.5.5.0
router eigrp 20
distribute-list 1 in fast 0/0
also remember distribute list and the error commited (should always give network which
matches the routing table not the network which can alternatively match the ip address
for example to deny 1.1.1.1 to enter into routing table , the network 1.0.0.0 should be
mentioned in the routing table and not 1.1.1.0 which dosent match the routing table entry )
---------------------------------------------------------------------------------------------
2.1.3 Access-list wildcard masks:
---------------------------------
> An optional wild card mask can be uses to include many addresses in a policy set
access-list 3 permit 192.168.3.0 0.0.0.255
2.1.4 Specifying hosts in a subnet versus specifying a subnet:
--------------------------------------------------------------
> It is important to distinguish between specifying a network number and the host for
inclusion in a policy set nd specifying all of the hosts in a policy set
access-list 3 permit 192.168.30.0 0.0.0.255
includes all of the hosts in network 192.168.30.0/24
* This is not same as the below acl:
access-list 4 permit 192.168.30.0
This access-list entry includes the single ip address 192.168.30.0 in a policy set
192.168.30.0 could be one of the two:
a host ip address or a network number
line vty 0 4
access-class 4 in
only a host with the potentially valid ip of 192.168.30.0 would be permitted to have login
access to the router
> acl 4 would more typically be used to build a policy set of network addresses in routing
context
router eigrp 100
distribute-list 4 in serial 0/0
here only route to network 192.168.30.0 would be permitted into the routing table via eigrp
routing protocol
>* IN general it is best to be as specific as possible when defining policy sets