On Wed, Jan 23, 2013 at 11:33 PM, Saku Ytti <[email protected]> wrote: > On (2013-01-23 23:00 +1100), Andrew Miehs wrote: > > Your provider (INET) should be able to announce a default for you if you > > request it. > > We don't. We advertise to our customers prefix to which they static route. > If our PE is disconnected from core, we don't have that prefix to send to > the customer, so we don't blackhole customer.
So the reason would be to ensure that customers with multiple uplinks but no full BGP feed survive a failure on the provider side where at least one of the PE routers connecting the customer looses connectivity to the rest of the Internet. Thinking about it a little more - I would probably make a static route announcement conditional based on the reachability of something inside the central core of my own network - not some external host.You will probably also have null routes for 10/8, 172.16/12 and 192.168/16 with similar issues. This would cause an issue for those customer should I have a complete "uplink" outage so I would put more effort into ensuring that this complete outage can not happen. As a side note, if you were to use 8.8.8.8 as your "test" you need to ensure that you do not peer directly with this network. > > HOWEVER: If we are talking about service provider networks - what is the > > purpose of your default route? > > As it recurses you can use it to your advantage to gain higher level of > trust of default destinations ability to transport packets. > > Gert suggested that you static route in ASBR to your PEER IP. > > - static route always valid, if PEER is up. Regardless if it ARPs, > regardless if BGP is up. > > If non ASBR has > a) static to 8.8.8.8 (or any trustworthy, important, stable eBGP) > and > b) static to ASBR anycast (worse admin than above) Or get your upstreams to additionally announce a default to you - still not sure I am convinced though... _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
