Re: Some advice on IPv6 planning and ARIN request, please

[Bjørn Mork]

Mark Andrews  writes:

> If I had 32 departments and were wanting to give them equal sized
> allocations then I'd give them a /53 each which is 2064 subnets
> each.  It isn't that hard to do 8 delegations in the reverse tree
> for each of the 32 departments.  Delegation on nibble boundaries
> is for convience and nothing else.

I believe you under-estimate the importance of sysadmin convenience...

Yes, you *can* do 8 delegations.  And you are of course right - it's not
even hard.  But it does come with a "less convenient" price tag, so
you'd better get something back.  What was that, exactly?  Right, you
saved a /48.  Big deal.


Bjørn

Re: Some advice on IPv6 planning and ARIN request, please

[William Herrin]

On Mon, Jul 10, 2017 at 11:09 PM, Mark Andrews  wrote:

> If I had 32 departments and were wanting to give them equal sized
> allocations then I'd give them a /53 each which is 2064 subnets
> each.  It isn't that hard to do 8 delegations in the reverse tree
> for each of the 32 departments.  Delegation on nibble boundaries
> is for convience and nothing else.
>

For comprehensibility which nets convenience. Consistently delegate on
nibble boundaries and your power users don't have to understand Boolean
algebra to make sense of the network.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Some advice on IPv6 planning and ARIN request, please

[Mark Andrews]

In message , William Herrin writes:
> On Mon, Jul 10, 2017 at 11:09 PM, Mark Andrews  wrote:
> 
> > If I had 32 departments and were wanting to give them equal sized
> > allocations then I'd give them a /53 each which is 2064 subnets
> > each.  It isn't that hard to do 8 delegations in the reverse tree
> > for each of the 32 departments.  Delegation on nibble boundaries
> > is for convience and nothing else.
> 
> For comprehensibility which nets convenience. Consistently delegate on
> nibble boundaries and your power users don't have to understand Boolean
> algebra to make sense of the network.

Hexadecimal is much much simpler than decimal to work with on non
nibble/octet boundaries.  I think most people are applying IPv4 non
octet experience to non nibble IPv6 addressing.  The two are nowhere
near comparable having had to work with both.

> Regards,
> Bill Herrin
> 
> -- 
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

BGP peering question

[craig washington]

Hello,


Newbie question, what criteria do you look for when you decide that you want to 
peer with someone or if you will accept peering with someone from an ISP point 
of view.


Thanks.

Re: BGP peering question

[Patrick W. Gilmore]

1) Are they present an IX where I am present?

2) Can they configure BGP correctly?

3) … Beer?

Private interconnect requires actual thinking. Putting a procedure in around 
public peering is just overhead we don’t need.

-- 
TTFN,
patrick

> On Jul 10, 2017, at 4:12 PM, craig washington  
> wrote:
> 
> Hello,
> 
> 
> Newbie question, what criteria do you look for when you decide that you want 
> to peer with someone or if you will accept peering with someone from an ISP 
> point of view.
> 
> 
> Thanks.
> 
> 

Re: BGP peering question

[Bryan Holloway]

Also worth looking at your telemetries to see if it makes sense from an 
inbound/outbound point of view.


That is, you'll get more bang for your buck if you're eyeballs and 
peering with a content provider (or vice versa), as opposed to eyeballs 
<-> eyeballs or content <-> content.



On 7/11/17 11:52 AM, Patrick W. Gilmore wrote:

1) Are they present an IX where I am present?

2) Can they configure BGP correctly?

3) … Beer?

Private interconnect requires actual thinking. Putting a procedure in around 
public peering is just overhead we don’t need.

Re: BGP peering question

[William Herrin]

On Mon, Jul 10, 2017 at 4:12 PM, craig washington <
craigwashingto...@hotmail.com> wrote:

> Newbie question, what criteria do you look for when you decide that you
> want to peer with someone or if you will accept peering with someone from
> an ISP point of view.


