Hi all When we get newip, we should let the upstream know to expor it as there should have rule in their side. how about upstream provider, does they need to let their all bgp interconnect to know those our newip? If no, Can I know how it works? If they don't have rules each other, ls it any problems? Thank you so much
On Tue, Jan 10, 2012 at 2:43 PM, Deric Kwok <deric.kwok2000@gmail.com>wrote:
Hi all
When we get newip, we should let the upstream know to expor it as there should have rule in their side.
how about upstream provider, does they need to let their all bgp interconnect to know those our newip?
If no, Can I know how it works?
If they don't have rules each other, ls it any problems?
It depends on your upstream ISPs. Conventionally, some choose to place exact filters in place on BGP announcements that exactly match IP space that is registered with a RIR or LIR, some build those filters from IRR sources, and others just filter on the number of prefixes your sending (to avoid sending a whole table out on accident). I'm sure there are some other filtering schemes in place around the world. In the case of exact filters, you'll need to contact your upstream ISPs and ask them to update their filters. In the case of IRR-sourced filtering information, update the prefixes that you originate with your IRR provider. And in the case of max-prefix filtering, ask your ISP what they have their equipment set to. Cheers, jof
On Tue, 10 Jan 2012, Deric Kwok wrote:
When we get newip, we should let the upstream know to expor it as there should have rule in their side.
Correct. Ideally, two things happen: 1. You tell your upstreams and peers about the new space, and they update whatever prefix filters they have in place for your network. 2. You update you own outbound BGP filters wherever necessary so that you can announce the new prefix, aggregated to the extent possible, when you're ready.
how about upstream provider, does they need to let their all bgp interconnect to know those our newip?
They might. It depends on the relationship your upstreams have with their neighbors. Different providers have different criteria for what they'll accept and how they manage their filters. If your upstreams need to have their upstreams and/or peers update their BGP filters, it is their responsibility to notify them. Note that this can add to the amount of time it will take before your direct upstreams are ready to accept and propagate your new prefix. Some providers might require that your new prefix be registered in one of several routing registries, and they'll update their filters based on your new registry data. jms
Hi Justin Thank you Could you tell me more about "routing registries"? I would like to learn it 2nd questions? Are you familiar to quagga? ls it supporting equally multipath in different bgp connections? Thank you so much On Tue, Jan 10, 2012 at 7:58 PM, Justin M. Streiner <streiner@cluebyfour.org> wrote:
On Tue, 10 Jan 2012, Deric Kwok wrote:
When we get newip, we should let the upstream know to expor it as there should have rule in their side.
Correct. Ideally, two things happen: 1. You tell your upstreams and peers about the new space, and they update whatever prefix filters they have in place for your network. 2. You update you own outbound BGP filters wherever necessary so that you can announce the new prefix, aggregated to the extent possible, when you're ready.
how about upstream provider, does they need to let their all bgp interconnect to know those our newip?
They might. It depends on the relationship your upstreams have with their neighbors. Different providers have different criteria for what they'll accept and how they manage their filters.
If your upstreams need to have their upstreams and/or peers update their BGP filters, it is their responsibility to notify them. Note that this can add to the amount of time it will take before your direct upstreams are ready to accept and propagate your new prefix.
Some providers might require that your new prefix be registered in one of several routing registries, and they'll update their filters based on your new registry data.
jms
On Jan 18, 2012, at 5:58 AM, Deric Kwok wrote:
Could you tell me more about "routing registries"? I would like to learn it
google it, and RADB for example.
2nd questions? Are you familiar to quagga? ls it supporting equally multipath in different bgp connections?
Yes, absolutely. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
On Wed, 18 Jan 2012, Deric Kwok wrote:
Could you tell me more about "routing registries"? I would like to learn it
In a nutshell, Internet Routing Registries (IRRs) are places where networks can store information that describes their routing policies. Other networks can query this information and use the results to build or update their filtering policies. You can find an extensive list of registries and more background information at http://www.irr.net/
2nd questions? Are you familiar to quagga? ls it supporting equally multipath in different bgp connections?
I haven't messed around too much with quagga, so I can't give you a good answer on that at the moment. jms
On Wed, Jan 18, 2012 at 5:58 AM, Deric Kwok <deric.kwok2000@gmail.com> wrote:
ls it supporting equally multipath in different bgp connections?
Most software routing protocols have support for this in their RIBs, but the actual forwarding ability of the underlying kernel will determine the support for this. What platform do you route on? Cheers, jof
Hi Thank you all of you Can I have one question? We are planning to have 3 x 1G bgp connections (full tables) eg: Path A, B, C Can I say that we have 3G output totally?
From my understanding, the bgp chooses the best path to route automatically
If the path A is best route and that path 1G bandwidth is used up, will bgp try to use path B and path C automatically? or the bgp still choose to path A whatever the bandwidth is used up How can I use up those 3G? Thank you so much PS: my platform is linu On Wed, Jan 18, 2012 at 7:24 PM, Jonathan Lassoff <jof@thejof.com> wrote:
On Wed, Jan 18, 2012 at 5:58 AM, Deric Kwok <deric.kwok2000@gmail.com> wrote:
ls it supporting equally multipath in different bgp connections?
Most software routing protocols have support for this in their RIBs, but the actual forwarding ability of the underlying kernel will determine the support for this. What platform do you route on?
Cheers, jof
On Thu, Jan 19, 2012 at 6:27 AM, Deric Kwok <deric.kwok2000@gmail.com> wrote:
We are planning to have 3 x 1G bgp connections (full tables) eg: Path A, B, C
Can I say that we have 3G output totally?
Sure.
From my understanding, the bgp chooses the best path to route automatically
It doesn't. It typically chooses the path with the least number of autonomous systems for a given destination. That can actually result in longer physical paths in many cases. Let's say provider C buys bandwidth from A and B (and nobody else). If that's the case, you will only use C for things directly connected to C's network (typically only things that pay C), but every other internet destination would use A or B. (unless you adjust things to not do this).
If the path A is best route and that path 1G bandwidth is used up, will bgp try to use path B and path C automatically?
No, with one caveat. If you fill up the pipe enough that routing messages don't get through, those routes will eventually time out and the path won't be used at all.
How can I use up those 3G?
You will need to manually adjust routes, preferences, etc. You'll still have one path that is hotter than the others (although hopefully not too much hotter). Are you worried about incoming or outgoing bandwidth, or both? For incoming, you will need to do things like: 1) Announce all of your prefixes aggregated out all 3 links 2) Announce parts of your prefixes out ONLY ONE link. So announce /24 #1 out A, /24 #2 out B, /24 #3 out C. This means you're forcing incoming traffic to generally come in one link per /24. The problem with this is that a really active /24 will get more traffic still. It also requires you to have at least 3 /24s (you can't route longer prefixes, which means you can't route PART of a /24). For outbound, the easy and obvious way would be for your providers to just announce 0/0 to you and for you to do some sort of flow-based load balancing. But if one provider had reachability problems, you'd go down. So without that, you'll have to adjust the preferences of incoming routes. Alternatively use BGP multipath and buy from one provider (and connect to the same router on the provider side). Bandwidth from one provider isn't necessarily a horrible thing, if you pick a good one provider. Even with multiple BGP feeds, unless you are really, really careful (and, most likely, spend tons of money for things like fiber redundancy so the different fibers don't all end up on one pole or going into the same telco building) you'll still have single points of failure.
participants (5)
-
Deric Kwok -
Jo Rhett -
Joel Maslak -
Jonathan Lassoff -
Justin M. Streiner