From: Nigel Roy (nigel@xxxxxxxxxxxxxxxxx)
Date: Fri Nov 16 2001 - 05:38:09 GMT-3
Wayne,
I imagine that the summary address has in this case overidden the normal
redistribution process. The rules below are assuming there is no filtering
or aggregation and are based on what I have experienced whilst studying the
actual results of redistribution.
regards
Nigel
----- Original Message -----
From: "Wayne Lewis" <lewisway@hcc.hawaii.edu>
To: "Nigel Roy" <nigel@system-link.co.uk>
Sent: Thursday, November 15, 2001 11:11 PM
Subject: RE: OSPF redistribution into BGP, no external routes shown.
>
> Nigel,
>
> Recently I was doing a lab where I redistributed a connected route into
> OSPF on a router. Since I wanted that to be redistributed into IGRP as
well
> (from the same router), and the mask was not right for IGRP, I used the
> summary-address command in OSPF, which caused the route with the
compatible
> mask to appear in the routing table. My OSPF to IGRP redistribution then
> succeeded in redistributing this route into IGRP. This appears to
> contradict the rules below, doen't it?
>
> Thanks,
>
> Wayne
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Nigel Roy
> Sent: Thursday, November 15, 2001 12:35 PM
> To: ccielab@groupstudy.com
> Cc: Albert Lu
> Subject: Re: OSPF redistribution into BGP, no external routes shown.
>
>
> Albert,
>
> The problem is not that the route has come from an external source, as you
> say it is quite acceptable for "external" routes to be redistributed.
> However the problem here is that the route has not been learned by OSPF
nor
> is it in a network statement. Although OSPF will advertise it out as an
> external LSA it cannot be redistributed from OSPF to BGP on the same
router
> as which it was redistributed from another source (connected). As I said
> earlier this is because when you redistribute routes from one protocol to
> another there are strict rules as to what will be taken:
> 1) a)The route must have been learned by this router by the source
protocol
> (OSPF in your case)
> or b)The route must be in a network statement under the source process.
> 2) The route must be in the IP routing table from that process.
>
> I hope this clarifies it!
>
> regards
>
> Nigel (CCIE #1405)
>
>
>
>
> ----- Original Message -----
> From: "Albert Lu" <albert_ccie@yahoo.com>
> To: "'Nigel Roy'" <nigel@system-link.co.uk>
> Cc: <ccielab@groupstudy.com>
> Sent: Thursday, November 15, 2001 9:05 PM
> Subject: RE: OSPF redistribution into BGP, no external routes shown.
>
>
> > Nigel,
> >
> > That is correct, I'm trying to redistribute the connected loopback of
> > 150.50.4.0 into OSPF and redistribute it into BGP.
> >
> > I'm sure that it must be ok for OSPF to redistribute it's external
routes
> > into BGP. In the real world, an AS would probably consist of more than 1
> > routing protocol (eg. OSPF + EIGRP). If OSPF has the job of
redistributing
> > into BGP, then no EIGRP routes would be redistributed.
> >
> > That doesn't quite make sense for me, but please correct me.
> >
> > Thanks
> >
> > Albert
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> > Nigel Roy
> > Sent: Friday, November 16, 2001 1:29 AM
> > To: ccielab@groupstudy.com
> > Subject: Fw: OSPF redistribution into BGP, no external routes shown.
> >
> >
> > Albert,
> >
> > From what I can gather you are trying to do the following:
> >
> > redistribute connected into OSPF and then from OSPF into BGP.
> >
> > Unfortunately the only routes that will get redistributed from OSPF
into
> > BGP
> > are routes that have been learned by OSPF or have a network statement
> under
> > the OSPF. They must also be the best route as per the IP routing
table.
> > You cannot get routes from one protocol to be redistributed into
another
> > and
> > then forwarded onto a third protocol. This prevents the possibility of
> > mutual redistribution causing routes be fed back into their originating
> > protocol.
> >
> > regards
> >
> > Nigel
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Albert Lu" <albert_ccie@yahoo.com>
> > To: <ccielab@groupstudy.com>
> > Sent: Thursday, November 15, 2001 12:18 PM
> > Subject: OSPF redistribution into BGP, no external routes shown.
> >
> >
> > > Hello all,
> > >
> > > Does anyone know any reason why OSPF external routes would not
> > redistribute
> > > into BGP?
> > >
> > > Here's a section of the config, and the show ip ospf database. The
ospf
> > > > database shows that the connected route has been redistributed into
> OSPF
> > > as
> > > > External, but it seems like BGP won't accept this route when
> > redistributed
> > > > from OSPF.
> > > >
> > > > Thanks
> > > >
> > > > Albert
> > > >
> > > > interface Loopback0
> > > > ip address 200.0.0.8 255.255.255.255
> > > > !
> > > > interface Loopback1
> > > > ip address 150.50.3.8 255.255.255.0
> > > > ip ospf network point-to-point
> > > > !
> > > > interface Loopback2
> > > > ip address 150.50.4.8 255.255.255.0
> > > > ip ospf network
> > > >
> > > > router ospf 8
> > > > log-adjacency-changes
> > > > redistribute connected metric-type 1 subnets route-map
> RM_150_50_4_Only
> > > > passive-interface Loopback1
> > > > network 150.50.3.0 0.0.0.255 area 0
> > > > network 150.50.5.64 0.0.0.63 area 0
> > > > !
> > > > router bgp 65078
> > > > bgp log-neighbor-changes
> > > > bgp confederation identifier 200
> > > > redistribute ospf 8 match internal external 1 external 2 route-map
> > O_IN_B
> > > > neighbor 150.50.5.68 remote-as 65078
> > > > no auto-summary
> > > > !
> > > > !
> > > > access-list 10 permit 150.50.4.0
> > > > access-list 10 permit 150.50.3.0
> > > >
> > > > route-map RM_150_50_4_Only permit 10
> > > > match interface Loopback2
> > > > !
> > > > route-map O_IN_B permit 10
> > > > match ip address 10
> > > > !
> > > >
> > > >
> > > > OSPF Router with ID (200.0.0.8) (Process ID 8)
> > > >
> > > >
> > > > Router Link States (Area 0)
> > > >
> > > > Link ID ADV Router Age Seq# Checksum Link
> > count
> > > > 200.0.0.7 200.0.0.7 243 0x80000019 0xF97C 2
> > > > 200.0.0.8 200.0.0.8 242 0x80000019 0x7B1C 3
> > > >
> > > > Type-5 AS External Link States
> > > >
> > > > Link ID ADV Router Age Seq# Checksum Tag
> > > > 150.50.4.0 200.0.0.8 247 0x80000001 0xF88A 0
> > > >
> > > >
This archive was generated by hypermail 2.1.4 : Fri Jun 21 2002 - 06:45:16 GMT-3