I assume you mean "reciprocal peering" in the sense of shortcut from your
customers to their customers rather than the more generic sense that any
BGP neighbor is a "peer".

1. What does it cost? If you and they are already on an IX peering switch
or you're both at a relaxed location where running another cable carries no
monthly fee, there's not much down side.

2. Is the improvement to your service worth the cost? It's not worth buying
a data circuit or cross-connect to support a 100kbps trickle.

3. Do you have the technical acumen to stay on top of it? Some kinds of
breakage in the peering link could jam traffic between your customers and
theirs. If you're not able to notice and respond, you'd be better off
sending the traffic up to your ISPs and letting them worry about it.

If the three of those add up to "yes" instead of "no" then peering may be
smart.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: BGP peering question

[Niels Bakker]

* br...@shout.net (Bryan Holloway) [Tue 11 Jul 2017, 19:28 CEST]:
Also worth looking at your telemetries to see if it makes sense from 
an inbound/outbound point of view.


That is, you'll get more bang for your buck if you're eyeballs and 
peering with a content provider (or vice versa), as opposed to 
eyeballs <-> eyeballs or content <-> content.


Luckily these are not exclusionary so you can peer with all networks 
present at an Internet exchange with no repercussions.



-- Niels.

Re: BGP peering question

[Bob Evans]

There is one more thing to consider based on your app or content latency
criteria needs. Do you provide a service that performs better with low
latency - such as live desktop, live video/voice. You may wish to peer to
have more control and more direct  path to your customer base. If you
identify your customer base in a specific region - then explore the best
peering exchange points to utilize in that region. This can help you
reduce your packet hop count/ deliver time, etc. etc..

Thank You
Bob Evans
CTO




> On Mon, Jul 10, 2017 at 4:12 PM, craig washington <
> craigwashingto...@hotmail.com> wrote:
>
>> Newbie question, what criteria do you look for when you decide that you
>> want to peer with someone or if you will accept peering with someone
>> from
>> an ISP point of view.
>
>
> I assume you mean "reciprocal peering" in the sense of shortcut from your
> customers to their customers rather than the more generic sense that any
> BGP neighbor is a "peer".
>
> 1. What does it cost? If you and they are already on an IX peering switch
> or you're both at a relaxed location where running another cable carries
> no
> monthly fee, there's not much down side.
>
> 2. Is the improvement to your service worth the cost? It's not worth
> buying
> a data circuit or cross-connect to support a 100kbps trickle.
>
> 3. Do you have the technical acumen to stay on top of it? Some kinds of
> breakage in the peering link could jam traffic between your customers and
> theirs. If you're not able to notice and respond, you'd be better off
> sending the traffic up to your ISPs and letting them worry about it.
>
> If the three of those add up to "yes" instead of "no" then peering may be
> smart.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
>

Re: BGP peering question

[Ethan E. Dee]

Considering the wording you use, I would include this,

'Peering' is not always necessary. If you can get an upstream provider 
to give you a pack of IP's and it is sufficient to just use them as a 
gateway instead of setting up peering that would be preferred.


If you decide you want to have multiple upstream providers or hit some 
kind of speed cap is when I would probably peer with someone else. So 
that you can keep your IP space but share it across a redundant 
connection from a different provider.


Then you need to decide if you want to be a hop between those two peers 
or if you want them to serve you only. You can change your routing so 
that both providers know of your routes but you are not sharing routes 
between the two providers.


BGP is an enormous protocol and extremely scalable so there is alot to 
consider before you even decide if you want to peer.


Because it can sometimes be a headache to setup.


On 07/11/2017 02:17 PM, Bob Evans wrote:

There is one more thing to consider based on your app or content latency
criteria needs. Do you provide a service that performs better with low
latency - such as live desktop, live video/voice. You may wish to peer to
have more control and more direct  path to your customer base. If you
identify your customer base in a specific region - then explore the best
peering exchange points to utilize in that region. This can help you
reduce your packet hop count/ deliver time, etc. etc..

Thank You
Bob Evans
CTO





