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?
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.
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)
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)
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.
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-13225234.html#id-13255463
So, you may need to help walk them through adding the "advertise-peer-as"
flag to your neighbor configurations if they use Juniper kit.
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.
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.
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.
> 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.
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.
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.
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.
>> 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.
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?
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.
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.
