[c-nsp] Drawbacks of Redistributing Default Route from BGP intoIGP(ISIS)

[Dan Armstrong]

You may be missing a layer in your head....

The layer that has BGP Peers obvoiusly runs BGP. 

The bottom layer where customers connect, generally speaking does not 
run BGP, it only runs your IGP, and generally is advertised a default 
route from the "middle" layer(s) The middle layer(s) usually speak both 
BGP and your IGP..

So theoretically, each "access" device will not really need to care 
about more than 2 middle layer devices (2 for redundancy) coupled with 
per destination load balancing with CEF, the default routes are good to go.

In a small network, of course, all those upper layers could be collapsed 
into one.... that's why I say you may be missing it in your head, 
conceptually.

Dan.


Osama I Dosary wrote:

> Thank you Oliver. But is there a good reliable  alternative to 
> redistribution of the default route?
> Is this what most ISPs are doing?
> Or do they just have BGP everywhere?
>
> /Osama
>
> Oliver Boehmer (oboehmer) wrote:
>
>>> We are a service provider, and have two upstream service providers,
>>> connecting to two different border routers (at different locations).
>>> Each upstream SP is sending us a default route back to them. Not all
>>> our routers speak BGP, so we need a way to send them the default
>>> route, where if one upstream fails they get the other dynamically.
>>> We are currently using default-originate in ISIS, but it is not
>>> dynamic. Then we thought of using route-map condition with the
>>> default-originate, but it didn't seem as straight forward as
>>> redistribution.
>>> What are the drawbacks of redistributing the default route into ISIS
>>> on the border routers?
>>> Is there an architecturally better way to do this?
>>>   
>>
>>
>> Redistribution from BGP into an IGP is usually not being done, reasoning
>> is that simple config mistakes can cause a network meltdown if you end
>> up injecting several thousands of prefixes into an IGP.
>> If you do it carefully and secure it with multiple safety nets (i.e. a)
>> filtering and/or limiting the number of prefixes you accept from your
>> eBGP peer, b) use route-maps to only redistribute 0/0 into ISIS, and
>> possibly c) limit the number of redistributed routes via the "IS-IS
>> Limit on Number of Redistributed Routes" feature), it is a valid
>> approach IMHO.
>>
>>     oli
>>  
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/