On Mon, Jul 10, 2017 at 4:12 PM, craig washington <
craigwashingto...@hotmail.com> wrote:


Newbie question, what criteria do you look for when you decide that you
want to peer with someone or if you will accept peering with someone
from
an ISP point of view.


I assume you mean "reciprocal peering" in the sense of shortcut from your
customers to their customers rather than the more generic sense that any
BGP neighbor is a "peer".

1. What does it cost? If you and they are already on an IX peering switch
or you're both at a relaxed location where running another cable carries
no
monthly fee, there's not much down side.

2. Is the improvement to your service worth the cost? It's not worth
buying
a data circuit or cross-connect to support a 100kbps trickle.

3. Do you have the technical acumen to stay on top of it? Some kinds of
breakage in the peering link could jam traffic between your customers and
theirs. If you're not able to notice and respond, you'd be better off
sending the traffic up to your ISPs and letting them worry about it.

If the three of those add up to "yes" instead of "no" then peering may be
smart.

Regards,
Bill Herrin


--
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 





--
Ethan Dee
Network Admin
Globalvision
864 704 3600
e...@globalvision.net

For Support:
gv-supp...@globalvision.net
864 467 1333

For Sales:
sa...@globalvision.net
864 467 1333

Re: BGP peering question

[Nick Hilliard]

craig washington wrote:
> Newbie question, what criteria do you look for when you decide that
> you want to peer with someone or if you will accept peering with
> someone from an ISP point of view.

If you're new to the game, peer with everyone you can and use route
servers aggressively.  You have nothing to lose and everything to gain.

At the point at which you have a medium sized network, in the sense of
maintaining multiple peering points, PNIs, transit customers, and tens
to hundreds of gigs of traffic (i.e. the stage at which you actually
have to think a bit about your traffic routing policies), you might want
to consider whether it's worth your while peering with smaller players
and also whether whether route servers are still a good fit for your
business requirements.

If you are very large, the rules are completely different and will
depend entirely on your business model.  Some organisations thrive on
open interconnection models; others prefer to be highly selective.

Nick

Re: BGP peering question

[Patrick W. Gilmore]

> Then you need to decide if you want to be a hop between those two peers or if 
> you want them to serve you only. You can change your routing so that both 
> providers know of your routes but you are not sharing routes between the two 
> providers.

The definition of “peering” to most ISPs would definitely not include becoming 
a “hop” between two peers. Most networks would de-peer you if you sent their 
prefixes to another peer.

-- 
TTFN,
patrick

> On Jul 11, 2017, at 2:40 PM, Ethan E. Dee  wrote:
> 
> Considering the wording you use, I would include this,
> 
> 'Peering' is not always necessary. If you can get an upstream provider to 
> give you a pack of IP's and it is sufficient to just use them as a gateway 
> instead of setting up peering that would be preferred.
> 
> If you decide you want to have multiple upstream providers or hit some kind 
> of speed cap is when I would probably peer with someone else. So that you can 
> keep your IP space but share it across a redundant connection from a 
> different provider.
> 
> Then you need to decide if you want to be a hop between those two peers or if 
> you want them to serve you only. You can change your routing so that both 
> providers know of your routes but you are not sharing routes between the two 
> providers.
> 
> BGP is an enormous protocol and extremely scalable so there is alot to 
> consider before you even decide if you want to peer.
> 
> Because it can sometimes be a headache to setup.
> 
> 
> On 07/11/2017 02:17 PM, Bob Evans wrote:
>> There is one more thing to consider based on your app or content latency
>> criteria needs. Do you provide a service that performs better with low
>> latency - such as live desktop, live video/voice. You may wish to peer to
>> have more control and more direct  path to your customer base. If you
>> identify your customer base in a specific region - then explore the best
>> peering exchange points to utilize in that region. This can help you
>> reduce your packet hop count/ deliver time, etc. etc..
>> 
>> Thank You
>> Bob Evans
>> CTO
>> 
>> 
>> 
>> 
>>> On Mon, Jul 10, 2017 at 4:12 PM, craig washington <
>>> craigwashingto...@hotmail.com> wrote:
>>> 
 Newbie question, what criteria do you look for when you decide that you
 want to peer with someone or if you will accept peering with someone
 from
 an ISP point of view.
