GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
RE: summary-address in ospf and redistribution posted 05/10/2001
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


thanks for the ideas. I will keep playing with it. 

-----Original Message-----
From: Jim Graves [mailto:jtg@xxxxxxxxxx]
Sent: Wednesday, May 09, 2001 8:32 PM
To: Ron Carithers; 'lkouncar@xxxxxx'; Ron Carithers; 'Rob Hopkins'
Cc: ccielab@xxxxxxxxxxxxxx
Subject: RE: summary-address in ospf and redistribution


I'm not all that suprised that the CCIE Lab Practice Kit solution doesn't 
work.  That book is full of errors.

Try removing passive-interface s0/0 from the igrp process, or 
redistributing connected.  I know the passive-interface is required by 
another part of that lab, but give it a shot anyway.

I'm developing what I think is a key to how to get ospf summary-address to 
work: the network to be summarized must appear as an external LSA in the 
ospf database.  If it's there, a null0 route will be injected, and the 
summary advertized.  If there is no type 5 LSA for a network you're 
summarizing, the null0 route won't be injected, and it won't be advertized.

Redistributing connected would do that.  I think removing passive-interface 
would also do it (I'm not as sure about that, though).

I also suspect that the order commands are typed makes a big 
difference.  In playing with this not long ago, I found that once a type-5 
LSA makes it into OSPF, it can sometimes bounce around forever even after 
the external route isn't being advertized.  If IGRP is configured first, 
and then passive-interfaces are added, the external LSA gets in and stays 
in.  If the passive interfaces are added before network statements, the 
external LSA doesn't get in.

Anyway, that's my current suspicion/superstition.  Find a way to get 
152.1.2.128 to show up as external, and everything will fall into place.

(Note that I haven't done this particular lab yet, so I may be full of it.)

At 07:30 PM 5/9/2001 -0700, Ron Carithers wrote:
>Below is the config from R6. It's supposed to send 152.1.1.0/24 and
>152.1.2.0/24 through IGRP (e1/0) to R8. When I turn on IGRP debugs I don't
>see it send the routes. Thanks for any help.
>Ron
>
>service timestamps debug uptime
>no service password-encryption
>no service udp-small-servers
>no service tcp-small-servers
>no cdp run
>!
>hostname R6
>!
>!
>username R1 password 0 cisco
>ip subnet-zero
>isdn switch-type basic-ni1
>!
>interface Loopback0
>  ip address 152.1.12.1 255.255.255.0
>!
>interface Ethernet0/0
>  ip address 152.1.11.1 255.255.255.0
>!
>interface Serial0/0
>  backup delay 5 20
>  backup interface BRI1/0
>  ip address 152.1.2.130 255.255.255.128
>  ip ospf authentication-key cisco1
>!
>
>interface Ethernet1/0
>  ip address 152.1.0.1 255.255.255.0
>!
>!
>interface BRI1/0
>  ip address 152.1.1.78 255.255.255.252
>  encapsulation ppp
>  ip ospf demand-circuit
>  isdn spid1 5201
>  isdn spid2 5202
>  dialer map ip 152.1.1.77 name R1 broadcast 8995101
>  dialer load-threshold 1 outbound
>  dialer-group 1
>  no fair-queue
>  ppp callback request
>  ppp authentication chap
>  ppp multilink
>  hold-queue 75 in
>!
>router ospf 64
>  summary-address 152.12.0.0 255.252.0.0
>  summary-address 152.1.1.0 255.255.255.0
>  summary-address 152.1.2.0 255.255.255.0
>  redistribute igrp 64 metric 1000
>  network 152.1.2.128 0.0.0.127 area 1
>  network 152.1.1.76 0.0.0.3 area 2
>  network 152.1.11.0 0.0.0.255 area 2
>  default-information originate always
>  distribute-list 1 in Serial0/0
>  area 0 authentication message-digest
>  area 1 authentication
>  area 1 virtual-link 152.1.2.5 message-digest-key 1 md5 cisco0
>  area 2 nssa
>!
>router igrp 64
>  redistribute ospf 64 route-map summary
>  passive-interface Ethernet0/0
>  passive-interface Serial0/0
>  passive-interface BRI1/0
>  passive-interface Loopback0
>  network 152.1.0.0
>  default-metric 1500 10 255 255 1500
>  distribute-list 3 in Ethernet1/0
>!
>no ip classless
>access-list 1 deny   152.1.1.72
>access-list 1 deny   152.1.1.65
>access-list 1 deny   152.1.1.69
>access-list 1 deny   152.1.1.96 0.0.0.31
>access-list 1 permit any
>access-list 2 permit any
>access-list 3 deny   152.16.0.0
>access-list 3 deny   152.10.0.0
>access-list 3 deny   152.11.0.0
>access-list 3 permit any
>access-list 6 permit 152.1.1.0
>access-list 6 permit 152.1.2.0
>route-map summary permit 10
>  match ip address 6
>!
>!
>dialer-list 1 protocol ip list 2
>!
>line con 0
>line aux 0
>line vty 0 4
>  login
>!
>end
>
>
>
>-----Original Message-----
>From: louie kouncar [mailto:lkouncar@xxxxxx]
>Sent: Wednesday, May 09, 2001 7:20 PM
>To: 'Ron Carithers'; 'Rob Hopkins'
>Cc: ccielab@xxxxxxxxxxxxxx
>Subject: RE: summary-address in ospf and redistribution
>
>
>Ron,
>
>I have used this many many times and it works just fine, Why don't you post
>your configs so we can take a look?
>
>Thanks
>
>
>Louie J. Kouncar
>TCO3 Senior Data Center Engineer
>UUNET
>W-703-343-6645
>C-703-304-2460
>
>
>
>-----Original Message-----
>From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx]On Behalf Of
>Ron Carithers
>Sent: Wednesday, May 09, 2001 9:50 PM
>To: 'Rob Hopkins'
>Cc: ccielab@xxxxxxxxxxxxxx
>Subject: RE: summary-address in ospf and redistribution
>
>
>OK, everyone says to use a summary address to redistribute a route with the
>correct mask into IGRP. I have never seen this work. I am using "CCIE Lab
>Practice Kit" and there is an example of this in one of their labs. Using
>their exact configuration IT DOES NOT WORK. Cisco's documentation says "
For
>OSPF, this command summarizes only routes from other routing protocols that
>are being redistributed into OSPF". What am I missing? Has this changed in
>different IOS versions?
>
>-----Original Message-----
>From: Rob Hopkins [mailto:rshopkins@xxxxxxxxxxxxx]
>Sent: Wednesday, May 09, 2001 5:11 PM
>Cc: ccielab@xxxxxxxxxxxxxx
>Subject: Re: summary-address in ospf and redistribution
>
>
>ever notice how the route to NULL stays even after you remove the
>summary-address?
>I got a little careless, and created a summary more specific than my
>ethernet address subnet,
>so I couldnt even ping anything on  local ethernet segment, ran a debug
icmp
>packets,
>
>IP: s=137.20.64.5 (local), d=137.20.64.6 (Null0), len 100, sending.
>IP: s=137.20.64.5 (local), d=137.20.64.6 (Null0), len 100, sending.
>IP: s=137.20.64.5 (local), d=137.20.64.6 (Null0), len 100, sending.
>IP: s=137.20.64.5 (local), d=137.20.64.6 (Null0), len 100, sending.
>IP: s=137.20.64.5 (local), d=137.20.64.6 (Null0), len 100, sending.
>Success rate is 0 percent (0/5)
>
>I cleared ip ro to no avail, rebooted the router and the null route went
>away,
>coolest thing is it never shows up in the config..  Have some fun with your
>study parteners next
>time they ask you to break their network...
>
>Thanks,
>
>Rob Hopkins
>
>
>
>
>
>
>
>1.6180339887499
>----- Original Message -----
>From: "Greg Ferro" <gferro@xxxxxxxxxxxxxxxxxxx>
>To: "Connary, Julie Ann" <jconnary@xxxxxxxxx>
>Cc: <ccielab@xxxxxxxxxxxxxx>
>Sent: Thursday, January 25, 2001 10:04 PM
>Subject: Re: summary-address in ospf and redistribution
>
>
> > I have been using the ospf summary-address x.x.x.x y.y.y.y not-advertise
>or
> > area x range not-advertise which seem to work well. (Although I did not
> > expect them to, I will spend more time on this later).
> >
> > This result is that the summary does not get advertised through the OSPF
>AS
> > but is used in the redistribution to IGRP. I think that this is a 12.0
> > command. This would be used when the OSPF masks are longer than IGRP
> >
> >
> > At 10:02 AM 24/01/2001 -0500, you wrote:
> > >Nigel,
> > >
> > >I  struggled with this too. Here are my secret tools for trying to
figure
> > >it out:
> > >
> > >1. debug ip igrp events, debug ip igrp transactions. Then do a clear ip
> > >ospf redistribution and a clear ip route * and watch what
> > >IGRP is sending in it's packets to neighbors.
> > >
> > >2. show ip ospf database and look at the external lsa's. This will tell
>you
> > >when you redistribute igrp into ospf if you are
> > >getting any unwanted routes.
> > >
> > >3. If on the same router - then I have found that IGRP will
automatically
> > >announce any connected interfaces of the
> > >same subnet length and same major network. Your's however are of
>different
> > >networks - so summarization or something is needed.
> > >
> > >If the routes are in the same major network these techniques work:
> > >
> > >4. If the OSPF longer subnet masks are on ABR's that are not the
> > >redistribution router - use area x range command.
> > >5. If the OSPF longer subnet mask are on the ASBR - i.e. the
>redistributing
> > >router, then you have three choices:
> > >                  use a summary-address to the igrp subnet mask length
>and
> > >then filter it from going back into OSPF as an E2 route
> > >                  use a ip route xxxx xxxx to null 0 (with a subnet
mask
> > >equal to that of your IGRP subnet mask) and redistribute static
> > >                  use a default-route to another non-related network.
> > >
> > >But in your case - two different major networks -
> > >
> > >          I would think a summary-address to the classfull boundary.
> > >          Or a default-route to this network  at the classfull boundary
-
>as
> > >it is a different major network.
> > >          Or a static-route to the classfull boundary to null 0 and
then
> > >redistribute static.
> > >
> > >What was the summary-address that you used? Did you then do a
>redistribute
> > >ospf 1 metric x x x x  under
> > >your igrp process?
> > >
> > >Julie Ann
> > >
> > >
> > >At 07:14 PM 1/23/2001 -0500, you wrote:
> > > >Julie Ann,
> > > >                 I was working a lab like this over the past weekend
>and let
> > > >me say I've still not solved how to get the OSPF domain routed into
the
>IGRP
> > > >domain.  In my case the interface to the IGRP domain was given as
> > > >171.68.62.93/26 and all the OSPF connected interfaces were assigned
>address
> > > >on the 172.17.59.x subnet making use of address with /28 /29 /30
>subnets.
> > > >The lab specified only the use of the 172.17.59.x.  I tried the
> > > >summary-address and got nothing to work...
> > > >
> > > >I'm still looking for answers.....
> > > >
> > > >Nigel..
> > > >
> > > >----- Original Message -----
> > > >From: Connary, Julie Ann <jconnary@xxxxxxxxx>
> > > >To: <ccielab@xxxxxxxxxxxxxx>
> > > >Sent: Tuesday, January 23, 2001 9:37 AM
> > > >Subject: summary-address in ospf and redistribution
> > > >
> > > >
> > > > > Hi All,
> > > > >
> > > > > I ran across a practice lab and another fat-kid lab that use the
>ospf
> > > > > summary-address to overcome
> > > > > vlsm to fsm issues when redistributing ospf into igrp:
> > > > >
> > > > >
> > > > >
> > > > > situation: The ospf connected interface has a longer mask than the
>IGRP
> > > > > connected interface.
> > > > > area-range does not work because it is on the same router.
> > > > >
> > > > >   The Fatkid lab - expert redistribution - solves this with a
> > > >summary-address.
> > > > >
> > > > > Question - does this not inject E2 routes back into your OSPF
>domain?
> > > > >
> > > > >
> > > > > OSPF area 2
> > > > > 170.10.128.4 - 255.255.255.192
> > > > > |
> > > > > |
> > > > > |
> > > > > R4 -----------IGRP - 170.10.2.4 255.255.255.0
> > > > >
> > > > > To redistribute the ospf interface into IGRP a summary-address is
> > > > > used:  summary-address 170.10.128.0 255.255.255.0
> > > > >
> > > > > But then in the ospf domain you get an E2 route to 170.10.128.0
in
>your
> > > > > ospf domain.
> > > > >
> > > > > So how do you prevent this E2 route into OSPF - can you filter it?
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > remember - no static, no default.
> > > > >
> > > > > Julie Ann
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > ------------------------------------------------------------------------
> > > > >                                          Julie Ann Connary
> > > > >            |           |                  Network Consulting
>Engineer
> > > > >           |||         |||                  Federal Support Program
> > > > >         .|||||.     .|||||.                 13635 Dulles
Technology
> > > Drive,
> > > > > Herndon VA 20171
> > > > >       .:|||||||||:.:|||||||||:.           Pager: 1-888-642-0551
> > > > >      c i s c o S y s t e m s     Email: jconnary@xxxxxxxxx
> > > > >
> > > >
> > ------------------------------------------------------------------------
> >
>------------------------------------------------------------------------
> > >                                          Julie Ann Connary
> > >            |           |                  Network Consulting Engineer
> > >           |||         |||                  Federal Support Program
> > >         .|||||.     .|||||.                 13635 Dulles Technology
>Drive,
> > >Herndon VA 20171
> > >       .:|||||||||:.:|||||||||:.                Pager: 1-888-642-0551
> > >      c i s c o S y s t e m s     Email: jconnary@xxxxxxxxx
> > >
> >
>------------------------------------------------------------------------
>**Please read:http://www.groupstudy.com/list/posting.html
>**Please read:http://www.groupstudy.com/list/posting.html
>**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
_______________________________________________________
To unsubscribe from the CCIELAB list, send a message to
majordomo@xxxxxxxxxxxxxx with the body containing:
unsubscribe ccielab