Re: Single AS multiple Dirverse Providers

[Oliver]

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  "
> 
>  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

RE: Single AS multiple Dirverse Providers

[Adam Vitkovsky]

>  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

RE: Single AS multiple Dirverse Providers

[Dennis Burgess]

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:br...@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-6667ICQ:  2269442
Schedule a meeting:  https://doodle.com/brossSkype:  brandonross

Re: Single AS multiple Dirverse Providers

[Brandon Ross]

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-6667ICQ:  2269442
Schedule a meeting:  https://doodle.com/brossSkype:  brandonross

Re: Single AS multiple Dirverse Providers

[Leo Bicknell]

On Jun 10, 2013, at 2:22 PM, Patrick W. Gilmore  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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

Re: Single AS multiple Dirverse Providers

[Joe Provo]

On Mon, Jun 10, 2013 at 03:22:41PM -0400, Patrick W. Gilmore wrote:
> On Jun 10, 2013, at 14:14 , Joe Provo  wrote:
> > On Mon, Jun 10, 2013 at 01:18:04PM -0400, Patrick W. Gilmore wrote:
> >> On Jun 10, 2013, at 12:54 , Joe Provo  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

Re: Single AS multiple Dirverse Providers

[Patrick W. Gilmore]

On Jun 10, 2013, at 15:23 , Job Snijders  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

Re: Single AS multiple Dirverse Providers

[Job Snijders]

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

Re: Single AS multiple Dirverse Providers

[Patrick W. Gilmore]

On Jun 10, 2013, at 14:14 , Joe Provo  wrote:
> On Mon, Jun 10, 2013 at 01:18:04PM -0400, Patrick W. Gilmore wrote:
>> On Jun 10, 2013, at 12:54 , Joe Provo  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

Re: Single AS multiple Dirverse Providers

[Brandon Ross]

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-6667ICQ:  2269442
Schedule a meeting:  https://doodle.com/brossSkype:  brandonross

Re: Single AS multiple Dirverse Providers

[Patrick W. Gilmore]

On Jun 10, 2013, at 14:07 , Bruce Pinsky  wrote:
> Patrick W. Gilmore wrote:
> > On Jun 10, 2013, at 13:36 , Bruce Pinsky  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. 

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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Single AS multiple Dirverse Providers

[Leo Bicknell]

On Jun 10, 2013, at 12:08 PM, 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.


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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Single AS multiple Dirverse Providers

[Dan]

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  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Patrick W. Gilmore wrote:
>> On Jun 10, 2013, at 13:36 , Bruce Pinsky  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-
> 

Re: Single AS multiple Dirverse Providers

[Joe Provo]

On Mon, Jun 10, 2013 at 01:18:04PM -0400, Patrick W. Gilmore wrote:
> On Jun 10, 2013, at 12:54 , Joe Provo  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

Re: Single AS multiple Dirverse Providers

[Bruce Pinsky]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Patrick W. Gilmore wrote:
> On Jun 10, 2013, at 13:36 , Bruce Pinsky  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-

Re: Single AS multiple Dirverse Providers

[Matthew Petach]

On Mon, Jun 10, 2013 at 10:08 AM, 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.


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-13225234.html#id-13255463

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" 
> 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  "
> >
> > 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
> >
> >
> >
>
>
>

Re: Single AS multiple Dirverse Providers

[Patrick W. Gilmore]

On Jun 10, 2013, at 13:36 , Bruce Pinsky  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



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Single AS multiple Dirverse Providers

[Bruce Pinsky]

-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-

Re: Single AS multiple Dirverse Providers

[Patrick W. Gilmore]

On Jun 10, 2013, at 12:54 , Joe Provo  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
> 

Re: Single AS multiple Dirverse Providers

[Patrick W. Gilmore]

> 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"  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  "
> 
> 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  
> 
> 
> 

Re: Single AS multiple Dirverse Providers

[Matthew Petach]

On Mon, Jun 10, 2013 at 9:43 AM, Joe Abley  wrote:

>
> On 2013-06-10, at 18:36, "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?
>
> 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-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.

Matt

Re: Single AS multiple Dirverse Providers

[Joe Provo]

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

Re: Single AS multiple Dirverse Providers

[Joe Abley]

On 2013-06-10, at 18:43, Joe Abley  wrote:

> [...] neigh x.x.x.x allowas-in" on JunOS.

Actually, I think that's JunOSe. Or however you capitalise it.


Joe

Re: Single AS multiple Dirverse Providers

[joel jaeggli]

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  "

  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

Re: Single AS multiple Dirverse Providers

[joel jaeggli]

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  "

  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

  

Re: Single AS multiple Dirverse Providers

[Joe Abley]

On 2013-06-10, at 18:36, "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?

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