>>> 
>>> I assume you mean "reciprocal peering" in the sense of shortcut from your
>>> customers to their customers rather than the more generic sense that any
>>> BGP neighbor is a "peer".
>>> 
>>> 1. What does it cost? If you and they are already on an IX peering switch
>>> or you're both at a relaxed location where running another cable carries
>>> no
>>> monthly fee, there's not much down side.
>>> 
>>> 2. Is the improvement to your service worth the cost? It's not worth
>>> buying
>>> a data circuit or cross-connect to support a 100kbps trickle.
>>> 
>>> 3. Do you have the technical acumen to stay on top of it? Some kinds of
>>> breakage in the peering link could jam traffic between your customers and
>>> theirs. If you're not able to notice and respond, you'd be better off
>>> sending the traffic up to your ISPs and letting them worry about it.
>>> 
>>> If the three of those add up to "yes" instead of "no" then peering may be
>>> smart.
>>> 
>>> Regards,
>>> Bill Herrin
>>> 
>>> 
>>> --
>>> William Herrin  her...@dirtside.com  b...@herrin.us
>>> Dirtside Systems . Web: 
>>> 
>> 
> 
> -- 
> Ethan Dee
> Network Admin
> Globalvision
> 864 704 3600
> e...@globalvision.net
> 
> For Support:
> gv-supp...@globalvision.net
> 864 467 1333
> 
> For Sales:
> sa...@globalvision.net
> 864 467 1333

Re: BGP peering question

[William Herrin]

On Tue, Jul 11, 2017 at 3:24 PM, Patrick W. Gilmore 
wrote:

> > Then you need to decide if you want to be a hop between those two peers
> or if you want them to serve you only. You can change your routing so that
> both providers know of your routes but you are not sharing routes between
> the two providers.
>
> The definition of “peering” to most ISPs would definitely not include
> becoming a “hop” between two peers. Most networks would de-peer you if you
> sent their prefixes to another peer.
>

Hi Patrick,

I'm given to understand this practice is common in service providers
connecting academia. Three or more service providers serving schools will
agree to pass packets even if neither school terminates at the current ISP.

This comes up in the discussion of "valley free" inter-domain routing
because it's one of the cases that forms a valley where the participating
organization is not paid for or directly donating the transiting packets.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: BGP peering question

[Nick Hilliard]

Patrick W. Gilmore wrote:
> 1) Are they present an IX where I am present?
> 
> 2) Can they configure BGP correctly?
> 
> 3) … Beer?

Naah, way overthought.  I prefer the traditional:

1) do they have a pulse?

Nick

RE: Some advice on IPv6 planning and ARIN request, please

[Aaron Gould]

Hence my mention of thinking it was a "sin" to subnet on the bit boundary in
v6... again, I will do my best to never go back to bit boundary subnetting
math in my v6 deployment.  Actually, you folks are giving me bad flashbacks
to my ATM H-PNNI days of pnni peer group nsap address subnetting.  Oh how
nice it was to view the atm switch nsap prefix in hex and view the peer
group level's at the hex boundary until we got to a place where we needed to
get a 4th level from 96-104 I recall going with 98... we had to do bit
boundary pnni level 98... I don't want to have to do that with v6 if I can
avoid it

-Aaron

Hacked DVRs again?! (Probably the wrong forum, but probably of interest nonetheless)

[Large Hadron Collider]

So, I run a small chat service and it has attracted abuse from multiple 
kinds of open device.


Most recently, I've found DVRs being spammed through. This is the kind 
of "default password"/"open Cisco" abuse that is very hard to detect 
with an open proxy scanner without, well, logging in and seeing if you 
get a shell.


Has anyone ever seen this? What can I do to prevent it?