I have 5 providers and we get the default from all of them and full routing tables.
I have seen cases where if there is no default route, the traffic didn't know where to go, even with full routes from all my providers.
-Mike
We put some efforts into our default origination service a few years back to prevent default from being announced if the pop became isolated for some catastrophic reason. I recall once when someone upgraded the route processor of two different routers in a pop at the same time resulting in isolation until the configs were placed on the new RE for other devices in the site. Things happen and preparing for them is the first step to survive.
- Jared
It seems in such a case, the traffic still doesn’t know where to go, but you don’t realize it because you have a default.
Then you pass the traffic to one of the providers who doesn’t have a route for it and they drop it instead of you.
If you see something different, then, by definition, said provider is not feeding you a full set of their tables, or, they, too, are depending on a default and are not receiving a full set of tables.
Owen
We don't accept a default from anyone, but will send one to a customer when
specifically requested.
We heavily filter all incoming routes (bogon, 1918, and many others). We
don't want data resorting to 0/0 and ::/0 when we specifically rejected the
matching route at the import policy.
Additionally, if your upstream isn't announcing a route to you, where are
they going to send your traffic anyway?
Regards,
Chris Rogers
+1.302.357.3696 x2110
http://inerail.net/
There is one setup where you would need default route from your provider.
If you have no IBGP between two sites and your prefix is a large /16 on side and maybe a /18 from that /16 on another site. These site would not be able to talk to each other if you orginate from the same AS.
Other than that I see not harm in having both default and a full table since longest prefix match will always win even if you have 2 or more transits.
// Andreas
Med vänlig hälsning
Andreas Larsen
IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Besöksadress: S:t Persgatan 6, Uppsala |
Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56
www.ip-only.se<https://webmail.ip-only.net/owa/UrlBlockedError.aspx>
5 nov 2014 kl. 02:41 skrev Chris Rogers <crogers@inerail.net<mailto:crogers@inerail.net>>:
We don't accept a default from anyone, but will send one to a customer when
specifically requested.
We heavily filter all incoming routes (bogon, 1918, and many others). We
don't want data resorting to 0/0 and ::/0 when we specifically rejected the
matching route at the import policy.
Additionally, if your upstream isn't announcing a route to you, where are
they going to send your traffic anyway?
Regards,
Chris Rogers
+1.302.357.3696 x2110
http://inerail.net/
There is one setup where you would need default route from your provider.
If you have no IBGP between two sites and your prefix is a large /16 on side and maybe a /18 from that /16 on another site. These site would not be able to talk to each other if you orginate from the same AS.
Other than that I see not harm in having both default and a full table since longest prefix match will always win even if you have 2 or more transits.
I think in that case you would use “allowas-in”.
Regards,
Marc
We receive full routes and a default so we can perform traffic engineering within our network. We have links to multiple carriers, via multiple routers. We inject a default route into OSPF from distinct segments of our network, based on receiving the default route on that segment via eBGP. If the default route goes down, the default injected from another segment assumes priority and traffic routes out through that segment's carrier. It's easier to manage this kind of failover (for us) using default routes, so we don't have to carry full routes on all our core routers. We also prefer using a default route over engineering things based on some other arbitrary route learned from eBGP.
Thanks,
Adam
There is one setup where you would need default route from your provider.
That may be true, but this isn’t it…
If you have no IBGP between two sites and your prefix is a large /16 on side and maybe a /18 from that /16 on another site. These site would not be able to talk to each other if you orginate from the same AS.
1. Don’t do this. No, really, this is like the old joke about “Doctor, Doctor, it hurts when I do this!”. Just get a second AS.
Supposed definition of an AS: “A collection of prefixes with a common routing policy”.
If you have a /18 advertised from group A and a /17 and a /18 advertised from group B (even if you’re pretending it’s a /16
and including the covered separate /18), then you have 3 (or pretending 2) prefixes which have different routing
policies.
2. If you are going to do this, then you’re better off building a tunnel between the sites and setting up iBGP across the tunnel.
3. Another option is to coerce your BGP into accepting routes with your own AS in the AS PATH. This circumvents BGP loop
detection, but if you’re two sites are stub sites (and I can’t imagine a scenario where you would do this with transit sites),
then that is a pretty low risk. Further, you can filter out the potential loop routes pretty easily since you know which ones
are local to each site, making that particular loop detection irrelevant).
Other than that I see not harm in having both default and a full table since longest prefix match will always win even if you have 2 or more transits.
The harm is that instead of dropping traffic that can’t go anywhere, you’re passing it to someone else to drop for you. I suppose as long as you’re paying for the bandwidth used, it’s not a big deal, but it also breaks your ability to implement things like BCP38.
Owen