Router only speaks IGP in BGP network

Tarig Ahmed tariq198487 at
Tue Jan 4 00:00:27 CST 2011

On Jan 3, 2011, at 8:02 PM, Jeff Aitken <jaitken at> wrote:

> On Sat, Dec 25, 2010 at 08:52:42AM -0500, ML wrote:
>> If you're only redistributing 10 prefixes into OSPF? Problem?
> I know I'm a little late to this thread, but figured I'd point out one
> reason why this can be very dangerous:
> In IOS, you use a route-map to control redistribution between  
> protocols.
> For example, if you want to redist just those BGP prefixes tagged  
> with a
> specific community into OSPF, you will probably configure something  
> that
> looks like this:
>    route-map bgp-to-ospf permit 10
>     match community $COMMUNITY
>    !
>    route-map bgp-to-ospf deny 20
>    !
>    router ospf $PID
>     redistribute bgp $ASN subnets route-map bgp-to-ospf
> Now, consider the following failure scenarios:
> 1. Someone typo's a BGP config elsewhere in your network and attaches
> $COMMUNITY to a whole bunch more routes... say, all 350k being sent  
> by your
> upstream provider.  *oops*
> 2. An engineer thinks that there's something wrong with the  
> redistribution
> and decides to temporarily disable it as part of the troubleshooting
> process.  He types the following:
>    conf t
>    router ospf $PID
>    no redistribute bgp $ASN subnets route-map bgp-to-ospf
> *boom*
> He just dumped all BGP routes into OSPF, due to the way IOS parses the
> command: it removes the route-map but leaves the redistribution  
> intact.
> To be fair, Cisco does provide you with tools to mitigate this risk  
> (see
> the "redistribute maximum-prefix" command) but the point is that  
> this is
> a fairly easy mistake to make.
> At the end of the day, the reason that many folks advise against the
> redistribution of BGP into an IGP is that it sets the stage for a  
> seemingly
> insignificant mistake to cause a not-so-insignificant outage.
> --Jeff

This is an interesting point.
But why cisco *no* command does not remove the redistribute , I think  
it should do.


More information about the NANOG mailing list