Re: Internet Exchanges supporting jumbo frames?

[Mark Tinka]

On 10/Mar/16 00:22, Tassos Chatzithomaoglou wrote:

> I must be missing something very obvious here, because i cannot think of any 
> reason why an IXP shouldn't enable the maximum possible MTU on its 
> infrastructure to be available to its customers. Then it's clearly customers' 
> decision on what MTU to use on their devices, as long as:
>
>   * It fits inside IXP's MTU
>   * It suits with any other customer's (exchanging traffic with) MTU

This is a valid point.

Mark.

Re: Internet Exchanges supporting jumbo frames?

[Tassos Chatzithomaoglou]

Niels Bakker wrote on 10/3/16 02:44:
> * nanog@nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59 CET]:
>> I'm pretty confident there is no need for a specific MTU consensus and not 
>> all IXP participants are obligated to raise their interface MTU if the IXP 
>> starts allowing jumbo frames.
>
> You're wrong here.  The IXP switch platform cannot send ICMP Packet Too Big 
> messages.  That's why everybody must agree on one MTU.
>
>
Isn't that the case for IXP's current/default MTU?
If an IXP currently uses 1500, what effect will it have to its customers if 
it's increased to 9200 but not announced to them?

--
Tassos

RE: Facebook & Traceroute

[Sam Norris]

> maybe their loadbalancer is a little wonky? (I don't see this in
> traceroutes from a few places, but I also don't end up at IAD for
> 'www.facebook.com' traceroutes... here's my last 4 hops though to the
> dest-ip you had:
> 
> .13.28.75)  0.597 ms ae0.dr08.ash2.tfbnw.net (31.13.26.235)  0.576 ms
>  8  * * *
>  9  * * *
> 10  * * *
> 11  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  0.774 ms
> 0.755 ms  0.701 ms

This is probably because you are properly filtering your own prefixes from 
being sourced outside coming in?

Re: Facebook & Traceroute

[Brandon Martin]

On 03/09/2016 10:53 PM, Sam Norris wrote:

Why does Facebook spoof the source IP address of the hop before this server?
They spoof the source IP address that is performing the traceroute.

...

(31.13.28.207)  67.846 ms ae12.dr08.ash3.tfbnw.net (31.13.29.191)  68.629 ms
12  * * *
13  * * *
14  8.25.38.1 (8.25.38.1)  68.571 ms  68.718 ms  68.132 ms
15  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  67.903 ms  67.752
ms  68.071 ms
---

Hop 14 is the source ip of the traceroute which is forged. This essentially
makes hop 14 reply using the same ip for src and dst.


If intentional, I would speculate that this might be something to help 
their support staff by giving them confirmation of where the traceroute 
actually originated from in the public Internet view given that the 
originator might actually be behind possibly several layers of NAT.  The 
two missing hops could be a marker or perhaps other info that got eaten 
due to various source filters?


--
Brandon Martin

Re: Facebook & Traceroute

[Christopher Morrow]

On Wed, Mar 9, 2016 at 10:53 PM, Sam Norris  wrote:
> Why does Facebook spoof the source IP address of the hop before this server?
> They spoof the source IP address that is performing the traceroute.
>
> 66.220.156.68
>
> ---
>  7  FACEBOOK-IN.ear1.Atlanta2.Level3.net (4.16.185.58)  51.736 ms  51.678 ms
> 52.075 ms
>  8  ae2.bb01.atl1.tfbnw.net (74.119.78.214)  51.636 ms  51.584 ms  51.720 ms
>  9  be36.bb01.frc3.tfbnw.net (31.13.26.199)  58.669 ms ae4.bb05.frc3.tfbnw.net
> (31.13.27.129)  61.085 ms ae16.bb06.frc3.tfbnw.net (74.119.76.117)  59.731 ms
> 10  ae5.bb04.iad3.tfbnw.net (31.13.26.57)  111.338 ms ae7.bb04.iad3.tfbnw.net
> (31.13.31.245)  110.007 ms  110.015 ms
> 11  ae9.dr07.ash3.tfbnw.net (31.13.29.29)  68.692 ms ae10.dr08.ash2.tfbnw.net
> (31.13.28.207)  67.846 ms ae12.dr08.ash3.tfbnw.net (31.13.29.191)  68.629 ms
> 12  * * *
> 13  * * *
> 14  8.25.38.1 (who)  68.571 ms  68.718 ms  68.132 ms
> 15  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  67.903 ms  67.752
> ms  68.071 ms
> ---
>
> Hop 14 is the source ip of the traceroute which is forged. This essentially
> makes hop 14 reply using the same ip for src and dst.

maybe their loadbalancer is a little wonky? (I don't see this in
traceroutes from a few places, but I also don't end up at IAD for
'www.facebook.com' traceroutes... here's my last 4 hops though to the
dest-ip you had:

.13.28.75)  0.597 ms ae0.dr08.ash2.tfbnw.net (31.13.26.235)  0.576 ms
 8  * * *
 9  * * *
10  * * *
11  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  0.774 ms
0.755 ms  0.701 ms

Facebook & Traceroute

[Sam Norris]

Why does Facebook spoof the source IP address of the hop before this server?
They spoof the source IP address that is performing the traceroute.

66.220.156.68

---
 7  FACEBOOK-IN.ear1.Atlanta2.Level3.net (4.16.185.58)  51.736 ms  51.678 ms
52.075 ms
 8  ae2.bb01.atl1.tfbnw.net (74.119.78.214)  51.636 ms  51.584 ms  51.720 ms
 9  be36.bb01.frc3.tfbnw.net (31.13.26.199)  58.669 ms ae4.bb05.frc3.tfbnw.net
(31.13.27.129)  61.085 ms ae16.bb06.frc3.tfbnw.net (74.119.76.117)  59.731 ms
10  ae5.bb04.iad3.tfbnw.net (31.13.26.57)  111.338 ms ae7.bb04.iad3.tfbnw.net
(31.13.31.245)  110.007 ms  110.015 ms
11  ae9.dr07.ash3.tfbnw.net (31.13.29.29)  68.692 ms ae10.dr08.ash2.tfbnw.net
(31.13.28.207)  67.846 ms ae12.dr08.ash3.tfbnw.net (31.13.29.191)  68.629 ms
12  * * *
13  * * *
14  8.25.38.1 (8.25.38.1)  68.571 ms  68.718 ms  68.132 ms
15  edge-star-mini-shv-07-ash4.facebook.com (66.220.156.68)  67.903 ms  67.752
ms  68.071 ms
---

Hop 14 is the source ip of the traceroute which is forged. This essentially
makes hop 14 reply using the same ip for src and dst.

Sam

Re: .pro whois registry down?

[Doug Barton]

On 03/09/2016 04:54 PM, Mark Andrews wrote:

Additionally we should be publishing where the whois server for the
tld is in the DNS.  whois applications could be looking for this
then falling back to other methods.

e.g.

_whois._tcp.pro. srv 0 100 43 whois.afilias.net.

If we want machines to follow referrals we have to provide them in
appropriate forms.


Brilliant, wish I'd thought of it :)

Doug

Re: [tld-admin-poc] Fwd: Re: .pro whois registry down?

[Suresh Ramasubramanian]

Worst comes to worst there's a python based whois client called pwhois that 
lets you dump whois data into json 

--srs

> On 10-Mar-2016, at 6:50 AM, Royce Williams  wrote:
> 
> I'm not affiliated, but there are a couple of companies that normalize
> whois data.  It's a whackamole game, but it sucks less than trying to
> do it yourself.

Re: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?

[Royce Williams]

On Wed, Mar 9, 2016 at 3:54 PM, Mark Andrews  wrote:
>
> Additionally 'whois' is free form text.  Whois doesn't include a
> AI to workout what this free form text means so, no, there isn't a
> actual referral for a whois application to use.

I'm not affiliated, but there are a couple of companies that normalize
whois data.  It's a whackamole game, but it sucks less than trying to
do it yourself.

> Additionally we should be publishing where the whois server for the
> tld is in the DNS.  whois applications could be looking for this
> then falling back to other methods.
>
> e.g.
>
> _whois._tcp.pro. srv 0 100 43 whois.afilias.net.
>
> If we want machines to follow referrals we have to provide them in
> appropriate forms.

That's a great idea.

Royce

Re: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?

[Mark Andrews]

Additionally 'whois' is free form text.  Whois doesn't include a
AI to workout what this free form text means so, no, there isn't a
actual referral for a whois application to use.

Additionally we should be publishing where the whois server for the
tld is in the DNS.  whois applications could be looking for this
then falling back to other methods.

e.g.

_whois._tcp.pro. srv 0 100 43 whois.afilias.net.

If we want machines to follow referrals we have to provide them in
appropriate forms.

Mark

