ospf multiple area, summarization, stubs...

i've been saying this for a long time... all of this is over-engineering... it's easily relegated to network trivia, or a "we do it because we can" philosophy... but nobody wants to hear me say it... listen to these guys then...

it is no wonder my mind glazes over when these discussions come up...

http://packetpushers.net/show-134-ospf-design-part-1-debunking-the-multiple-area-myth/

and we'll have an area here and here and here, and this will be a stub, and we'll summarize there, and that needs to be nssa because it sounds cool and we get to use it in a sentence... gimme a break...

crookbook eigrp summ...

add loopbacks to r1... add auto-summary...

it is very contrived, suck it up...

interface Loopback1
 ip address 192.168.1.1 255.255.255.252
!
interface Loopback2
 ip address 192.168.1.9 255.255.255.252
!
interface Loopback3
 ip address 192.168.1.17 255.255.255.252

r2#sh ip route eigrp

Gateway of last resort is not set

D     1.0.0.0/8 [90/2297856] via 10.1.1.1, 00:00:16, Serial2/0
D     192.168.1.0/24 [90/2297856] via 10.1.1.1, 00:00:16, Serial2/0

auto summary makes summarization at the classful border...

lose it...

r2#sh ip route eigrp

Gateway of last resort is not set

      1.0.0.0/24 is subnetted, 1 subnets
D        1.1.1.0 [90/2297856] via 10.1.1.1, 00:00:11, Serial2/0
      192.168.1.0/30 is subnetted, 3 subnets
D        192.168.1.0 [90/2297856] via 10.1.1.1, 00:00:11, Serial2/0
D        192.168.1.8 [90/2297856] via 10.1.1.1, 00:00:11, Serial2/0
D        192.168.1.16 [90/2297856] via 10.1.1.1, 00:00:11, Serial2/0

and you get them all...

to summarize at the longest prefix, count...

0 to 16 includes 0 and that means 17, so the summary needs to be more than 16 and less than 32...  256 minus 32 = 224 or /24 + 3 or /27...

int s2/0
ip summary-add eigrp 1 192.168.1.0 255.255.255.224

r2#sh ip route eigrp

Gateway of last resort is not set

      1.0.0.0/24 is subnetted, 1 subnets
D        1.1.1.0 [90/2297856] via 10.1.1.1, 00:06:45, Serial2/0
      192.168.1.0/27 is subnetted, 1 subnets
D        192.168.1.0 [90/2297856] via 10.1.1.1, 00:00:16, Serial2/0

/28 doesn't get it...

int s2/0
ip summary-add eigrp 1 192.168.1.0 255.255.255.240

r2#sh ip route eigrp

Gateway of last resort is not set

      1.0.0.0/24 is subnetted, 1 subnets
D        1.1.1.0 [90/2297856] via 10.1.1.1, 00:09:25, Serial2/0
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
D        192.168.1.0/27 [90/2297856] via 10.1.1.1, 00:02:56, Serial2/0
D        192.168.1.0/28 [90/2297856] via 10.1.1.1, 00:00:42, Serial2/0

this has been a public service announcement...

summarization redux...

are you sick of writing down all the bits then counting from left to right... me too...
look at the examples below and answer the multiple choice...

summarize 10.1.32.0 to 10.1.35.255?

        a)10.1.32.0/23
        b)10.1.32.0/22
        c)10.1.32.0/21
        d)10.1.32.0/20


summarize 172.168.12.0/24 to 172.168.13.0/24?

        a)172.168.12.0/23
        b)172.168.12.0/22
        c)172.168.12.0/21
        d)172.168.12.0/20

example 1
step 1: identify the octet where the action is.  the action is where the numbers change
in the first example the numbers change in the third octet, and like wise in the second example

.32 to .35 (you don't have to write down all the numbers, just the beginning and end of the range)
and .12 to .13

step 2: the first 2 octets are the same 10.1 and 172.168. together they comprise 16 bits so 16 is our working number

step 3: write down the first number .32 in example 1 and the last number where the change occurred, .35

.32
0010 0000

.35
0010 0011

count up to, but not including where the bits change and add 16 + 6  = /22
16 is the working number, determined by the address where there are no changes and 6 is the last position in the octet before a change

example 2
summarize 172.168.12.0/24 to 172.168.13.0/24?

the change happens in the third octet

     .12
0000 1100

     .13
0000 1101

16 plus 7 = /23
     
Class of address does not matter... the working number is always determined by the octet where the change occurs...

not sure about you, but there are a lot less 1's and zero's to count with my method... go ahead and prove this wrong...