Single AS multiple Dirverse Providers
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks. Currently we are announcing several /24s out one network and other /24s out the second network, they do not overlap. To the internet this works fine, however, providers a/b at site1 do not send us the two /24s from site b.. We have requested them to, but have not seen them come in, nor do we have any filters that would prohibit them from coming in. Is this normal? Can we receive those routes even though they are from our own AS? What is the "best practice" in this case? Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition <http://www.wlan1.com/product_p/mikrotik%20book-2.htm> " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 <tel:314-735-0270> Website: http://www.linktechs.net <http://www.linktechs.net/> - Skype: linktechs <skype:linktechs?call> -- Create Wireless Coverage's with www.towercoverage.com <http://www.towercoverage.com/> - 900Mhz - LTE - 3G - 3.65 - TV Whitespace
On 2013-06-10, at 18:36, "Dennis Burgess" <dmburgess@linktechs.net> wrote:
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks.
Currently we are announcing several /24s out one network and other /24s out the second network, they do not overlap. To the internet this works fine, however, providers a/b at site1 do not send us the two /24s from site b.. We have requested them to, but have not seen them come in, nor do we have any filters that would prohibit them from coming in.
Is this normal?
Yeah.
Can we receive those routes even though they are from our own AS?
You can stop them from being suppressed inbound by using "neigh x.x.x.x allowas-in" on a cisco, or "set neigh x.x.x.x allowas-in" on JunOS.
What is the "best practice" in this case?
I don't know. Above seems reasonable. I've seen people join their sites with tunnels plumbed to router loopbacks in different sites and run IGPs over them before; this gives them inter-site connectivity which makes the question moot. But it involves tunnels. Joe
On Mon, Jun 10, 2013 at 9:43 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2013-06-10, at 18:36, "Dennis Burgess" <dmburgess@linktechs.net> wrote:
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks.
Currently we are announcing several /24s out one network and other /24s out the second network, they do not overlap. To the internet this works fine, however, providers a/b at site1 do not send us the two /24s from site b.. We have requested them to, but have not seen them come in, nor do we have any filters that would prohibit them from coming in.
Is this normal?
Yeah.
Can we receive those routes even though they are from our own AS?
You can stop them from being suppressed inbound by using "neigh x.x.x.x allowas-in" on a cisco, or "set neigh x.x.x.x allowas-in" on JunOS.
What is the "best practice" in this case?
I don't know. Above seems reasonable. I've seen people join their sites with tunnels plumbed to router loopbacks in different sites and run IGPs over them before; this gives them inter-site connectivity which makes the question moot. But it involves tunnels.
Joe
If your upstream provider runs JunOS, they may not be aware that their gear won't send you the routes by default, no matter what their policy says: "The JUNOS software does not advertise the routes learned from one external BGP (EBGP) peer back to the same EBGP peer. In addition, the software does not advertise those routes back to any EBGP peers that are in the same AS as the originating peer, regardless of the routing instance. You can modify this behavior by including the advertise-peer-as statement in the configuration." (from http://www.juniper.net/techpubs/software/junos/junos95/swconfig-routing/id-1... So, you may need to help walk them through adding the "advertise-peer-as" flag to your neighbor configurations if they use Juniper kit. Matt
On 6/10/13 6:36 PM, Dennis Burgess wrote:
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks.
Currently we are announcing several /24s out one network and other /24s out the second network, they do not overlap. To the internet this works fine, however, providers a/b at site1 do not send us the two /24s from site b.. We have requested them to, but have not seen them come in, nor do we have any filters that would prohibit them from coming in. bgp loop detection ignores these...
You need the equivalent of loops 2 (cisco) in your router config to make this work (and it will work fine)
Is this normal? Can we receive those routes even though they are from our own AS? What is the "best practice" in this case?
Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition <http://www.wlan1.com/product_p/mikrotik%20book-2.htm> "
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270 <tel:314-735-0270> Website: http://www.linktechs.net <http://www.linktechs.net/> - Skype: linktechs <skype:linktechs?call>
-- Create Wireless Coverage's with www.towercoverage.com <http://www.towercoverage.com/> - 900Mhz - LTE - 3G - 3.65 - TV Whitespace
On 6/10/13 6:48 PM, joel jaeggli wrote:
On 6/10/13 6:36 PM, Dennis Burgess wrote:
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks.
Currently we are announcing several /24s out one network and other /24s out the second network, they do not overlap. To the internet this works fine, however, providers a/b at site1 do not send us the two /24s from site b.. We have requested them to, but have not seen them come in, nor do we have any filters that would prohibit them from coming in. bgp loop detection ignores these...
You need the equivalent of loops 2 (cisco) in your router config to make this work (and it will work fine) sorry that's juniper style e.g.
routing-options { autonomous-system 64999 loops 2; }
Is this normal? Can we receive those routes even though they are from our own AS? What is the "best practice" in this case?
Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition <http://www.wlan1.com/product_p/mikrotik%20book-2.htm> "
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270 <tel:314-735-0270> Website: http://www.linktechs.net <http://www.linktechs.net/> - Skype: linktechs <skype:linktechs?call>
-- Create Wireless Coverage's with www.towercoverage.com <http://www.towercoverage.com/> - 900Mhz - LTE - 3G - 3.65 - TV Whitespace
On Mon, Jun 10, 2013 at 11:36:44AM -0500, Dennis Burgess wrote:
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks.
So, you have two islands? Technically, that would be separate ASNs as they are separatre routing policies, but the modern world has adapted.
Currently we are announcing several /24s out one network and other /24s out the second network, they do not overlap. To the internet this works fine, however, providers a/b at site1 do not send us the two /24s from site b.. We have requested them to, but have not seen them come in, nor do we have any filters that would prohibit them from coming in.
Is this normal? Can we receive those routes even though they are from our own AS? What is the "best practice" in this case?
To prevent loops in the global Internet the BGP specification dictates this behavior, and has in all versions. Depending on your platform and theirs, you will all need to turn several knobs before you are allowed to break these rules. I would recommend that you gain more than passing familiarity with why the protocol is built this way, how it affects your use case, and what concerns you might have WRT your providers before you change the behavior for your case. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NANOG
On Jun 10, 2013, at 12:54 , Joe Provo <nanog-post@rsuc.gweep.net> wrote:
On Mon, Jun 10, 2013 at 11:36:44AM -0500, Dennis Burgess wrote:
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks.
So, you have two islands? Technically, that would be separate ASNs as they are separatre routing policies, but the modern world has adapted.
Should we change the rules? I know with 64-bit ASNs mean it is tough to run out of ASNs, but not sure we really want each island to be its own AS going forward. Comments from the peanut gallery? -- TTFN, patrick
Currently we are announcing several /24s out one network and other /24s out the second network, they do not overlap. To the internet this works fine, however, providers a/b at site1 do not send us the two /24s from site b.. We have requested them to, but have not seen them come in, nor do we have any filters that would prohibit them from coming in.
Is this normal? Can we receive those routes even though they are from our own AS? What is the "best practice" in this case?
To prevent loops in the global Internet the BGP specification dictates this behavior, and has in all versions. Depending on your platform and theirs, you will all need to turn several knobs before you are allowed to break these rules. I would recommend that you gain more than passing familiarity with why the protocol is built this way, how it affects your use case, and what concerns you might have WRT your providers before you change the behavior for your case.
Cheers,
Joe
-- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NANOG
On Mon, Jun 10, 2013 at 01:18:04PM -0400, Patrick W. Gilmore wrote:
On Jun 10, 2013, at 12:54 , Joe Provo <nanog-post@rsuc.gweep.net> wrote:
On Mon, Jun 10, 2013 at 11:36:44AM -0500, Dennis Burgess wrote:
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks.
So, you have two islands? Technically, that would be separate ASNs as they are separatre routing policies, but the modern world has adapted.
Should we change the rules? I know with 64-bit ASNs mean it is tough to run out of ASNs, but not sure we really want each island to be its own AS going forward.
Comments from the peanut gallery?
I missed your proposal for loop detection to replace the current behavior in the above text. Was it compressed? I will admit that it is Not Hard for people who know what they're doing to operate well outside default and standard behavior. That's why I merely recommended that the questioner educate themselves as to the whys and wherefore before just turning knobs. I would submit that not knowing loop detection is a default and valuable feature might indicate the person should understand why and how it affects them. I don't have the hubris to believe that I understand his business needs, nor edge conditions/failure modes where a different solution might be needed. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NANOG
On Mon, 10 Jun 2013, Joe Provo wrote:
I would submit that not knowing loop detection is a default and valuable feature might indicate the person should understand why and how it affects them.
And I would further submit that the lack of deep protocol knowledge is a good reason to NOT F**K with it! Why is just getting another ASN not the preferred option here? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross
On Jun 10, 2013, at 14:14 , Joe Provo <nanog-post@rsuc.gweep.net> wrote:
On Mon, Jun 10, 2013 at 01:18:04PM -0400, Patrick W. Gilmore wrote:
On Jun 10, 2013, at 12:54 , Joe Provo <nanog-post@rsuc.gweep.net> wrote:
On Mon, Jun 10, 2013 at 11:36:44AM -0500, Dennis Burgess wrote:
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks.
So, you have two islands? Technically, that would be separate ASNs as they are separatre routing policies, but the modern world has adapted.
Should we change the rules? I know with 64-bit ASNs mean it is tough to run out of ASNs, but not sure we really want each island to be its own AS going forward.
Comments from the peanut gallery?
I missed your proposal for loop detection to replace the current behavior in the above text. Was it compressed?
Was not compressed. Don't want to take out loop detection in general. If you are running an island, it is up to you to ensure that island is specifically configured. This makes it no different than lots of other "weird" things on the 'Net. (I put weird in quotes because weird implies out of the ordinary, but there are probably more weird things than "normal" things these days.)
I will admit that it is Not Hard for people who know what they're doing to operate well outside default and standard behavior. That's why I merely recommended that the questioner educate themselves as to the whys and wherefore before just turning knobs. I would submit that not knowing loop detection is a default and valuable feature might indicate the person should understand why and how it affects them. I don't have the hubris to believe that I understand his business needs, nor edge conditions/failure modes where a different solution might be needed.
All good points. Is it enough to keep the standard? Or should the standard have a specific carve out, e.g. for stub networks only, not allowing islands to provide transit. Just a straw man. Or we can keep it like it is today, non-standard and let people who know what they are doing violate it at their own peril. The problem with the latter is some ISPs point to standards as if there is no other possible way to do things. Which makes it difficult to be someone who knowingly violates a standard. Anyway, just wondering how others felt. -- TTFN, patrick
On Mon, Jun 10, 2013 at 03:22:41PM -0400, Patrick W. Gilmore wrote:
On Jun 10, 2013, at 14:14 , Joe Provo <nanog-post@rsuc.gweep.net> wrote:
On Mon, Jun 10, 2013 at 01:18:04PM -0400, Patrick W. Gilmore wrote:
On Jun 10, 2013, at 12:54 , Joe Provo <nanog-post@rsuc.gweep.net> wrote:
On Mon, Jun 10, 2013 at 11:36:44AM -0500, Dennis Burgess wrote:
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks.
So, you have two islands? Technically, that would be separate ASNs as they are separatre routing policies, but the modern world has adapted.
Should we change the rules? I know with 64-bit ASNs mean it is tough to run out of ASNs, but not sure we really want each island to be its own AS going forward.
Comments from the peanut gallery?
I missed your proposal for loop detection to replace the current behavior in the above text. Was it compressed?
Was not compressed. Don't want to take out loop detection in general. If you are running an island, it is up to you to ensure that island is specifically configured.
So, you like loop detection but you don't like how it is implemtned? Then I ask again for your suggestion for BGPv5.
This makes it no different than lots of other "weird" things on the 'Net. (I put weird in quotes because weird implies out of the ordinary, but there are probably more weird things than "normal" things these days.)
Handwave without data meant to belittle the loop detection concern. "Probably" and "Lots of" are nice rhetorical dodges, but they work better in a conference hall. Let's keep this text to real data.
I will admit that it is Not Hard for people who know what they're doing to operate well outside default and standard behavior. That's why I merely recommended that the questioner educate themselves as to the whys and wherefore before just turning knobs. I would submit that not knowing loop detection is a default and valuable feature might indicate the person should understand why and how it affects them. I don't have the hubris to believe that I understand his business needs, nor edge conditions/failure modes where a different solution might be needed.
All good points.
Is it enough to keep the standard? Or should the standard have a specific carve out, e.g. for stub networks only, not allowing islands to provide transit. Just a straw man.
I'd be leery of attempting to add anything into the protocol spec that doesn't have an alternative for loop detection.
Or we can keep it like it is today, non-standard and let people who know what they are doing violate it at their own peril.
...like much of the rest of the 'net: "know what you're doing".
The problem with the latter is some ISPs point to standards as if there is no other possible way to do things. Which makes it difficult to be someone who knowingly violates a standard.
I'll point out that in this case, it only matters for the relationship between the island AS and its immediate neighbors; if I'm paying for service that doesn't get me what I want, I vote with my wallet (as we've alreays done). You skip the obvious route; we write a BCP for "Operation of BGP Islands: effective ASN reuse". Some will like it, some will throw stones, and some will insist that it just get folded into an update to RFC4271. Interestingly, a quick re-review of BCP126 doesn't tip its toes into these waters, but there might be room to insert it there.
Anyway, just wondering how others felt.
You like to remind everyone (when convenient) that you don't run a "network" - perhaps It would be nice to hear if anyone who runs *networks* thinks they can discard AS_PATH based loop detection and they want to cook up Some Other Way for BGPv5. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NANOG
On Jun 10, 2013, at 2:22 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
Is it enough to keep the standard? Or should the standard have a specific carve out, e.g. for stub networks only, not allowing islands to provide transit. Just a straw man.
For the moment I'm not going to make a statement one way or another if this should be enshrined in an RFC or not... I would like to be able to apply a route map to "allow as in" behavior: ip prefix-list SPECIAL permit 192.168.0.0/24 ! route-map SAFETY permit 10 match ip prefix-list SPECIAL set community no-export ! router bgp XXX neighbor a.b.c.d allowas-in route-map SAFETY This is a belt and suspenders approach; first you can limit this behavior to only the netblocks you use at other locations, and be extra safe by marking them no-export on the way in. Implementation should be easy, anything that would normally be rejected as an AS-Path loop gets fed into the route-map instead. This would mitigate almost all of the bad effects I can think of that can happen when the network and/or its upstreams fail to properly apply filters and all the sudden there are a lot more routes "looping" than should be, and no mechanism to stop them anymore! :) -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
neighbor a.b.c.d allowas-in route-map SAFETY Wow this would be so cool, I'll definitely mention this to our SE.
I was wondering if the internet service is realized as MPLS VRF than the ISP could do as-override which is pretty standard for VPN services. What I'm curious about is the percentage of tier2/3 ISPs doing full internet in a VRF over common MPLS backbone as I guess it's not that common. adam
however, providers a/b at site1 do not send us the two /24s from site b..
This is probably incorrect. The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection. To answer your later question, this is the definition of 'standard' as it is written into the RFC. Use the allow-as-in style command posted later in this thread to fix your router. -- TTFN, patrick On Jun 10, 2013, at 12:36 , "Dennis Burgess" <dmburgess@linktechs.net> wrote:
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks.
Currently we are announcing several /24s out one network and other /24s out the second network, they do not overlap. To the internet this works fine, however, providers a/b at site1 do not send us the two /24s from site b.. We have requested them to, but have not seen them come in, nor do we have any filters that would prohibit them from coming in.
Is this normal? Can we receive those routes even though they are from our own AS? What is the "best practice" in this case?
Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition <http://www.wlan1.com/product_p/mikrotik%20book-2.htm> "
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270 <tel:314-735-0270> Website: http://www.linktechs.net <http://www.linktechs.net/> - Skype: linktechs <skype:linktechs?call>
-- Create Wireless Coverage's with www.towercoverage.com <http://www.towercoverage.com/> - 900Mhz - LTE - 3G - 3.65 - TV Whitespace
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick W. Gilmore wrote:
however, providers a/b at site1 do not send us the two /24s from site b..
This is probably incorrect.
The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection. To answer your later question, this is the definition of 'standard' as it is written into the RFC.
Use the allow-as-in style command posted later in this thread to fix your router.
Or maintain "standard" behavior by running a GRE tunnel between the two discontinuous sites and run iBGP over the tunnel. - -- ========= bep -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG2DrQACgkQE1XcgMgrtyZVWQCgzeYOVPCWdNz3LKf4AvdsZ2pR I5MAn3ojgD8zaTY4VyaR/7KdaC2YUD7B =nGK/ -----END PGP SIGNATURE-----
On Jun 10, 2013, at 13:36 , Bruce Pinsky <bep@whack.org> wrote:
Patrick W. Gilmore wrote:
however, providers a/b at site1 do not send us the two /24s from site b..
This is probably incorrect.
The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection. To answer your later question, this is the definition of 'standard' as it is written into the RFC.
Use the allow-as-in style command posted later in this thread to fix your router.
Or maintain "standard" behavior by running a GRE tunnel between the two discontinuous sites and run iBGP over the tunnel.
Standard how? I don't remember any such standard, but always willing to be educated. Also, as someone who helps run 2500 non-connected sites, I can't begin to imagine the mess of GRE that would require. (OK, not all are in the same ASN, but I like hyperbole. :) -- TTFN, patrick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick W. Gilmore wrote:
On Jun 10, 2013, at 13:36 , Bruce Pinsky <bep@whack.org> wrote:
Patrick W. Gilmore wrote:
however, providers a/b at site1 do not send us the two /24s from site b..
This is probably incorrect.
The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection. To answer your later question, this is the definition of 'standard' as it is written into the RFC.
Use the allow-as-in style command posted later in this thread to fix your router.
Or maintain "standard" behavior by running a GRE tunnel between the two discontinuous sites and run iBGP over the tunnel.
Standard how? I don't remember any such standard, but always willing to be educated.
Also, as someone who helps run 2500 non-connected sites, I can't begin to imagine the mess of GRE that would require. (OK, not all are in the same ASN, but I like hyperbole. :)
"Standard" in the sense of continuing to reject duplicate ASN in the AS path and not using a BGP knob to allow unnatural behavior. If the networks he wishes to advertise for those sites are considered in the same ASN, there should be continuity between those sites, either physical or virtual. - -- ========= bep -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG2FdcACgkQE1XcgMgrtybZWQCg8CBl8406YFzmXxZgczPYk3z5 sL0AoMe26Q+6vkyOEaEHjKb1BM2/W6DO =AKb8 -----END PGP SIGNATURE-----
I wouldn't look at allowing a route in with the same AS as being non-standard. Protocol behavior has to be managed by the administrator based on their own network needs and requirements. One very common tweak that comes to mind is setting next hop self for advertising ebgp learned routes to ibgp neighbors. In SP networks providing mpls vpn services its common to see the same AS used for all sites in a customer vpn and this requires that the PE routers advertise the routes and that the CE routers accept them etc. Similar to what Patrick said about GRE this could be a management nightmare just for ASN's. -Dan On Jun 10, 2013, at 12:07 PM, Bruce Pinsky <bep@whack.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Patrick W. Gilmore wrote:
On Jun 10, 2013, at 13:36 , Bruce Pinsky <bep@whack.org> wrote:
Patrick W. Gilmore wrote:
however, providers a/b at site1 do not send us the two /24s from site b..
This is probably incorrect.
The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection. To answer your later question, this is the definition of 'standard' as it is written into the RFC.
Use the allow-as-in style command posted later in this thread to fix your router.
Or maintain "standard" behavior by running a GRE tunnel between the two discontinuous sites and run iBGP over the tunnel.
Standard how? I don't remember any such standard, but always willing to be educated.
Also, as someone who helps run 2500 non-connected sites, I can't begin to imagine the mess of GRE that would require. (OK, not all are in the same ASN, but I like hyperbole. :)
"Standard" in the sense of continuing to reject duplicate ASN in the AS path and not using a BGP knob to allow unnatural behavior.
If the networks he wishes to advertise for those sites are considered in the same ASN, there should be continuity between those sites, either physical or virtual.
- -- ========= bep
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlG2FdcACgkQE1XcgMgrtybZWQCg8CBl8406YFzmXxZgczPYk3z5 sL0AoMe26Q+6vkyOEaEHjKb1BM2/W6DO =AKb8 -----END PGP SIGNATURE-----
On Jun 10, 2013, at 14:07 , Bruce Pinsky <bep@whack.org> wrote:
Patrick W. Gilmore wrote:
On Jun 10, 2013, at 13:36 , Bruce Pinsky <bep@whack.org> wrote:
Or maintain "standard" behavior by running a GRE tunnel between the two discontinuous sites and run iBGP over the tunnel.
Standard how? I don't remember any such standard, but always willing to be educated.
Also, as someone who helps run 2500 non-connected sites, I can't begin to imagine the mess of GRE that would require. (OK, not all are in the same ASN, but I like hyperbole. :)
"Standard" in the sense of continuing to reject duplicate ASN in the AS path and not using a BGP knob to allow unnatural behavior.
"Natural" is a funny word here. The reason you think it is natural is that's the way it has always been done. It's not a law or nature or something ghod has wrought. It is essentially a tribal tradition. <cue Topol singing> Tradition is useful, but not a reason in-and-of itself, especially in the face of reasons to break tradition. I think having 100s of 1000s of discontiguous locations is a pretty good reason.
If the networks he wishes to advertise for those sites are considered in the same ASN, there should be continuity between those sites, either physical or virtual.
I disagree. There are times it is simply not realistic to expect continuity. The alternative is to expect "networks" with 100s or 1000s of locations to burn 100s or 1000s of ASNs. Which I think is a bit silly. Hence my question about possibly changing the rules. NB: I fully admit I am biased in this. But that doesn't mean I'm wrong. -- TTFN, patrick
Hi,
The alternative is to expect "networks" with 100s or 1000s of locations to burn 100s or 1000s of ASNs. Which I think is a bit silly. Hence my question about possibly changing the rules.
I see no issue with that, we have an ASN pool of roughly 4294967280 ASNs. There is no shortage. Also BCP6 section 5 [1] would support the philosophy to just get more ASNs when you need to manage multiple islands. Kind regards, Job [1] - http://tools.ietf.org/html/bcp6#section-5
On Jun 10, 2013, at 15:23 , Job Snijders <job.snijders@atrato.com> wrote:
The alternative is to expect "networks" with 100s or 1000s of locations to burn 100s or 1000s of ASNs. Which I think is a bit silly. Hence my question about possibly changing the rules.
I see no issue with that, we have an ASN pool of roughly 4294967280 ASNs. There is no shortage. Also BCP6 section 5 [1] would support the philosophy to just get more ASNs when you need to manage multiple islands.
Ever tried to get a single peer set up sessions in 50+ places with 50+ ASNs? Neither have I. Nor do I plan to try any time soon. Anyway, looks like the comments lean towards "leave it as it is", and some people will knowingly violate the rules, as has been done since the Internet began. -- TTFN, patrick
On Mon, 10 Jun 2013, Patrick W. Gilmore wrote:
Ever tried to get a single peer set up sessions in 50+ places with 50+ ASNs?
I would submit that it's very likely that someone setting up 50+ places will have gained expert level knowledge of BGP and will understand the compromises they are making by "breaking the rules". I think the point is that if this is your first rodeo, perhaps you should stick with the script. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross
Just to update everyone.. Already had the allowas-in setup, the end result is that the ISPs in question tier2 team did not know that they block inbound updates from their upstream(peers) from known ranges inside their network. So, the upstream was blocking the customer prefix as they thought they should only receive that block from our peer with them, vs. receiving those from the "net" Recently, they fixed their filters on their peers and we have now received the /24s in question. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace -----Original Message----- From: Brandon Ross [mailto:bross@pobox.com] Sent: Monday, June 10, 2013 4:28 PM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: Single AS multiple Dirverse Providers On Mon, 10 Jun 2013, Patrick W. Gilmore wrote:
Ever tried to get a single peer set up sessions in 50+ places with 50+ ASNs?
I would submit that it's very likely that someone setting up 50+ places will have gained expert level knowledge of BGP and will understand the compromises they are making by "breaking the rules". I think the point is that if this is your first rodeo, perhaps you should stick with the script. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross
On Mon, Jun 10, 2013 at 10:08 AM, Patrick W. Gilmore <patrick@ianai.net>wrote:
however, providers a/b at site1 do not send us the two /24s from site b..
This is probably incorrect.
The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection.
As noted above, if your *provider* is running JunOS, that is incorrect; by default, Juniper will not send routes out were learned from the same ASN as the one to which the neighbor is configured. http://www.juniper.net/techpubs/software/junos/junos95/swconfig-routing/id-1... I've been bitten by this before. Matt
To answer your later question, this is the definition of 'standard' as it is written into the RFC.
Use the allow-as-in style command posted later in this thread to fix your router.
-- TTFN, patrick
On Jun 10, 2013, at 12:36 , "Dennis Burgess" <dmburgess@linktechs.net> wrote:
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks.
Currently we are announcing several /24s out one network and other /24s out the second network, they do not overlap. To the internet this works fine, however, providers a/b at site1 do not send us the two /24s from site b.. We have requested them to, but have not seen them come in, nor do we have any filters that would prohibit them from coming in.
Is this normal? Can we receive those routes even though they are from our own AS? What is the "best practice" in this case?
Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition <http://www.wlan1.com/product_p/mikrotik%20book-2.htm> "
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270 <tel:314-735-0270> Website: http://www.linktechs.net <http://www.linktechs.net/> - Skype: linktechs <skype:linktechs?call>
-- Create Wireless Coverage's with www.towercoverage.com <http://www.towercoverage.com/> - 900Mhz - LTE - 3G - 3.65 - TV Whitespace
On Jun 10, 2013, at 12:08 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
however, providers a/b at site1 do not send us the two /24s from site b..
This is probably incorrect.
The providers are almost certainly sending you the prefixes, but your router is dropping them due to loop detection. To answer your later question, this is the definition of 'standard' as it is written into the RFC.
Use the allow-as-in style command posted later in this thread to fix your router.
I've done this many places, and find allow-as-in can be, uh, problematic. :) Everyone says to just turn it on, but it's possible to get some strange paths in your table that way, in some circumstances. For most users having a default route is just as good of a solution. Each site will have a full table minus the small number of prefixes at the other site, and a static default will get packets to your upstream that has those routes. Don't like a default? Just static the netblocks at the other side to a particular provider. Already have a default because you weren't taking full tables? You're good to go, no special config needed. Of course it depends on what your site-to-site requirements are, if they are independent islands or talking to each other with critical data all the time. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
A BGP speaker will not accept routes with its own AS in the path, nor should it. Whilst a number of people have suggested using allowas-in, I'd personally not recommend it as loop prevention is generally a good thing - if you ever added a BGP speaker to one network that also had internet peerings (plus iBGP to the existing router) allowas-in would result in internal traffic going over the external link since eBGP is preferred over iBGP. You could of course prevent that by mangling attributes, but why create the potential work and pain for yourself? Instead, I'd suggest setting up iBGP peerings for each of the upstreams, rewriting the next hop address of received routes to the upstream of that particular interface. Since it would really be pointless/wasteful to advertise your internet routes over iBGP, be sure to restrict it to just your own networks. Doing it this way means that you can quite easily just spin up a new peering if you get a real backbone link, and you don't take on the downsides of using allowas-in. Regards Oliver On Monday 10 June 2013 11:36:44 Dennis Burgess wrote:
I have a network that has three peers, two are at one site and the third is geographically diverse, and there is NO connection between the two separate networks.
Currently we are announcing several /24s out one network and other /24s out the second network, they do not overlap. To the internet this works fine, however, providers a/b at site1 do not send us the two /24s from site b.. We have requested them to, but have not seen them come in, nor do we have any filters that would prohibit them from coming in.
Is this normal? Can we receive those routes even though they are from our own AS? What is the "best practice" in this case?
Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition <http://www.wlan1.com/product_p/mikrotik%20book-2.htm> "
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270 <tel:314-735-0270> Website: http://www.linktechs.net <http://www.linktechs.net/> - Skype: linktechs <skype:linktechs?call>
-- Create Wireless Coverage's with www.towercoverage.com <http://www.towercoverage.com/> - 900Mhz - LTE - 3G - 3.65 - TV Whitespace
participants (13)
-
Adam Vitkovsky -
Brandon Ross -
Bruce Pinsky -
Dan -
Dennis Burgess -
Job Snijders -
Joe Abley -
Joe Provo -
joel jaeggli -
Leo Bicknell -
Matthew Petach -
Oliver -
Patrick W. Gilmore