In message <56e0bfd4.7020...@dougbarton.us>, Doug Barton writes:
> Joseph,
> 
> Thanks for the update. However the current state of things is not good 
> ... My Ubuntu host tries to use whois.dotproregistry.net, which has no 
> address records. FreeBSD by default uses pro.whois-servers.net, which 
> resolves to whois.registrypro.pro (which has an A record), but never 
> returns with any data (arguably worse than failing immediately with an 
> obvious error).
> 
> If it were me, I would have done the following:
> 
> 1. Reach out to the OS vendors and the folks at whois-servers.net with 
> information that the proper host name for your whois service is 
> changing. Include a drop-dead date of 3 years in the future for the old 
> names to stop working.
> 
> 2. Place a CNAME at the two (or more?) old host names so that the 
> service will continue to work in the meantime.
> 
> The CNAME costs you nothing, and while I agree that it should be able to 
> be removed at some point in the future, having things not work at all in 
> the short term is not the right approach.
> 
> It's also not realistic to expect folks to be able to chase this down on 
> their own ... anyone familiar with using whois on the command line has 
> most assuredly grown accustomed to the convenience of having it "just 
> work," as it has for the last decade or so. While people certainly *can* 
> go back to the "good old days" of having to hunt down each registry's 
> whois server individually, it's hard to think of that as the best approach.
> 
> Is there some reason that the above can't be/hasn't been done that I'm 
> missing?
> 
> Doug
> 
> 
> On 03/09/2016 02:17 PM, Joseph Yee wrote:
> > Hi Doug,
> >
> > Afilias had updated .PRO whois host in Jan 2016, and we filed the record
> > to ICANN & IANA (http://www.iana.org/domains/root/db/pro.html).
> >
> > The new host is 'whois.afilias.net ' and not
> > 'whois.dotproregistry.net ' anymore.
> >
> > Some operating systems may not update their whois configuration yet.
> > You may need to check and update the configuration manually for PRO
> > WHOIS server before official patch were available.
> >
> > Best Regards,
> > Joseph Yee
> > Afilias
> >
> > On Wed, Mar 9, 2016 at 4:56 PM, Michael Flanagan  > > wrote:
> >
> > -Original Message-
> > From: Doug Barton [mailto:do...@dougbarton.us
> > ]
> > Sent: Wednesday, March 09, 2016 4:54 PM
> > To: tld-admin-...@afilias.info ;
> > tld-tech-...@afilias.info 
> > Subject: [tld-admin-poc] Fwd: Re: .pro whois registry down?
> >
> > FYI
> >
> >  Forwarded Message 
> > Subject: Re: .pro whois registry down?
> > Date: Wed, 9 Mar 2016 13:51:28 -0800
> > From: Doug Barton >
> > To: Bryan Holloway  > >, NANOG list  > >
> >
> > On 03/09/2016 01:24 PM, Bryan Holloway wrote:
> >  > Anyone else noticing that the .pro TLD is failing for some
> > things, and
> >  > their WHOIS registry appears to be unavailable?
> >
> > The delegation from the root to PRO, and the PRO name servers
> > themselves,
> > seem to be working.
> >
> >  > I appear to be able to resolve, but whois times out, and we're
> > getting
> >  > reports that mail isn't going through for some folks with this TLD.
> >
> > The address records for whois.dotproregistry.net
> >  are missing.
> >
> > Doug
> >
> >
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Internet Exchanges supporting jumbo frames?

[Niels Bakker]

* nanog@nanog.org (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59 CET]:
I'm pretty confident there is no need for a specific MTU consensus 
and not all IXP participants are obligated to raise their interface 
MTU if the IXP starts allowing jumbo frames.


You're wrong here.  The IXP switch platform cannot send ICMP Packet 
Too Big messages.  That's why everybody must agree on one MTU.



So we have Tier-1 backbones moving jumbo frames around continents, 
why in a controlled L2 enviroment that usually resides in a single 
building and managed by a single controller having jumbo frames is 
that concerning?


Because the L3 devices connected to it aren't controlled by a single entity.


-- Niels.

Re: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?

[Doug Barton]

Joseph,

Thanks for the update. However the current state of things is not good 
... My Ubuntu host tries to use whois.dotproregistry.net, which has no 
address records. FreeBSD by default uses pro.whois-servers.net, which 
resolves to whois.registrypro.pro (which has an A record), but never 
returns with any data (arguably worse than failing immediately with an 
obvious error).


If it were me, I would have done the following:

1. Reach out to the OS vendors and the folks at whois-servers.net with 
information that the proper host name for your whois service is 
changing. Include a drop-dead date of 3 years in the future for the old 
names to stop working.


2. Place a CNAME at the two (or more?) old host names so that the 
service will continue to work in the meantime.


The CNAME costs you nothing, and while I agree that it should be able to 
be removed at some point in the future, having things not work at all in 
the short term is not the right approach.


It's also not realistic to expect folks to be able to chase this down on 
their own ... anyone familiar with using whois on the command line has 
most assuredly grown accustomed to the convenience of having it "just 
work," as it has for the last decade or so. While people certainly *can* 
go back to the "good old days" of having to hunt down each registry's 
whois server individually, it's hard to think of that as the best approach.


Is there some reason that the above can't be/hasn't been done that I'm 
missing?


Doug


On 03/09/2016 02:17 PM, Joseph Yee wrote:

Hi Doug,

Afilias had updated .PRO whois host in Jan 2016, and we filed the record
to ICANN & IANA (http://www.iana.org/domains/root/db/pro.html).

The new host is 'whois.afilias.net ' and not
'whois.dotproregistry.net ' anymore.

Some operating systems may not update their whois configuration yet.
You may need to check and update the configuration manually for PRO
WHOIS server before official patch were available.

Best Regards,
Joseph Yee
Afilias

On Wed, Mar 9, 2016 at 4:56 PM, Michael Flanagan > wrote:

-Original Message-
From: Doug Barton [mailto:do...@dougbarton.us
]
Sent: Wednesday, March 09, 2016 4:54 PM
To: tld-admin-...@afilias.info ;
tld-tech-...@afilias.info 
Subject: [tld-admin-poc] Fwd: Re: .pro whois registry down?

FYI

 Forwarded Message 
Subject: Re: .pro whois registry down?
Date: Wed, 9 Mar 2016 13:51:28 -0800
From: Doug Barton >
To: Bryan Holloway >, NANOG list >

On 03/09/2016 01:24 PM, Bryan Holloway wrote:
 > Anyone else noticing that the .pro TLD is failing for some
things, and
 > their WHOIS registry appears to be unavailable?

The delegation from the root to PRO, and the PRO name servers
themselves,
seem to be working.

 > I appear to be able to resolve, but whois times out, and we're
getting
 > reports that mail isn't going through for some folks with this TLD.

The address records for whois.dotproregistry.net
 are missing.

Doug

Re: Internet Exchanges supporting jumbo frames?

[Kurt Kraut via NANOG]

Hello folks,


First of all, thank you all for this amazing debate. So many important
ideas were exposed here and I wish we keep going on this. I've seen many
opposition to my proposal but I still remain on the side of jumbo frame
adoption for IXP. I'm pretty confident there is no need for a specific MTU
consensus and not all IXP participants are obligated to raise their
interface MTU if the IXP starts allowing jumbo frames.

One of the reasons I'm so surprised with concerns about compatibility and
breaking the internet I've seen here is the offers I get from my IP transit
providers: half of them offered me jumbo frame capable ports by default, it
wasn't a request. When this subject became important to me and I open
support tickets, half of them replied something like 'You don't need to
request it. From our end the max MTU is X'. The lowest X I got was 4400 and
the highest 9260 bytes. All my Tier-1 providers already provided me jumbo
frames IP transit. Even my south american IP Transit provider activated my
link with 9k MTU by default.

So we have Tier-1 backbones moving jumbo frames around continents, why in a
controlled L2 enviroment that usually resides in a single building and
managed by a single controller having jumbo frames is that concerning?

Best regards,


Kurt Kraut

2016-03-09 19:22 GMT-03:00 Tassos Chatzithomaoglou :

> I must be missing something very obvious here, because i cannot think of
> any reason why an IXP shouldn't enable the maximum possible MTU on its
> infrastructure to be available to its customers. Then it's clearly
> customers' decision on what MTU to use on their devices, as long as:
>
>   * It fits inside IXP's MTU
>   * It suits with any other customer's (exchanging traffic with) MTU
>
>
> --
> Tassos
>
> Kurt Kraut via NANOG wrote on 9/3/16 16:26:
> > Hi,
> >
> >
> > I'm trying to convince my local Internet Exchange location (and it is not
> > small, exceed 1 terabit per second on a daily basis) to adopt jumbo
> frames.
> > For IPv6 is is hassle free, Path MTU Discovery arranges the max MTU per
> > connection/destination.
> >
> > For IPv4, it requires more planning. For instance, two datacenters tend
> to
> > exchange relevant traffic because customers  with disaster recovery in
> mind
> > (saving the same content in two different datacenters, two different
> > suppliers). In most cases, these datacenters are quite far from each
> other,
> > even in different countries. In this context, jumbo frames would allow
> max
> > speed even the latency is from a tipical international link.
> >
> > Could anyone share with me Internet Exchanges you know that allow jumbo
> > frames (like https://www.gr-ix.gr/specs/ does) and how you notice
> benefit
> > from it?
> >
> >
> > Best regards,
> >
> >
> > Kurt Kraut
> >
>
>

Re: .pro whois registry down?

[Tony Finch]

Doug Barton  wrote:

> On 03/09/2016 01:24 PM, Bryan Holloway wrote:
> > Anyone else noticing that the .pro TLD is failing for some things, and
> > their WHOIS registry appears to be unavailable?
>
> The address records for whois.dotproregistry.net are missing.

Well, it depends how you find the .pro whois servers, and I am pleased
that my recent changes to FreeBSD whois handle this case OK.

If you use pro.whois-servers.net aka whois.registrypro.pro the connection
times out. (It is sad that the often excellent whois-servers.net doesn't
work as well as it used to.)

If you use whois.nic.pro then it works. (This is the standard name
required for new gTLDs.)

If you follow the referral from whois.iana.org to whois.afilias.net then
it works.

More on whois at http://fanf.livejournal.com/140505.html

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
East Dogger, Fisher, German Bight: Southeasterly 4 or 5. Slight or moderate.
Fog patches for a time. Moderate or good, occasionally very poor.

Re: Internet Exchanges supporting jumbo frames?

[Tassos Chatzithomaoglou]

I must be missing something very obvious here, because i cannot think of any 
reason why an IXP shouldn't enable the maximum possible MTU on its 
infrastructure to be available to its customers. Then it's clearly customers' 
decision on what MTU to use on their devices, as long as:

  * It fits inside IXP's MTU
  * It suits with any other customer's (exchanging traffic with) MTU


--
Tassos

Kurt Kraut via NANOG wrote on 9/3/16 16:26:
> Hi,
>
>
> I'm trying to convince my local Internet Exchange location (and it is not
> small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames.
> For IPv6 is is hassle free, Path MTU Discovery arranges the max MTU per
> connection/destination.
>
> For IPv4, it requires more planning. For instance, two datacenters tend to
> exchange relevant traffic because customers  with disaster recovery in mind
> (saving the same content in two different datacenters, two different
> suppliers). In most cases, these datacenters are quite far from each other,
> even in different countries. In this context, jumbo frames would allow max
> speed even the latency is from a tipical international link.
>
> Could anyone share with me Internet Exchanges you know that allow jumbo
> frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit
> from it?
>
>
> Best regards,
>
>
> Kurt Kraut
>

Re: Internet Exchanges supporting jumbo frames?

[Nick Hilliard]

Saku Ytti wrote:
> Member may puke L2 loop to IXP, you must have some channel to deal
> with your customers.

First, mac filters.  Second, if someone l2 loops and it causes problems
because of hardware failure on our side, we reserve the right to pull
connectivity:

https://www.inex.ie/technical/maintenance

> In the case of emergencies, INEX reserves the right to perform
> critical maintenance on a 24x7x365 basis without prior notification
> to INEX members. Emergencies are defined as situations where:
[...]
> - member port misconfiguration or hardware/software bug causes loss of
> service or down-time for other INEX members, in the potential
> situation where this is not prevented by INEX port security measures

Fortunately, it's only rarely that this happens.

Third, someone puking an l2 loop to the IXP is a problem which may
affect the ixp infrastructure.  This is not the case when people muck up
their MTU config.  There is a demarcation line here:  one is an IXP
problem; the other is not.

Nick

Re: Internet Exchanges supporting jumbo frames?

[Mark Tinka]

On 9/Mar/16 16:26, Kurt Kraut via NANOG wrote:

>
> Could anyone share with me Internet Exchanges you know that allow jumbo
> frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit
> from it?

NAPAfrica in South Africa support jumbo frames:

https://www.napafrica.net/

Little benefit to us since the majority of members don't run jumbo
frames. For some that do, it is unclear whether their backbones support
jumbo frames across the board.

Mark.

Re: Internet Exchanges supporting jumbo frames?

[Saku Ytti]

On 10 March 2016 at 00:01, Nick Hilliard  wrote:

> Other people would be fine with 1522 core because that suits both their
> needs and equipment limitations.  So what do you do?  Go with 9100
> because it suits you, or 9000 because that's what lots of other people
> use?  Or 4470 because of history?  Or 1522 because that enables you to
> pad on some extra headers and get 1500 payload, and works for more
> people but is too meh for others to contemplate?  Or 9000 and some slop
> because you commit to carrying 9000 payload on your network, whereas
> other people only commit to 9000 total frame size?

I don't think it's super important. IXP will do what they think is
best for the coreMTU.

> And how truly awful some equipment is that people install at IXPs?

People with awful kit are free to do edgeMTU only.

> but you haven't solved the human problem.  The IXP operator does not
> have enable on IXP participant routers.

Member may puke L2 loop to IXP, you must have some channel to deal
with your customers. If that channel fails you quarantine the VLAN or
shut down the port.
If you cannot have any communication with your members I can see how
this seems like particularly difficult problem.

-- 
  ++ytti

Re: Internet Exchanges supporting jumbo frames?

[Nick Hilliard]

Saku Ytti wrote:
> I would go for 1500B edge, and 9100B core, but that's just me.

Other people would be fine with 1522 core because that suits both their
needs and equipment limitations.  So what do you do?  Go with 9100
because it suits you, or 9000 because that's what lots of other people
use?  Or 4470 because of history?  Or 1522 because that enables you to
pad on some extra headers and get 1500 payload, and works for more
people but is too meh for others to contemplate?  Or 9000 and some slop
because you commit to carrying 9000 payload on your network, whereas
other people only commit to 9000 total frame size?

Do you understand how bad humans are at making decisions like this?

And how truly awful some equipment is that people install at IXPs?

> I've proposed automated, fully toolisable solution for IXP to verify
> customers have correct config.

but you haven't solved the human problem.  The IXP operator does not
have enable on IXP participant routers.

Nick

Re: .pro whois registry down?

[Doug Barton]

On 03/09/2016 01:24 PM, Bryan Holloway wrote:

Anyone else noticing that the .pro TLD is failing for some things, and their 
WHOIS registry appears to be unavailable?


The delegation from the root to PRO, and the PRO name servers 
themselves, seem to be working.



I appear to be able to resolve, but whois times out, and we're getting reports 
that mail isn't going through for some folks with this TLD.


The address records for whois.dotproregistry.net are missing.

Doug

Re: Internet Exchanges supporting jumbo frames?

[Saku Ytti]

On 9 March 2016 at 22:56, Nick Hilliard  wrote:

> - hardware problems

If we build everything on LCD, we'll have Internet where just HTTP/80
works on 576B. You can certainly find platform which has problems
doing else.

> - lack of interest among ixp participants outside individual pushers

They probably want faster horses.

> - lack of consensus about what MTU should be chosen

If we stop thinking of MTU as single entity and start thinking it as
edge MTU and core MTU, it becomes less important, as long as core MTU
covers overhead over edge.
I would go for 1500B edge, and 9100B core, but that's just me.

> - operational problems causing people to "temporarily disable
> connectivity until someone can take a look at it", i.e. permanently.

Vague. But ultimately this is what you will do always when issue is
not solved, sometime you just have to give up, 'ok far end is gone,
let's close this connection'.

> - additional expense in some situations

Vague. 'Sometimes something has some cost which is more than in some
other situation sometimes'.

> - the main peering lan worked fine, ie no overriding value proposition

>99% Internet users likely are happy with 576B HTTP only INET. I'm not still 
>comfortable accepting that it's only thing Internet shoudl be.

> - pmtu problems

Immaterial, it is there regardless.

> - fragile and troublesome to debug when things went wrong

I've proposed automated, fully toolisable solution for IXP to verify
customers have correct config. People who don't want to deal with
this, who don't believe in this, can peer only over edgeMTU VLAN and
have completely same situation as today.

-- 
  ++ytti

.pro whois registry down?

[Bryan Holloway]

Anyone else noticing that the .pro TLD is failing for some things, and their 
WHOIS registry appears to be unavailable?

I appear to be able to resolve, but whois times out, and we're getting reports 
that mail isn't going through for some folks with this TLD.

Re: Internet Exchanges supporting jumbo frames?

[Saku Ytti]

On 9 March 2016 at 22:28, Nick Hilliard  wrote:
> iirc, we had problems with a bunch of ios based platforms.  It worked
> fine on junos / xr platforms.  I share your surprise that this could
> even have caused a problem, but it did.

This is very poor reason to kill it for everyone, 'I recall I may have
found platform where it maybe didn't work'.

Yet, it's super common go have L3Termination - L2Aggregation - Customer.

And sell various MTU options to customers, even use the L2Aggregation
as core between two L3Termination. All of these require per
logical-interface L3 MTU, while L2 MTU is usually set to max.
>From Cisco, I've done this at least on 720x, 7301, 7304 NPE/NSE, 7600,
6500, GSR, CRS-1, ASR1k, ASR9k, 2600, 3600, ASR9k, probably some
others too.

-- 
  ++ytti

Re: Internet Exchanges supporting jumbo frames?

[Mikael Abrahamsson]

On Wed, 9 Mar 2016, Nick Hilliard wrote:

Many IXPs have either looked at or attempted to build jumbo peering 
lans.  You can see how well they worked out by looking at the number of 
successful deployments.  The reason for this tiny number isn't due to 
lack of effort on the part of the ixp operators.


I believe all IXP operators should offer higher MTU vlans, so that the 
ISPs who are interested can use them. If individual ISPs are not 
interested, then they don't have to use it. It's available if they gain 
interest.


The whole point of an IX is to be a market place where interested parties 
can talk to each other. The IXP should not limit (to reasonable extent) 
what services the ISPs can run across the infrastructure. If two ISPs need 
higher than 1500 MTU between them, then forcing them to connect outside of 
the IXP L2 infrastructure doesn't make any sense to me, when it's fairly 
easy for the IXP to offer this service.


The IXPs who offer "private lans" between two parties, do they generally 
limit these as well to 1500 L3 MTU?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Internet Exchanges supporting jumbo frames?

[Nick Hilliard]

Saku Ytti wrote:
> It works and has worked 2 decades in real IXP.

If you're referring to Netnod, this started out as a fddi platform with
a native max frame size of 4470.  Maintaining something which already
exists is not nearly as difficult as starting something from scratch and
trying to reach a critical mass.  In the case of INEX and several other
IXPs, it failed because of (in no particular order):

- hardware problems
- lack of interest among ixp participants outside individual pushers
- lack of consensus about what MTU should be chosen
- operational problems causing people to "temporarily disable
connectivity until someone can take a look at it", i.e. permanently.
- additional expense in some situations
- the main peering lan worked fine, ie no overriding value proposition
- pmtu problems
- fragile and troublesome to debug when things went wrong

>  ++ytti, boy who didn't cry wolf

Many IXPs have either looked at or attempted to build jumbo peering
lans.  You can see how well they worked out by looking at the number of
successful deployments.  The reason for this tiny number isn't due to
lack of effort on the part of the ixp operators.

Nick, boy who did the jumbo vlan thing and got the t shirt

Re: Internet Exchanges supporting jumbo frames?

[Nick Hilliard]

Mikael Abrahamsson wrote:
> On all platforms I've configured and connected to an IXP, they would all
> be configured by setting max L2 MTU on the main interface, and then you
> configure whatever needed IPv4 and IPv6 L3 MTU on the subinterface.

iirc, we had problems with a bunch of ios based platforms.  It worked
fine on junos / xr platforms.  I share your surprise that this could
even have caused a problem, but it did.

Nick

Re: Internet Exchanges supporting jumbo frames?

[Mikael Abrahamsson]

On Wed, 9 Mar 2016, Nick Hilliard wrote:


For example, many types of hardware don't allow you to specify a
different MTU for different .1q tags on the same physical interface.


What hardware types typically connected to an IXP would that be, where 
this would be a problem?


On all platforms I've configured and connected to an IXP, they would all 
be configured by setting max L2 MTU on the main interface, and then you 
configure whatever needed IPv4 and IPv6 L3 MTU on the subinterface.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Internet Exchanges supporting jumbo frames?

[William Herrin]

On Wed, Mar 9, 2016 at 9:50 AM, Kurt Kraut via NANOG  wrote:
> Thank you for replying so quickly. I don't see why the consensus for an MTU
> must be reached. IPv6 Path MTU Discovery would handle it by itself,
> wouldn't it? If one participant supports 9k and another 4k, the traffic
> between them would be at 4k with no manual intervention. If to participants
> adopts 9k, hooray, it will be 9k thanks do PMTUD.
>
> Am I missing something?

Hi Kurt,

As far as I know, there is no "discovery" of MTU on an Ethernet LAN.
That's Link MTU, not Path MTU. Unhappy things happen when the
participants don't agree exactly about the layer-2 MTU. It's a layer 2
thing; IPv6 and layer 3 pmtud can't discover that layer 2 problem.
Pmtud discovers when a link *reports* that the MTU is too small, not
when packets vanish as a result of a layer 2 error. As a result,
non-1500 byte MTUs in a network with multiple connected organizations
can be brittle: human beings are bad at each configuring their router
to exactly the same non-standard configuration as everybody else.

Other than that one problem, high MTUs at an IXP are a good thing, not
a bad one. Because IPv4 path MTU discovery is so badly broken, it's
desirable to maintain a minimum MTU of 1500 bytes across the core,
even as packets travel through tunnels, VPNs and other layered
structures that add bytes to the payload.

Greater than 1500 byte MTUs to the customer, on the other hand, are a
bad thing. The aggravate the problems with PMTUd.

Regards,
Bill Herrin


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

Re: Internet Exchanges supporting jumbo frames?

[Saku Ytti]

On 9 March 2016 at 21:46, Nick Hilliard  wrote:
> I've spent a good deal of time and effort trying to get a jumbo peering
> vlan to work and it didn't work for the reasons that I've mentioned, and
> others.

It works and has worked 2 decades in real IXP.

-- 
  ++ytti, boy who didn't cry wolf

Re: Internet Exchanges supporting jumbo frames?

[Nick Hilliard]

Saku Ytti wrote:
> If customer does not react, put it on quarantine VLAN. This can be
> automated too. Wrong MTU => open internal case, contact customers
> email, no customer response in N days, quarantine VLAN.

... and then the customer will leave the service down because it the
primary peering lan works fine and they couldn't be bothered fixing
jumbo lan connectivity because the neteng who wanted the 9000 byte mtu
connectivity in the first place got distracted by a squirrel or left the
company or was too busy doing other things.

> work, but it's very difficult to actually know without trying what
> works and what does.

I've spent a good deal of time and effort trying to get a jumbo peering
vlan to work and it didn't work for the reasons that I've mentioned, and
others.

For example, many types of hardware don't allow you to specify a
different MTU for different .1q tags on the same physical interface.
This means that if you want a connection to a jumbo MTU vlan and a
standard mtu vlan, you needed two separate connections into the IXP.  At
that point, the ixp participant is unlikely to want to bother because
there's no cost:value justification in getting the second connection.

Don't get me wrong: jumbo MTU IXPs are a great idea in theory.  In
practice, they cause an inordinate amount of pain.

Nick

Re: Internet Exchanges supporting jumbo frames?

[Aris Lambrianidis]

Saku Ytti wrote:
>
> If customer does not react, put it on quarantine VLAN. This can be
> automated too. Wrong MTU => open internal case, contact customers
> email, no customer response in N days, quarantine VLAN.
>
> Even the most outrageous success stories in the world, majority of the
> people would have said before attempting that it won't work, because
> that is safe and easy. And usually they are right, most things don't
> work, but it's very difficult to actually know without trying what
> works and what does.
> Luckily we have actual IXPs running big and small VLAN MTUs, even
> without this monitoring capability, and it Internet still works.
>
Imo, there is not enough value for an IXP to do such monitoring,
especially assuming we agree
on Richard Steenbergen's conclusion in his presentation.

Promoting that kind of monitoring  as a differentiator will surely help
adding an extra bullet
point on marketing material, but will be a trivial part in the decision
process of a potential customer.

--Aris

Re: Internet Exchanges supporting jumbo frames?

[Saku Ytti]

On 9 March 2016 at 20:59, Nick Hilliard  wrote:

> There is a critical difference between these two situations. In the case of 
> an arp sponge, the ixp operator has control of both the polling and the 
> workaround. In the case of mtu management they would only have control of the 
> polling, not the remediation. The point I was making is that an ixp operator 
> can only control their own infrastructure. Once it's someone else's 
> infrastructure, all you can do is make polite suggestions.

If customer does not react, put it on quarantine VLAN. This can be
automated too. Wrong MTU => open internal case, contact customers
email, no customer response in N days, quarantine VLAN.

Even the most outrageous success stories in the world, majority of the
people would have said before attempting that it won't work, because
that is safe and easy. And usually they are right, most things don't
work, but it's very difficult to actually know without trying what
works and what does.
Luckily we have actual IXPs running big and small VLAN MTUs, even
without this monitoring capability, and it Internet still works.

-- 
  ++ytti

Re: Internet Exchanges supporting jumbo frames?

[Nick Hilliard]

On 9 Mar 2016, at 18:29, Saku Ytti  wrote:
> It's not a novel idea, IXPs already do active polling, even ARP
> sponges. In a competitive market, hopefully customers will choose the
> IXP operator who knows how to ensure minimal pain for the customers.

There is a critical difference between these two situations. In the case of an 
arp sponge, the ixp operator has control of both the polling and the 
workaround. In the case of mtu management they would only have control of the 
polling, not the remediation. The point I was making is that an ixp operator 
can only control their own infrastructure. Once it's someone else's 
infrastructure, all you can do is make polite suggestions.

Nick

Re: remote serial console (IP to Serial)

[bzs]

For a long time I used an Equinox SST which was a PCI card and a
plugboard of (daisy-chain-able up to 128) 16 x RJ-45 serial ports. It
was handy in one machine room, usually a Cat-5 RJ-45 cable with a
D-connector was all that was needed.

Unfortunately the Linux driver seems to have disappeared into the
sands of time though it would work with something like SuSE 9.x, maybe
10.x. That is, 2.4 maybe 2.6 kernels, I don't think SuSE mattered but
that's what I used.

With the driver and hardware installed it would present as a bunch of
/dev/ttyQ?? devices.

I'd use an xterm workalike 'eterm' which could take a device on the
command line and it'd work. I think screen could also work but firing
up separate terminal windows for different ports was convenient. And
eterm was rather pretty, not sure what happened to it, but you could
probably use kermit or cu etc in a pinch with enough magic.

I'm curious if anyone still uses this and perhaps got it working with
more modern kernels? I believe it's mentioned in the newer kernel
build configuration (make xconfig, whatever) but doesn't work.

Not a big deal to install an old OS on a spare machine. Or perhaps
even in a virtual machine with some sort of device passthru? Never
looked into that.

No idea where you'd find the hardware but it was a neat device and if
you can't find their driver stuff I could send it to you as a tarball
tho I think it's still up on whatever Equinox became. Ok here it is I
noted it:

  http://www.connectivity.avocent.com/drivers/superserial/eqnx_4.12d.asp

So you'd just login to that machine and fire up windows to access the
Equinox/SST serial ports (to answer the remote part of the question.)

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: remote serial console (IP to Serial)

[Owen DeLong]

If you're going to go that route, a PI is a much cheaper moboard to build on. 
Also consider the Pine64 (cheaper and more powerful than the PI) 

> On Mar 8, 2016, at 21:36, Doug McIntyre  wrote:
> 
>> On Tue, Mar 08, 2016 at 10:45:30AM -0900, Royce Williams wrote:
>>> On Tue, Mar 8, 2016 at 10:21 AM, Hugo Slabbert  wrote:
>>> I'm surprised no one's mentioned freetserv[1] yet.  I haven't used them so
>>> don't consider this an endorsement, but on the surface it looks to be a
>>> good balance of "open / DIY" and "supportable".
> ..
>> This is great!  A mainstream, patchable OS -- not locked into a half-baked
>> OS or roll-your-own-TCP-stack hell I've seen in some remote serial and
>> power devices.
> ..
> 
> Yes, instead of a hacked together hardwareboard, or appliance with
> firmware that never gets updated stuck in SSH v1 days (old Cisco?)..
> Freetserv looks interesting, but very costly once you add up the BOM. 
> 
> I'd get something like a 1U ATOM server ($120 eBay) with small SSD
> ($18).  Runup your favorite FOSS OS, and conserver.  For more than the
> single real serialport, you can most likely fit a USB hub inside
> the case still, and hang a number of USB serial dongles off.
> 
> Rackmountable, maintainable, and conserver works great.
> 
> 

Re: Internet Exchanges supporting jumbo frames?

[Saku Ytti]

On 9 March 2016 at 20:25, Nick Hilliard  wrote:

> any ixp configuration which requires active polling to ensure correct
> configuration is doomed to failure.  You are completely overestimating
> human nature if you believe that the IXP operator can make this work by
> harassing people into configuring the correct mtu, even if the data is
> clear that their systems are misconfigured.

It's not a novel idea, IXPs already do active polling, even ARP
sponges. In a competitive market, hopefully customers will choose the
IXP operator who knows how to ensure minimal pain for the customers.

-- 
  ++ytti

Re: Internet Exchanges supporting jumbo frames?

[Nick Hilliard]

Saku Ytti wrote:
> I'm suggesting IXP has active poller which detects customer MTU misconfigs.

any ixp configuration which requires active polling to ensure correct
configuration is doomed to failure.  You are completely overestimating
human nature if you believe that the IXP operator can make this work by
harassing people into configuring the correct mtu, even if the data is
clear that their systems are misconfigured.

Nick

Re: Internet Exchanges supporting jumbo frames?

[Saku Ytti]

On 9 March 2016 at 20:14, Nick Hilliard  wrote:
> you're recommending that routers at IXPs do inflight fragmentation?

I'm suggesting IXP has active poller which detects customer MTU misconfigs.

-- 
  ++ytti

re: Cogent - Google - HE Fun

[Nick Olsen]

This doesn't surprise me. Cogent get's into Peering Chicken from time to 
time. Just like Cogent and HE still have no IPv6 peering. *Insert picture 
of cake here*.
  
 Can also confirm I'm not learning  AS15169 routes via Cogent v6.

Nick Olsen
Network Operations  (855) FLSPEED  x106

  


 From: "Dennis Burgess" 
Sent: Wednesday, March 09, 2016 11:12 AM
To: "North American Network Operators' Group" 
Subject: Cogent - Google - HE Fun   
I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at 
all. I was told google pulled all of their peering with Cogent? If I bring 
up a SIT tunnel with HE, I get the prefixes but at horrible speed and 
latency .. anyone else?

[DennisBurgessSignature]
www.linktechs.net - 314-735-0270 x103 - 
dmburg...@linktechs.net

 

Re: Internet Exchanges supporting jumbo frames?

[Nick Hilliard]

Mikael Abrahamsson wrote:
> I have many times ping:ed with 1 byte packets on a device that has
> "ip mtu 9000" configured on it, so it sends out two fragments, one being
> 9000, the other one around 1100 bytes, only to get back a stream of
> fragments, none of them larger than 1500 bytes.

here's some data on INEX from a server interface with 9000 mtu.  fping
has 40 bytes overhead:

> # wc -l ixp-router-addresses.txt
>   85 ixp-router-addresses.txt
> # fping -b 1460 < ixp-router-addresses.txt | grep -c unreachable
> 0
> # fping -b 1500 < ixp-router-addresses.txt | grep -c unreachable
> 10
> # fping -b 5000 < ixp-router-addresses.txt | grep -c unreachable
> 11
> # fping -b 8960 < ixp-router-addresses.txt | grep -c unreachable
> 12

Out of interest, there were 5 different vendors in the output, according
to the MAC addresses returned.Some of this may be caused by
inappropriate icmp filtering on the routers, but the point is that it
would be unwise to depend on routers doing the right thing here. If
you're going to have a jumbo mtu vlan at an IXP, the VLAN needs to be a
hard specification, not an aspiration with any variance.

Nick

Re: remote serial console (IP to Serial)

[Lyndon Nerenberg]

I'd get something like a 1U ATOM server ($120 eBay) with small SSD
($18).  Runup your favorite FOSS OS, and conserver.  For more than the
single real serialport, you can most likely fit a USB hub inside
the case still, and hang a number of USB serial dongles off.


We use Raspberry Pi 2s with single- and 8-port USB serial dongles. Works 
like a charm, especially with tmux installed.


--lyndon

Re: Internet Exchanges supporting jumbo frames?

[Nick Hilliard]

Saku Ytti wrote:
> Poller in the IXP has too large MTU, it tries to send ping packets
> with max_size+1, if they work, customer has too large MTU. Also it
> tries to send max_size, if it does not work, customer has too small
> MTU. As icing on top, it tries to send max_size+1 but fragments it to
> max_size and 1, and sees what comes back.

you're recommending that routers at IXPs do inflight fragmentation?

Nick

Re: AW: Cogent - Google - HE Fun

[Jon Lewis]

In other words, GOOG is playing peering chicken with Cogent for IPv6.  I'm 
not surprised.  I suggested it during talks with GOOG roughly 10 years 
ago...not saying I had any influence...I'm pretty sure I did not. :)


GOOG wants Cogent to peer.  Cogent wants GOOG to pay for transit (from 
them or someone else to get to Cogent).  If you're well peered / 
multihomed, it's not much of an issue.  If you're a single-homed Cogent 
customer, you should complain to Cogent that they're not providing full 
IPv6 connectivity.


On Wed, 9 Mar 2016, Jürgen Jaritsch wrote:


Hi,

mail from Cogent:



Dear Cogent Customer,

Thank you for contacting Cogent Customer Support for information about the 
Google IPv6 addresses you are unable to reach.

Google uses transit providers to announce their IPv4 routes to Cogent.

At this time however, Google has chosen not to announce their IPv6 routes to 
Cogent through transit providers.

We apologize for any inconvenience this may cause you and will notify you if 
there is an update to the situation.


Mail from Google:



Unfortunately it seems that your transit provider does not have IPv6 
connectivity with Google. We suggest you ask your transit provider to look for 
alternatives to interconnect with us.

Google maintains an open interconnect policy for IPv6 and welcomes any network 
to peer with us for access via IPv6 (and IPv4). For those networks that aren't 
able, or chose not to peer with Google via IPv6, they are able to reach us 
through any of a large number of transit providers.

For more information in how to peer directly with Google please visit 
https://peering.google.com


best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jjarit...@anexia-it.com
Web: http://www.anexia-it.com



Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601


-Ursprüngliche Nachricht-
Von: NANOG [mailto:nanog-bounces+jjaritsch=anexia-it@nanog.org] Im Auftrag 
von Dennis Burgess
Gesendet: Mittwoch, 09. März 2016 17:01
An: North American Network Operators' Group
Betreff: Cogent - Google - HE Fun

I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. 
I was told google pulled all of their peering with Cogent?   If I bring up a 
SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. 
anyone else?

[DennisBurgessSignature]
www.linktechs.net - 314-735-0270 x103 - 
dmburg...@linktechs.net




--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Internet Exchanges supporting jumbo frames?

[Hugo Slabbert]

On Wed 2016-Mar-09 15:32:32 +0100, Grzegorz Janoszka  
wrote:


On 09/03/2016 15:26, Kurt Kraut via NANOG wrote:

Could anyone share with me Internet Exchanges you know that allow jumbo
frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit
from it?


Netnod does it in separate vlan's.

--
Grzegorz Janoszka


Same for the SIX.

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: Internet Exchanges supporting jumbo frames?

[joel jaeggli]

On 3/9/16 7:58 AM, Mikael Abrahamsson wrote:
> On Wed, 9 Mar 2016, Nick Hilliard wrote:
> 
>> used.  Some will want 9000, some 9200, others 4470 and some people
> 
> I have a strong opinion for jumboframes=9180bytes (IPv4/IPv6 MTU),
> partly because there are two standards referencing this size (RFC 1209
> and 1626), and also because all major core router vendors support this
> size now that Juniper has decided (after some pushing) to start
> supporting it in more recent software on all their major platforms
> (before that they had too low L2 MTU to be able to support 9180 L3 MTU).
> 
> In order to deploy this to end systems, I however thing we're going to
> need something like
> https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-04 to make this
> work on mixed-MTU LANs. The whole thing about PMTUD blackhole detection
> is also going to be needed, so hosts try lower PMTU in case larger
> packets are dropped because of L2 misconfiguration in networks.
> 
> With IPv6 we have the chance to make PMTUD work properly and also have

The prospects for that seem relatively dire. of course whats being
discussed here is the mixed L2 case, where the device will probably not
sent icmp6 ptb anyway but rather simply discard the packet as a giant.

> PMTU blackhole detection implemented in all hosts. IPv4 is lost cause in
> my opinion (although it's strange how many hosts that seem to get away
> with 1492 (or is it 1496) MTU because they're using PPPoE).

if your adv_mss is set accordingly you can get away with
 a lot.
> 




signature.asc
Description: OpenPGP digital signature

Re: Internet Exchanges supporting jumbo frames?

[Saku Ytti]

On 9 March 2016 at 16:34, Job Snijders  wrote:
> 
> https://www.nanog.org/sites/default/files/wednesday.general.steenbergen.antijumbo.pdf

IXP can verify if MTU is too large or too small with active poller.

Poller in the IXP has too large MTU, it tries to send ping packets
with max_size+1, if they work, customer has too large MTU. Also it
tries to send max_size, if it does not work, customer has too small
MTU. As icing on top, it tries to send max_size+1 but fragments it to
max_size and 1, and sees what comes back.

IXP is only interface in whole of Internet which collapses MTU to
1500B, private peers regularly have higher MTU, ~everyone runs core at
higher MTU.

I think it's crucial that we stop thinking MTU as single thing, we
should separate edge MTU and core MTU, that is how we already think
and provision when we think about our own network. Then question
becomes, is IXP edge or core? I would say run core MTU in IXP, so edge
MTU can be tunneled without fragmentation over it.
IXP can offer edgeMTU and coreMTU VLANs, so that people who are
religiously against it, can only peer in edgeMTU VLAN.

-- 
  ++ytti

Re: Internet Exchanges supporting jumbo frames?

[Mikael Abrahamsson]

On Wed, 9 Mar 2016, David Bass wrote:


Could you do the same with a 1501 byte packet?


I have many times ping:ed with 1 byte packets on a device that has "ip 
mtu 9000" configured on it, so it sends out two fragments, one being 9000, 
the other one around 1100 bytes, only to get back a stream of fragments, 
none of them larger than 1500 bytes.


MTU and MRU are two different things.

Regarding jumbo usage, the biggest immediate benefit I can see would be if 
two ISPs want to exchange tunneled traffic with each other, even if the 
customer access is 1500, there is definitely benefit in being able to slap 
an L3 tunnel header on that packet, send it as ~1550 bytes to the other 
ISP, and then they take off the header again, without having to handle 
tunnel packet fragments (which tend to be quite resource intensive).


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Cogent - Google - HE Fun

[Mike Hammett]

http://mailman.nanog.org/pipermail/nanog/2016-February/084147.html 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Dennis Burgess"  
To: "North American Network Operators' Group"  
Sent: Wednesday, March 9, 2016 10:01:12 AM 
Subject: Cogent - Google - HE Fun 

I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. 
I was told google pulled all of their peering with Cogent? If I bring up a SIT 
tunnel with HE, I get the prefixes but at horrible speed and latency .. anyone 
else? 

[DennisBurgessSignature] 
www.linktechs.net - 314-735-0270 x103 - 
dmburg...@linktechs.net 

AW: Cogent - Google - HE Fun

[Jürgen Jaritsch]

Hi,

mail from Cogent: 

Dear Cogent Customer,

Thank you for contacting Cogent Customer Support for information about the 
Google IPv6 addresses you are unable to reach.

Google uses transit providers to announce their IPv4 routes to Cogent.

At this time however, Google has chosen not to announce their IPv6 routes to 
Cogent through transit providers.

We apologize for any inconvenience this may cause you and will notify you if 
there is an update to the situation.


Mail from Google:

Unfortunately it seems that your transit provider does not have IPv6 
connectivity with Google. We suggest you ask your transit provider to look for 
alternatives to interconnect with us.

Google maintains an open interconnect policy for IPv6 and welcomes any network 
to peer with us for access via IPv6 (and IPv4). For those networks that aren't 
able, or chose not to peer with Google via IPv6, they are able to reach us 
through any of a large number of transit providers.

For more information in how to peer directly with Google please visit 
https://peering.google.com


best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jjarit...@anexia-it.com 
Web: http://www.anexia-it.com 



Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601


-Ursprüngliche Nachricht-
Von: NANOG [mailto:nanog-bounces+jjaritsch=anexia-it@nanog.org] Im Auftrag 
von Dennis Burgess
Gesendet: Mittwoch, 09. März 2016 17:01
An: North American Network Operators' Group
Betreff: Cogent - Google - HE Fun

I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. 
I was told google pulled all of their peering with Cogent?   If I bring up a 
SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. 
anyone else?

[DennisBurgessSignature]
www.linktechs.net - 314-735-0270 x103 - 
dmburg...@linktechs.net

Re: Internet Exchanges supporting jumbo frames?

[David Bass]

Could you do the same with a 1501 byte packet?

> On Mar 9, 2016, at 10:51 AM, Nick Hilliard  wrote:
> 
> Kurt Kraut wrote:
>> Thank you for replying so quickly. I don't see why the consensus for an
>> MTU must be reached. IPv6 Path MTU Discovery would handle it by itself,
>> wouldn't it? If one participant supports 9k and another 4k, the traffic
>> between them would be at 4k with no manual intervention. If to
>> participants adopts 9k, hooray, it will be 9k thanks do PMTUD.
>> 
>> Am I missing something?
> 
> for starters, if you send a 9001 byte packet to a router which has its
> interface MTU configured to be 9000 bytes, the packet will be
> blackholed, not rejected with a PTB.
> 
> Even if it weren't, how many icmp PTB packets per second would a router
> be happy to generate before rate limiters kicked in?  Once someone
> malicious works that out, they can send that number of crafted packets
> per second through the IXP, thereby creating a denial of service situation.
> 
> There are many other problems, such as pmtud not working properly in the
> general case.
> 
> Nick
> 

Cogent - Google - HE Fun

[Dennis Burgess]

I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. 
I was told google pulled all of their peering with Cogent?   If I bring up a 
SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. 
anyone else?

[DennisBurgessSignature]
www.linktechs.net - 314-735-0270 x103 - 
dmburg...@linktechs.net

Re: Internet Exchanges supporting jumbo frames?

[Mikael Abrahamsson]

On Wed, 9 Mar 2016, Nick Hilliard wrote:


interface MTU configured to be 9000 bytes, the packet will be
blackholed, not rejected with a PTB.


That is only true if the router/host sets MRU=MTU. That is definitely not 
always the case.

Re: Internet Exchanges supporting jumbo frames?

[Mikael Abrahamsson]

On Wed, 9 Mar 2016, Nick Hilliard wrote:


used.  Some will want 9000, some 9200, others 4470 and some people


I have a strong opinion for jumboframes=9180bytes (IPv4/IPv6 MTU), partly 
because there are two standards referencing this size (RFC 1209 and 1626), 
and also because all major core router vendors support this size now that 
Juniper has decided (after some pushing) to start supporting it in more 
recent software on all their major platforms (before that they had too low 
L2 MTU to be able to support 9180 L3 MTU).


In order to deploy this to end systems, I however thing we're going to 
need something like 
https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-04 to make this 
work on mixed-MTU LANs. The whole thing about PMTUD blackhole detection is 
also going to be needed, so hosts try lower PMTU in case larger packets 
are dropped because of L2 misconfiguration in networks.


With IPv6 we have the chance to make PMTUD work properly and also have 
PMTU blackhole detection implemented in all hosts. IPv4 is lost cause in 
my opinion (although it's strange how many hosts that seem to get away 
with 1492 (or is it 1496) MTU because they're using PPPoE).


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Internet Exchanges supporting jumbo frames?

[Nick Hilliard]

Kurt Kraut wrote:
> Thank you for replying so quickly. I don't see why the consensus for an
> MTU must be reached. IPv6 Path MTU Discovery would handle it by itself,
> wouldn't it? If one participant supports 9k and another 4k, the traffic
> between them would be at 4k with no manual intervention. If to
> participants adopts 9k, hooray, it will be 9k thanks do PMTUD.
> 
> Am I missing something?

for starters, if you send a 9001 byte packet to a router which has its
interface MTU configured to be 9000 bytes, the packet will be
blackholed, not rejected with a PTB.

Even if it weren't, how many icmp PTB packets per second would a router
be happy to generate before rate limiters kicked in?  Once someone
malicious works that out, they can send that number of crafted packets
per second through the IXP, thereby creating a denial of service situation.

There are many other problems, such as pmtud not working properly in the
general case.

Nick

Re: Internet Exchanges supporting jumbo frames?

[Stefan Neufeind]

There is no way to avoid breaking MTU for IPv4 but use PMTUD for IPv6,
is there? Meaning to stick to 1500 for IPv4 and use something larger for
IPv6?


Kind regards,
 Stefan

On 09.03.2016 15:59, Kurt Kraut via NANOG wrote:
> Hi Mike,
> 
> The adoption of jumbo frames in a IXP doesn't brake IPv4. For an ISP, their
> corporate and residencial users would still use 1,5k. For datacenters,
> their local switches and servers are still set to 1,5k MTU. Nothing will
> brake.  When needed, if needed and when supported, from a specific server,
> from a specific switch, to a specific router it can raise the MTU up to the
> max MTU supported by IXP if the operator know the destination also supports
> it, like in the disaster recovery example I gave. For IPv6, the best MTU
> will be detected and used with no operational effort.
> 
> For those who doesn't care about it, an IXP adopting jumbo frames wouldn't
> demand any kind of change for their network. They just set their interfaces
> to 1500 bytes and go rest. For those who care like me can take benefit from
> it and for that reason I see no reason for not adopting it.
> 
> 
> Best regards,
> 
> Kurt Kraut
> 
> 2016-03-09 11:53 GMT-03:00 Mike Hammett :
> 
>> Maybe breaking v4 in the process?
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>>
>>
>> Midwest Internet Exchange
>> http://www.midwest-ix.com
>>
>>
>> - Original Message -
>>
>> From: "Kurt Kraut via NANOG" 
>> To: "Nick Hilliard" 
>> Cc: "NANOG list" 
>> Sent: Wednesday, March 9, 2016 8:50:23 AM
>> Subject: Re: Internet Exchanges supporting jumbo frames?
>>
>> 2016-03-09 11:45 GMT-03:00 Nick Hilliard :
>>
>>> this has been tried before at many ixps. No matter how good an idea it
>>> sounds like, most organisations are welded hard to the idea of a 1500
>>> byte mtu. Even for those who use larger MTUs on their networks, you're
>>> likely to find that there is no agreement on the mtu that should be
>>> used. Some will want 9000, some 9200, others 4470 and some people
>>> will complain that they have some old device somewhere that doesn't
>>> support anything more than 1522, and could everyone kindly agree to that
>>> instead.
>>>
>>
>>
>>
>> Hi Nick,
>>
>>
>> Thank you for replying so quickly. I don't see why the consensus for an MTU
>> must be reached. IPv6 Path MTU Discovery would handle it by itself,
>> wouldn't it? If one participant supports 9k and another 4k, the traffic
>> between them would be at 4k with no manual intervention. If to participants
>> adopts 9k, hooray, it will be 9k thanks do PMTUD.
>>
>> Am I missing something?
>>
>>
>> Best regards,
>>
>>
>> Kurt Kraut

Re: Internet Exchanges supporting jumbo frames?

[Kurt Kraut via NANOG]

Hi Mike,



The adoption of jumbo frames in a IXP doesn't brake IPv4. For an ISP, their
corporate and residencial users would still use 1,5k. For datacenters,
their local switches and servers are still set to 1,5k MTU. Nothing will
brake.  When needed, if needed and when supported, from a specific server,
from a specific switch, to a specific router it can raise the MTU up to the
max MTU supported by IXP if the operator know the destination also supports
it, like in the disaster recovery example I gave. For IPv6, the best MTU
will be detected and used with no operational effort.

For those who doesn't care about it, an IXP adopting jumbo frames wouldn't
demand any kind of change for their network. They just set their interfaces
to 1500 bytes and go rest. For those who care like me can take benefit from
it and for that reason I see no reason for not adopting it.


Best regards,

Kurt Kraut

2016-03-09 11:53 GMT-03:00 Mike Hammett :

> Maybe breaking v4 in the process?
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
> - Original Message -
>
> From: "Kurt Kraut via NANOG" 
> To: "Nick Hilliard" 
> Cc: "NANOG list" 
> Sent: Wednesday, March 9, 2016 8:50:23 AM
> Subject: Re: Internet Exchanges supporting jumbo frames?
>
> 2016-03-09 11:45 GMT-03:00 Nick Hilliard :
>
> > this has been tried before at many ixps. No matter how good an idea it
> > sounds like, most organisations are welded hard to the idea of a 1500
> > byte mtu. Even for those who use larger MTUs on their networks, you're
> > likely to find that there is no agreement on the mtu that should be
> > used. Some will want 9000, some 9200, others 4470 and some people
> > will complain that they have some old device somewhere that doesn't
> > support anything more than 1522, and could everyone kindly agree to that
> > instead.
> >
>
>
>
> Hi Nick,
>
>
> Thank you for replying so quickly. I don't see why the consensus for an MTU
> must be reached. IPv6 Path MTU Discovery would handle it by itself,
> wouldn't it? If one participant supports 9k and another 4k, the traffic
> between them would be at 4k with no manual intervention. If to participants
> adopts 9k, hooray, it will be 9k thanks do PMTUD.
>
> Am I missing something?
>
>
> Best regards,
>
>
> Kurt Kraut
>
>

Re: Internet Exchanges supporting jumbo frames?

[Mike Hammett]

Maybe breaking v4 in the process? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Kurt Kraut via NANOG"  
To: "Nick Hilliard"  
Cc: "NANOG list"  
Sent: Wednesday, March 9, 2016 8:50:23 AM 
Subject: Re: Internet Exchanges supporting jumbo frames? 

2016-03-09 11:45 GMT-03:00 Nick Hilliard : 

> this has been tried before at many ixps. No matter how good an idea it 
> sounds like, most organisations are welded hard to the idea of a 1500 
> byte mtu. Even for those who use larger MTUs on their networks, you're 
> likely to find that there is no agreement on the mtu that should be 
> used. Some will want 9000, some 9200, others 4470 and some people 
> will complain that they have some old device somewhere that doesn't 
> support anything more than 1522, and could everyone kindly agree to that 
> instead. 
> 



Hi Nick, 


Thank you for replying so quickly. I don't see why the consensus for an MTU 
must be reached. IPv6 Path MTU Discovery would handle it by itself, 
wouldn't it? If one participant supports 9k and another 4k, the traffic 
between them would be at 4k with no manual intervention. If to participants 
adopts 9k, hooray, it will be 9k thanks do PMTUD. 

Am I missing something? 


Best regards, 


Kurt Kraut 

Re: Internet Exchanges supporting jumbo frames?

[Kurt Kraut via NANOG]

2016-03-09 11:45 GMT-03:00 Nick Hilliard :

> this has been tried before at many ixps.  No matter how good an idea it
> sounds like, most organisations are welded hard to the idea of a 1500
> byte mtu.  Even for those who use larger MTUs on their networks, you're
> likely to find that there is no agreement on the mtu that should be
> used.  Some will want 9000, some 9200, others 4470 and some people
> will complain that they have some old device somewhere that doesn't
> support anything more than 1522, and could everyone kindly agree to that
> instead.
>



Hi Nick,


Thank you for replying so quickly. I don't see why the consensus for an MTU
must be reached. IPv6 Path MTU Discovery would handle it by itself,
wouldn't it? If one participant supports 9k and another 4k, the traffic
between them would be at 4k with no manual intervention. If to participants
adopts 9k, hooray, it will be 9k thanks do PMTUD.

Am I missing something?


Best regards,


Kurt Kraut

Re: Internet Exchanges supporting jumbo frames?

[Nick Hilliard]

Kurt Kraut via NANOG wrote:
> I'm trying to convince my local Internet Exchange location (and it is not
> small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames.

this has been tried before at many ixps.  No matter how good an idea it
sounds like, most organisations are welded hard to the idea of a 1500
byte mtu.  Even for those who use larger MTUs on their networks, you're
likely to find that there is no agreement on the mtu that should be
used.  Some will want 9000, some 9200, others 4470 and some people
will complain that they have some old device somewhere that doesn't
support anything more than 1522, and could everyone kindly agree to that
instead.

Meanwhile, if anyone gets the larger MTU wrong anywhere on their
network, packets will be blackholed and customers will end up unhappy.
Management will demand that the IXP jumbo service is disconnected until
the root cause is fixed, or worse still, will blame the IXP for some
mumble relating to how things worked better before enabling jumbo mtus.

Nick

Re: Internet Exchanges supporting jumbo frames?

[Job Snijders]

Hi Kurt,

On Wed, Mar 09, 2016 at 11:26:35AM -0300, Kurt Kraut via NANOG wrote:
> I'm trying to convince my local Internet Exchange location (and it is not
> small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames.
> For IPv6 is is hassle free, Path MTU Discovery arranges the max MTU per
> connection/destination.
> 
> For IPv4, it requires more planning. For instance, two datacenters tend to
> exchange relevant traffic because customers  with disaster recovery in mind
> (saving the same content in two different datacenters, two different
> suppliers). In most cases, these datacenters are quite far from each other,
> even in different countries. In this context, jumbo frames would allow max
> speed even the latency is from a tipical international link.
> 
> Could anyone share with me Internet Exchanges you know that allow jumbo
> frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit
> from it?

You might find this presentation interesting:


https://www.nanog.org/sites/default/files/wednesday.general.steenbergen.antijumbo.pdf

The presenter argues: "Internet-wide Jumbo Frames will probably cause
infinitely more harm than good under the current technology."

Kind regards,

Job

Re: Internet Exchanges supporting jumbo frames?

[Grzegorz Janoszka]

On 09/03/2016 15:26, Kurt Kraut via NANOG wrote:

Could anyone share with me Internet Exchanges you know that allow jumbo
frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit
from it?


Netnod does it in separate vlan's.

--
Grzegorz Janoszka

Internet Exchanges supporting jumbo frames?

[Kurt Kraut via NANOG]

Hi,


I'm trying to convince my local Internet Exchange location (and it is not
small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames.
For IPv6 is is hassle free, Path MTU Discovery arranges the max MTU per
connection/destination.

For IPv4, it requires more planning. For instance, two datacenters tend to
exchange relevant traffic because customers  with disaster recovery in mind
(saving the same content in two different datacenters, two different
suppliers). In most cases, these datacenters are quite far from each other,
even in different countries. In this context, jumbo frames would allow max
speed even the latency is from a tipical international link.

Could anyone share with me Internet Exchanges you know that allow jumbo
frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit
from it?


Best regards,


Kurt Kraut

Re: mrtg alternative

[Alain Hebert]

Hi,

Cacti works... Biggest case I know, ~180 devices.  A few issues with
THold plugin but nothing that can't be fixed.

And they are working on a new release (available thru github) which
include most of the useful plugins.

-
Alain Hebertaheb...@pubnix.net   
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 02/27/16 16:12, Rafael Ganascim wrote:
> I like cacti:
>
> http://www.cacti.net
>
>
>
> 2016-02-26 20:18 GMT-03:00 Baldur Norddahl :
>
>> Hi
>>
>> I am currently using MRTG and RRD to make traffic graphs. I am searching
>> for more modern alternatives that allows the user to dynamically zoom and
>> scroll the timeline.
>>
>> Bonus points if the user can customize the graphs directly in the
>> webbrowse. For example he might be able to add or remove individual peers
>> from the graph by simply clicking a checkbox.
>>
>> What is the 2016 tool for this?
>>
>> Regards,
>>
>> Baldur
>>

Re: remote serial console (IP to Serial)

[Andrew Latham]

+1 on the Lantronix Spider as it is an awesome tool but Lantronix make
devices for very small rollouts also,
http://www.lantronix.com/products/eds1100-eds2100/#tab-features might be
great for only one device and
http://www.lantronix.com/products/lantronix-slb/ for site management with
remote power control might be a good option.

On Tue, Mar 8, 2016 at 12:45 PM, Andrew Fried 
wrote:

> The Lantronix Spiders work well and aren't a "do-it-yourself" option:
>
> http://www.lantronix.com/products/lantronix-spider/
>
> Andrew
>
> Andrew Fried
> andrew.fr...@gmail.com
>
> On 3/8/16 10:30 AM, greg whynott wrote:
> > Recently I have taking over the responsibility of managing about 18
> remote
> > routers and firewalls.   None of these have a console port for 'out of
> > band' access accessible today.
> >
> > Most sites has available IPs between the ISP and us (typically a /29) or
> a
> > backup DSL connection available for use. I'd like to purchase a IP to
> > Serial port device I can use for each location in the event I lock myself
> > out.   The requirement would be an Ethernet port,  a serial port,  and
> SSH.
> >
> >
> > Anyone have any recommendations on something like this?
> >
> > thanks much,
> > greg
> >
>



-- 
~ Andrew "lathama" Latham lath...@gmail.com http://lathama.net ~

Re: IPV6 planning

[Harald F. Karlsen]

On 05.03.2016 22:19, Laurent Dumont wrote:

Hiya,


Hi,


We are currently considering deploying IPv6 for a Lan event in April. We
are assigned a /48 which we then split into smaller subnets for each
player vlan. That said, what remains to be decided is how we are going
to assign the IPv6. Basically, it seems that are two ways, one SLAAC
where the endpoints uses RA to generate it's own IP and DHCPv6 which is
basically DHCP but for IPv6.

Large events like Dreamhack have used SLAAC and the feedback has been
mostly positive. Can anyone comment regarding past experiences with IPv6
gotchas and things that you don't really expect when running dual-stack
on a large-ish network?



For The Gathering 2015 we used DHCPv6 for IPv6. The reason for this was 
both tracability and security with IPv6 first-hop security 
(DHCPv6-guard, IPv6 source-guard, etc). We did the same for both wired 
and wireless clients which caused Android devices to not get IPv6 
connectivity, but it worked great on iOS devices and Windows Phones. You 
can run SLAAC for wireless clients if you want Android-devices to get 
IPv6 as well, but we wanted the same setup for all clients. IMHO it's 
really up to Google (Lorenzo?) to get their OS to support the same 
standards as everyone else does now.


We had around 5000 participants, ~160 edge switches (Juniper EX2200) and 
we had no issues with dual-stacked clients at all. First-hop security 
worked like a charm and I think more than 85% of all wired clients had 
IPv6 connectivity.


Here are a graph for the IPv4:IPv6 traffic ratio on the internet 
connection for the event (30Gbit/s total capacity):

http://bgp.no/stuff/rs1.tele-tg.png

As you can see we weren't near filling the pipe even though each client 
had 1Gbit/s wired connection and each edge switch had 3*1Gbit/s LAG 
toward the distribution layer (Juniper EX3300-VC). The IPv6 traffic 
ratio are also fairly low, but this is only natural as people attending 
these kinds of event uses a lot of services not available over IPv6 
(Valves Steam, EAs Origin, Torrents, etc).


I also see other people in the thread mentions firewalling. We didn't do 
any sort of inbound filtering. We've always provided the clients with 
public IPv4 addresses (borrowed PI-space from RIPE) and at events like 
this we feel it's up to the participants to secure their machines. We do 
still have a support crew that can assist participants with computer 
issues, but we haven't really had any issues with this since back in the 
days of WinNuke and the Blaster virus.


Feel free to ask any further questions regarding our setup either on- or 
off-list. We're all about openness and all code/config created for the 
event is publicly available online. :-)


Good luck with your event!

--
Harald

Re: remote serial console (IP to Serial)

[Saku Ytti]

On 9 March 2016 at 07:36, Doug McIntyre  wrote:

Hey,

> I'd get something like a 1U ATOM server ($120 eBay) with small SSD
> ($18).  Runup your favorite FOSS OS, and conserver.  For more than the
> single real serialport, you can most likely fit a USB hub inside
> the case still, and hang a number of USB serial dongles off.
>
> Rackmountable, maintainable, and conserver works great.

+1 on conserver. I think the greatest asset of conserver is, that it
harmonises your OOB network into single interface. You can have
different generation of OOB kit from different vendors with different
level of functionality. Yet you get all the important functions from
all of them.

a) multiplexing of console access (very nice if person has went to
lunch and you really need to access that console now)
b) persistent logging of all console output (might be that crucial
little detail which will allow vendor to solve your service request)


Before I learned about conserver I wanted to use something like
cyclades (or what ever it's name is now after two acquisitions) or
opengear, just to get those two crucial features I need. But after
conserver, I greatly prefer just using Cisco console ports, as then I
can use device which is well known and already toolised by the
organisation, and will offer all the WAN access options I need, with
encryption when needed. But not having multiplexing and persistent
logging earlier was deal-breaker, now it's immaterial.
Sure opengear and cyclades probably can do few WAN options and
probably some encryption, but operationally that would be chore to me,
compared to rocking platform I already know.

Big hand to who ever caused JNPR to add ISIS/CLNS to SRX (I think
DTAG?),  I wish someone would get JNPR to add async ports to SRX too,
so that I'd have other option than CSCO for OOB. Big thanks to CSCO
for still bringing async serial ports to CISCO4321, I know the demand
must be rather small.
-- 
  ++ytti