From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu Dec 23 2004 - 21:55:48 GMT-3
Marc,
Each line in an access-list that a packet has to be checked
against uses additional CPU cycles and causes additional delay for the
packet. In today's networks, both of these may be negligible, but it's
always good to be as efficient as possible.
Within the scope of the CCIE lab however is it feasible that
they could ask a question such as "Configure R1 so that it doesn't
accept traffic from hosts 10.10.10.100 - 10.10.10.150. Use the most
efficient access-list with the minimum number of lines, and do not deny
traffic from any other hosts." In this case obviously using a mask of
0.0.0.255 is not feasible. Now we have to go through the motions of
trying to pair the addresses up and see how many lines we can get down
to.
At first glance this is how I would break it down:
10.10.10.100 0.0.0.3
--------------------
100 01100100
101 01100101
102 01100110
103 01100111
10.10.10.104 0.0.0.7
--------------------
104 01101000
105 01101001
106 01101010
107 01101011
108 01101100
109 01101101
110 01101110
111 01101111
10.10.10.112 0.0.0.15
------------------
112 01110000
113 01110001
114 01110010
115 01110011
116 01110100
117 01110101
118 01110110
119 01110111
120 01111000
121 01111001
122 01111010
123 01111011
124 01111100
125 01111101
126 01111110
127 01111111
10.10.10.128 0.0.0.15
---------------------
128 10000000
129 10000001
130 10000010
131 10000011
132 10000100
133 10000101
134 10000110
135 10000111
136 10001000
137 10001001
138 10001010
139 10001011
140 10001100
141 10001101
142 10001110
143 10001111
10.10.10.144 0.0.0.3
--------------------
144 10010000
145 10010001
146 10010010
147 10010011
10.10.10.148 0.0.0.1
--------------------
148 10010100
149 10010101
10.10.10.150 0.0.0.0
--------------------
150 10010110
The final access-list would read:
access-list 1 deny 10.10.10.100 0.0.0.3
access-list 1 deny 10.10.10.104 0.0.0.7
access-list 1 deny 10.10.10.112 0.0.0.15
access-list 1 deny 10.10.10.128 0.0.0.15
access-list 1 deny 10.10.10.144 0.0.0.3
access-list 1 deny 10.10.10.148 0.0.0.1
access-list 1 deny 10.10.10.150 0.0.0.0
access-list 1 permit any
Now let's see how many addresses this encompasses:
10.10.10.100 0.0.0.3 = 2^2 = 4
10.10.10.104 0.0.0.7 = 2^3 = 8
10.10.10.112 0.0.0.15 = 2^4 = 16
10.10.10.128 0.0.0.15 = 2^4 = 16
10.10.10.144 0.0.0.3 = 2^2 = 4
10.10.10.148 0.0.0.1 = 2^1 = 2
10.10.10.150 0.0.0.0 = 2^0 = 1
4 + 8 + 16 + 16 + 4 + 2 + 1 = 51
100 through 150 inclusive is 151 addresses, so the access-list does not
overlap.
Make sense?
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: Marc Steiniger [mailto:marc.steiniger@gmail.com]
> Sent: Thursday, December 23, 2004 3:27 PM
> To: Brian McGahan
> Subject: Re: Inverse mask question - How - ???? [7:95532]
>
> Hey Brian, I'm responding off-list to this. First off, Thanks for
> posting that link, I can't remember seeing a more straightforward
> explanation of the logic used when applying masks to addresses.
>
> I actually took a quick moment to apply the posted method to the range
> of IPs initially presented in the question, and came out with the
> following:
>
> IP Decimal 1st Octet 2nd Octet 3rd
Octet 4th
> Octet
>
> 10.10.10.100 00001010 00001010 00001010 01100100
> 10.10.10.101 00001010 00001010 00001010 01100101
> 10.10.10.102 00001010 00001010 00001010 01100110
> 10.10.10.103 00001010 00001010 00001010 01100111
> 10.10.10.104 00001010 00001010 00001010 01101000
> 10.10.10.105 00001010 00001010 00001010 01101001
> 10.10.10.106 00001010 00001010 00001010 01101010
> 10.10.10.107 00001010 00001010 00001010 01101011
> 10.10.10.108 00001010 00001010 00001010 01101100
> 10.10.10.109 00001010 00001010 00001010 01101101
> 10.10.10.110 00001010 00001010 00001010 01101110
> 10.10.10.111 00001010 00001010 00001010 01101111
> 10.10.10.112 00001010 00001010 00001010 01110000
> 10.10.10.113 00001010 00001010 00001010 01110001
> 10.10.10.114 00001010 00001010 00001010 01110010
> 10.10.10.115 00001010 00001010 00001010 01110011
> 10.10.10.116 00001010 00001010 00001010 01110100
> 10.10.10.117 00001010 00001010 00001010 01110101
> 10.10.10.118 00001010 00001010 00001010 01110110
> 10.10.10.119 00001010 00001010 00001010 01110111
> 10.10.10.120 00001010 00001010 00001010 01111000
> 10.10.10.121 00001010 00001010 00001010 01111001
> 10.10.10.122 00001010 00001010 00001010 01111010
> 10.10.10.123 00001010 00001010 00001010 01111011
> 10.10.10.124 00001010 00001010 00001010 01111100
> 10.10.10.125 00001010 00001010 00001010 01111101
> 10.10.10.126 00001010 00001010 00001010 01111110
> 10.10.10.127 00001010 00001010 00001010 01111111
> 10.10.10.128 00001010 00001010 00001010 10000000
> 10.10.10.129 00001010 00001010 00001010 10000001
> 10.10.10.130 00001010 00001010 00001010 10000010
> 10.10.10.131 00001010 00001010 00001010 10000011
> 10.10.10.132 00001010 00001010 00001010 10000100
> 10.10.10.133 00001010 00001010 00001010 10000101
> 10.10.10.134 00001010 00001010 00001010 10000110
> 10.10.10.135 00001010 00001010 00001010 10000111
> 10.10.10.136 00001010 00001010 00001010 10001000
> 10.10.10.137 00001010 00001010 00001010 10001001
> 10.10.10.138 00001010 00001010 00001010 10001010
> 10.10.10.139 00001010 00001010 00001010 10001011
> 10.10.10.140 00001010 00001010 00001010 10001100
> 10.10.10.141 00001010 00001010 00001010 10001101
> 10.10.10.142 00001010 00001010 00001010 10001110
> 10.10.10.143 00001010 00001010 00001010 10001111
> 10.10.10.144 00001010 00001010 00001010 10010000
> 10.10.10.145 00001010 00001010 00001010 10010001
> 10.10.10.146 00001010 00001010 00001010 10010010
> 10.10.10.147 00001010 00001010 00001010 10010011
> 10.10.10.148 00001010 00001010 00001010 10010100
> 10.10.10.149 00001010 00001010 00001010 10010101
> 10.10.10.150 00001010 00001010 00001010 10010110
>
> AND 1010 1010 1010 0
> XOR 0 0 0 11111111
>
> Giving me a single-line solution of address=10.10.10.0
> wildcard=0.0.0.255, which obviously matches the entire /24 subnet.
>
> Other than having a single-line match-statement, is there any
> advantage to wildcard masking a range (IE more than two IP's) using
> this method rather than trying to most closely match the subnet
> borders, in this case using two match statements?
>
> thanks,
> Marc
>
>
>
> On Thu, 23 Dec 2004 10:55:35 -0500, Brian McGahan
> <bmcgahan@internetworkexpert.com> wrote:
> > Write out the range in binary to see the bit patterns. Based on
this
> > use the calculations in this white paper:
> >
> > http://www.internetworkexpert.com/resources/01700370.htm
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf
> > Of
> > > Cisco Nuts
> > > Sent: Thursday, December 23, 2004 12:36 AM
> > > To: cisco@groupstudy.com
> > > Subject: Inverse mask question - How - ???? [7:95532]
> > >
> > > What is the correct way to calculate the inverse mask for a range
of
> > > hosts?
> > >
> > > For ex. if I wanted to deny or permit just ip's b/w 100 through
150 in
> > the
> > > network 10.10.10.0/24, how would I calculate that?
> > >
> > > Calculating the inverse mask for a particular subnet is
> > > straightforward(1,3,
> > > 7, 15, 31, 63, 127,255) but this one - How ??
> > >
> > > Thank you for your help.
> > > Sincerely.
> > >
> > > CN
This archive was generated by hypermail 2.1.4 : Mon Jan 03 2005 - 10:31:29 GMT-3