Re: google ipv6 routes via cogent
That will have the effect of prioritizing Cogent routes as that would be more specific than the default routes from the other providers. Cogent are not that good that you would want to do that. Den 2. mar. 2017 20.16 skrev "Jeff Waddell" <jeff+nanog@waddellsolutions.com
:
Or at least ask for a full view from Cogent - then you won't get any routes they don't have On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay <alarig@swordarmor.fr> wrote:
On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote:
Well, I asked my (3) upstream providers to only send me a ipv6 default route and they sent me ::/0...here's one of them...
Why did you don’t ask for a full view? With that, you can easily deal with that kind of problem.
-- alarig
Ah - you are correct So - yeah what Alarig said - get full routes from all On Thu, Mar 2, 2017 at 2:30 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
That will have the effect of prioritizing Cogent routes as that would be more specific than the default routes from the other providers. Cogent are not that good that you would want to do that.
Den 2. mar. 2017 20.16 skrev "Jeff Waddell" <jeff+nanog@waddellsolutions. com
:
Or at least ask for a full view from Cogent - then you won't get any routes they don't have
On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay <alarig@swordarmor.fr> wrote:
On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote:
Well, I asked my (3) upstream providers to only send me a ipv6 default route and they sent me ::/0...here's one of them...
Why did you don’t ask for a full view? With that, you can easily deal with that kind of problem.
-- alarig
Yes, thanks, I am going to do that. But, is there a middle ground between being default only and full routes ? Like is it advantageous for me to ask for partial routes (like their routes and direct peers and default route) ? This way I don't have millions of routes but I guess only a few hundred thousand or less? Let me know please. -Aaron
* aaron1@gvtc.com (Aaron Gould) [Thu 02 Mar 2017, 20:52 CET]:
Yes, thanks, I am going to do that. But, is there a middle ground between being default only and full routes ? Like is it advantageous for me to ask for partial routes (like their routes and direct peers and default route) ? This way I don't have millions of routes but I guess only a few hundred thousand or less? Let me know please.
You should ask for full routes from all your providers + a default. Then you write per-upstream import policies to permit or deny specific subsets of the prefixes they announce to you. For example, you could accept all prefixes from Cogent and your other upstreams tagged with a BGP community indicating they're from customers, and accept default from all except Cogent to take care of the rest of the traffic while still pretty much sending traffic to downstream customers to their respective upstream. (Or you can accept default from all but also import networks with whom Cogent has no direct relationship from your other upstreams; but that's less failsafe.) Depending on what router hardware you have and what upstreams, you may have to filter out additional prefixes to not overflow its FIB. -- Niels.
On 3/2/2017 2:57 PM, Niels Bakker wrote:
You should ask for full routes from all your providers + a default.
-- Niels.
If you taking full routes from everyone, why would you need a default? If they don't show a route for it, they probably can't reach it. I don't think I have run with a default route external for many years, and so far it hasn't bit me yet.. --- Howard Leadmon PBW Communications, LLC http://www.pbwcomm.com
* howard@leadmon.net (Howard Leadmon) [Fri 03 Mar 2017, 01:06 CET]:
On 3/2/2017 2:57 PM, Niels Bakker wrote:
You should ask for full routes from all your providers + a default.
If you taking full routes from everyone, why would you need a default? If they don't show a route for it, they probably can't reach it. I don't think I have run with a default route external for many years, and so far it hasn't bit me yet..
As I explained in the rest of my email that you conveniently didn't quote, it's so that you can selectively import routes from all your providers in situations where your router cannot handle a full table. -- Niels.
Niels Bakker wrote:
As I explained in the rest of my email that you conveniently didn't quote, it's so that you can selectively import routes from all your providers in situations where your router cannot handle a full table.
it can also break horribly in situations where the provider is providing "transit" but doesn't provide full transit. OTOH, if you are single-homed, it is highly advisable to accept a default, the reason being that most transit providers provide bgp communities with "don't advertise to customers" semantics. So if you're single-homed and use a full dfz feed without default route, you will not have full connectivity to all the routes available from the transit provider. Nick
* nick@foobar.org (Nick Hilliard) [Fri 03 Mar 2017, 13:02 CET]:
Niels Bakker wrote:
As I explained in the rest of my email that you conveniently didn't quote, it's so that you can selectively import routes from all your providers in situations where your router cannot handle a full table.
it can also break horribly in situations where the provider is providing "transit" but doesn't provide full transit.
You don't need to import them into your border router's FIB. It's always good to be able to change your own routing policy without having to consult your upstream's NOC. -- Niels.
On Mar 3, 2017, at 7:00 AM, Nick Hilliard <nick@foobar.org> wrote:
Niels Bakker wrote:
As I explained in the rest of my email that you conveniently didn't quote, it's so that you can selectively import routes from all your providers in situations where your router cannot handle a full table.
it can also break horribly in situations where the provider is providing "transit" but doesn't provide full transit.
OTOH, if you are single-homed, it is highly advisable to accept a default, the reason being that most transit providers provide bgp communities with "don't advertise to customers" semantics. So if you're single-homed and use a full dfz feed without default route, you will not have full connectivity to all the routes available from the transit provider.
If you are single-homed, there is no need for BGP at all. And injecting your ASN into the table is probably not terribly useful to everyone else’s FIB. There are, of course, corner cases. But in general, single-homed people shouldn’t be using BGP. -- TTFN, patrick
On Fri, Mar 03, 2017 at 09:42:04AM -0500, Patrick W. Gilmore wrote:
On Mar 3, 2017, at 7:00 AM, Nick Hilliard <nick@foobar.org> wrote:
Niels Bakker wrote:
As I explained in the rest of my email that you conveniently didn't quote, it's so that you can selectively import routes from all your providers in situations where your router cannot handle a full table.
it can also break horribly in situations where the provider is providing "transit" but doesn't provide full transit.
OTOH, if you are single-homed, it is highly advisable to accept a default, the reason being that most transit providers provide bgp communities with "don't advertise to customers" semantics. So if you're single-homed and use a full dfz feed without default route, you will not have full connectivity to all the routes available from the transit provider.
Correct.
If you are single-homed, there is no need for BGP at all.
That is very strongly worded, and in plenty of cases a false assertion.
And injecting your ASN into the table is probably not terribly useful to everyone else’s FIB.
ASNs don't have anything to do with FIB.
There are, of course, corner cases. But in general, single-homed people shouldn’t be using BGP.
There are numerous reasons to use BGP when single-homed: - as preparation to multi-home in the (near) future - ability to quickly change providers - to use BGP based blackholing features - to save time on provisioning work (adding new prefixes becomes a matter of just announcing and updating IRR/RPKI). - loadbalanacing / loadsharing across multiple links - ability to use bgp communities for traffic engineering In other words, if you have your own IP space, I'd recommend to get your own ASN and use BGP. Kind regards, Job
On Fri, Mar 3, 2017 at 5:05 PM, Job Snijders <job@instituut.net> wrote:
There are, of course, corner cases. But in general, single-homed people shouldn’t be using BGP.
There are numerous reasons to use BGP when single-homed:
- as preparation to multi-home in the (near) future - ability to quickly change providers - to use BGP based blackholing features - to save time on provisioning work (adding new prefixes becomes a matter of just announcing and updating IRR/RPKI). - loadbalanacing / loadsharing across multiple links - ability to use bgp communities for traffic engineering
In other words, if you have your own IP space, I'd recommend to get your own ASN and use BGP.
I concur with Job. If you are single-homed but care about having proper L3 redundancy (not just VRRP or equivalent), BGP is a must. ARIN has a policy to allow this, but it is not spelled out with an excess of clarity. I suspect it is not often used; see NRPM section 5. -- Jeremy Austin
On Mar 3, 2017, at 9:05 PM, Job Snijders <job@instituut.net> wrote:
On Fri, Mar 03, 2017 at 09:42:04AM -0500, Patrick W. Gilmore wrote:
On Mar 3, 2017, at 7:00 AM, Nick Hilliard <nick@foobar.org> wrote:
Niels Bakker wrote:
As I explained in the rest of my email that you conveniently didn't quote, it's so that you can selectively import routes from all your providers in situations where your router cannot handle a full table.
it can also break horribly in situations where the provider is providing "transit" but doesn't provide full transit.
OTOH, if you are single-homed, it is highly advisable to accept a default, the reason being that most transit providers provide bgp communities with "don't advertise to customers" semantics. So if you're single-homed and use a full dfz feed without default route, you will not have full connectivity to all the routes available from the transit provider.
Correct.
If you are single-homed, there is no need for BGP at all.
That is very strongly worded, and in plenty of cases a false assertion.
And injecting your ASN into the table is probably not terribly useful to everyone else’s FIB.
ASNs don't have anything to do with FIB.
There are, of course, corner cases. But in general, single-homed people shouldn’t be using BGP.
There are numerous reasons to use BGP when single-homed:
- as preparation to multi-home in the (near) future - ability to quickly change providers - to use BGP based blackholing features - to save time on provisioning work (adding new prefixes becomes a matter of just announcing and updating IRR/RPKI). - loadbalanacing / loadsharing across multiple links - ability to use bgp communities for traffic engineering
In other words, if you have your own IP space, I'd recommend to get your own ASN and use BGP.
First, I said specifically there are corner cases. Everything you say above is a corner case. The sum of everyone in need of the above is to the right of the decimal compared to all single homed networks. Limiting it to “it you have your own IP space” makes the set even smaller. You are also reaching here. Preparation for multi-homing in the near future is just multi-homing. Adding prefixes is a very occasional thing, and in some cases is actually not easier with BGP. (Ever worked with some provider’s IRR implementation?) Etc. End of day, if you have your own space and only allow aggregates into the DFZ, even as a stub behind someone else, it doesn’t really save RIB slots compared to having the upstream announce it for you. My problem is making the exceptions sound normal. They are not, and we should not treat them as if they are. Else we will end up with people wanting to do it who do not understand what they are doing, polluting the table, etc. I stand by my statement. Single Homed Networks Should Not Use BGP. It is a good general rule. There are exceptions, but the exceptions are rare and should be approached with caution & clue. -- TTFN, patrick
Yes. Most providers can send you just their customer routes. If they send you full routes you want to discriminate customer vs peer routes. This is typically done with communities and is worthwhile as most people have capacity on customer links but via peer it may not always be the case. As is usual YMMV Jared Mauch
On Mar 2, 2017, at 2:52 PM, Aaron Gould <aaron1@gvtc.com> wrote:
Yes, thanks, I am going to do that. But, is there a middle ground between being default only and full routes ? Like is it advantageous for me to ask for partial routes (like their routes and direct peers and default route) ? This way I don't have millions of routes but I guess only a few hundred thousand or less? Let me know please.
-Aaron
On 3/2/17 3:42 PM, Jared Mauch wrote:
Yes. Most providers can send you just their customer routes. If they send you full routes you want to discriminate customer vs peer routes. This is typically done with communities and is worthwhile as most people have capacity on customer links but via peer it may not always be the case.
As is usual YMMV It's relatively straight-forward to take a full table feed and accept into your fib only the routes you want from that table.
I presented on variant of that based on my need for partial fib peering switches; but other reasons for doing so exist, e.g. defailt + te-overrides, prefix filters weighted by per prefix utilization and so on. In general I'd get the full table and the default if you intend to take the default but need recourse to over-rides (for example if your fib won't hold full table is an element of the design). if the Rib won't hold three full tables well that's a different sort of problem, and this may be the wrong router platform. joel
Jared Mauch
On Mar 2, 2017, at 2:52 PM, Aaron Gould <aaron1@gvtc.com> wrote:
Yes, thanks, I am going to do that. But, is there a middle ground between being default only and full routes ? Like is it advantageous for me to ask for partial routes (like their routes and direct peers and default route) ? This way I don't have millions of routes but I guess only a few hundred thousand or less? Let me know please.
-Aaron
Define "good" vs. "bad" transport of bits. As long as there is adequate bandwidth and low latency, who cares? On Thu, Mar 02, 2017 at 08:30:37PM +0100, Baldur Norddahl wrote:
That will have the effect of prioritizing Cogent routes as that would be more specific than the default routes from the other providers. Cogent are not that good that you would want to do that.
Den 2. mar. 2017 20.16 skrev "Jeff Waddell" <jeff+nanog@waddellsolutions.com
:
Or at least ask for a full view from Cogent - then you won't get any routes they don't have
On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay <alarig@swordarmor.fr> wrote:
On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote:
Well, I asked my (3) upstream providers to only send me a ipv6 default route and they sent me ::/0...here's one of them...
Why did you don’t ask for a full view? With that, you can easily deal with that kind of problem.
I think the implication is that, on Cogent, there isn't. :) On Thu, Mar 2, 2017 at 14:00 Chuck Anderson <cra@wpi.edu> wrote:
Define "good" vs. "bad" transport of bits. As long as there is adequate bandwidth and low latency, who cares?
On Thu, Mar 02, 2017 at 08:30:37PM +0100, Baldur Norddahl wrote:
That will have the effect of prioritizing Cogent routes as that would be more specific than the default routes from the other providers. Cogent are not that good that you would want to do that.
Den 2. mar. 2017 20.16 skrev "Jeff Waddell" < jeff+nanog@waddellsolutions.com
:
Or at least ask for a full view from Cogent - then you won't get any routes they don't have
On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay <alarig@swordarmor.fr> wrote:
On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote:
Well, I asked my (3) upstream providers to only send me a ipv6 default route and they sent me ::/0...here's one of them...
Why did you don’t ask for a full view? With that, you can easily deal with that kind of problem.
participants (13)
-
Aaron Gould -
Baldur Norddahl -
Chuck Anderson -
Howard Leadmon -
Hunter Fuller -
Jared Mauch -
Jeff Waddell -
Jeremy Austin -
Job Snijders -
joel jaeggli -
Nick Hilliard -
Niels Bakker -
Patrick W. Gilmore