Mailing List Archive

"Ethernet/Token Ring/Cisco Console/whatever uses an RJ45 connector"

RJ45 defines a keyed 8P8C type connector, wired in a specific
manner, for a specific 2 wire telco service. Incompatible with the
above on several levels. "RJxx" == specific connector/wiring pattern
for specific telco applications. Non-telco uses need not apply.

One of these days I'm going to start carrying around some actual RJ45
type cables to hand out to those who ask.


"DB9"

DB defines a D series subminiature connector with a size "B" (nominal 25 pin)
shell. DE defines a size "E" (nominal 9 pin) shell. DA15, DB25, DC37, DD50,
DE9, etc.. Also DB13W3 (old Sun monitors), etc. If in doubt, refer to
ITT/Cannon catalogs. (my oldest is from 1971).


--
-- Welcome My Son, Welcome To The Machine --
Bob Vaughan | techie@{w6yx|tantivy}.stanford.edu | techie@tantivy.net
AF6RR | P.O. Box 19792, Stanford, Ca 94309 | 1-650-469-3850
-- I am Me, I am only Me, And no one else is Me, What could be simpler? --

Give me someone who can already think and analyse over someone who
'knows' it all, any day. You can be qualified to the hilt but
absolutely useless in the real world (I've watched CCNP and higher
struggling to figure out why they can't ping a 10.0.0.0/24 address at a
customers remote site, not even realising it's a private range, let
alone trying to trace the path of the ping,) If you're capable of
symptoms->synthesis->solution you're of much more use to me. You can
pick up technical knowledge on the job, or around the job. It's
extremely hard to mold someone's thinking patterns by the time they're
adults. When we interview we try to spend more time trying to gauge
problem solving capabilities than anything else, after first quickly
establishing their technical level.

Paul

On 2/17/2012 8:43 AM, Kenneth M. Chipps Ph.D. wrote:
> Exactly right. They have some much information floating around in their
> heads many of them cannot fit it together. But once they get on the job, all
> of those little synapses rapidly connect, and then the light comes on.
>
> Higher education is just like drivers education. You did not learn to drive
> in drivers education. You learned how to drive by driving. Higher education
> gives you the foundation on which to learn.
>
> -----Original Message-----
> From: Paul Graydon [mailto:paul@paulgraydon.co.uk]
> Sent: Friday, February 17, 2012 12:33 PM
> To: nanog@nanog.org
> Subject: Re: Common operational misconceptions
>
> On 02/17/2012 04:29 AM, Leo Bicknell wrote:
>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
> Graydon wrote:
>>> At the same time, it's shocking how many network people I come across
>>> with no real grasp of even what OSI means by each layer, even if it's
>>> only in theory. Just having a grasp of that makes all the world of
>>> difference when it comes to troubleshooting. Start at layer 1 and
>>> work upwards (unless you're able to make appropriate intuitive
>>> leaps.) Is it physically connected? Are the link lights flashing? Can
>>> traffic route to it, etc. etc.
>> I wouldn't call it a "misconception", but I want to echo Paul's
>> comment. I would venture over 90% of the engineers I work with have
>> no idea how to troubleshoot properly. Thinking back to my own
>> education, I don't recall anyone in highschool or college attempting
>> to teach troubleshooting skills. Most classes teach you how to build
>> things, not deal with them when they are broken.
> The Cisco CCNA syllabus used to emphasise the layer 1->7 approach to
> troubleshooting. Not sure if they still do, or if trainers even bother to
> mention it (mine did back when I did it several years ago)
>
>> The basic skills are probably obvious to someone who might design
>> course material if they sat down and thought about how to teach
>> troubleshooting. However, there is one area that may not be obvious.
>> There's also a group management problem. Many times troubleshooting
>> is done with multiple folks on the phone (say, customer, ISP and
>> vendor). Not only do you have to know how to troubleshoot, but how to
>> get everyone on the same page so every possible cause isn't tested 3
>> times.
> Never trust what you can't prove yourself, that includes vendors and
> customers. Every now and then I forget this and find hours later that I've
> wasted a whole bunch of time because I trusted when someone said something
> that it actually was the case. It's really often better to test something a
> third time even if Vendor and Customer tell you something is a particular
> way.
>
>> I think all college level courses should include a "break/fix"
>> exercise/module after learning how to build something, and much of
>> that should be done in a group enviornment.
>>
> Definitely. I've learnt more in my time from breaking things than I've ever
> learnt setting them up; however the education system is focused on breadth
> of knowledge, not depth. Students are expected to be able to regurgitate
> ridiculous amounts of facts and figures, so that they pass standardised
> tests, not understand how to actually use them.
>
> Paul
>
>
>
>
>

Paul Graydon wrote:
> Give me someone who can already think and analyse over someone who
> 'knows' it all, any day. You can be qualified to the hilt but
> absolutely useless in the real world (I've watched CCNP and higher
> struggling to figure out why they can't ping a 10.0.0.0/24 address at a
> customers remote site, not even realising it's a private range, let
> alone trying to trace the path of the ping,)

Hard to believe, but you're obviously serious. What are their job titles? What were they hired to accomplish?
Also hard for me to understand that someone could study for CCNx and not get exposed to Private space and 1918...what am I
missing?

--Michael

Michael Sinatra wrote:
> The words "Internet" and "Web" can be used interchangeably

I prefer the term "intergophers" myself.

--
Earthquake Magnitude: 4.9
Date: Friday, February 17, 2012 14:28:20 UTC
Location: Komandorskiye Ostrova, Russia region
Latitude: 54.5969; Longitude: 168.8863
Depth: 34.70 km

David Barak wrote:

>> From: Owen DeLong owen@delong.com
>
>> Sigh... NAT is a horrible hack that served us all too well in
>> address conservation. Beyond that, it is merely a source of pain.
>
> I understand why you say that - NAT did yeoman's work in address
> conservation. However, it also enabled (yes, really) lots of
> topologies and approaches which are *not* designed upon the
> end-to-end model. Some of these approaches have found their way
> into business proceses.

I'm afraid both of you don't try to understand why NAT was
harmful to destroy the end to end transparency nor the end
to end argument presented in the original paper by Saltezer
et. al:

The function in question can completely and correctly be
implemented only with the knowledge and help of the application
standing at the end points of the communication system. Therefore,
providing that questioned function as a feature of the
communication system itself is not possible.

While plain NAT, which actively hide itself from end systems,
which means there can be no "knowledge and help of the
application" expected, is very harmful to the end to end
transparency, it is possible to entirely neutralize the
harmful effects, by let NAT boxes ask help end systems.

> An argument you and others have made many times boils down
> to "but if we never had NAT, think how much better it
> would be!"

The reality is much better that NAT is not so harmful if NAT
clients and gateways are designed properly to be able to
reverse the harmful translations by NAT gateways.

I have running code to make the reverse translations, with
which protocols such as ftp with PORT commands are working.

Masataka Ohta

On 2/17/2012 10:55 PM, Michael Painter wrote:
> Paul Graydon wrote:
>> Give me someone who can already think and analyse over someone who
>> 'knows' it all, any day. You can be qualified to the hilt but
>> absolutely useless in the real world (I've watched CCNP and higher
>> struggling to figure out why they can't ping a 10.0.0.0/24 address at a
>> customers remote site, not even realising it's a private range, let
>> alone trying to trace the path of the ping,)
>
> Hard to believe, but you're obviously serious. What are their job
> titles? What were they hired to accomplish?
> Also hard for me to understand that someone could study for CCNx and
> not get exposed to Private space and 1918...what am I missing?
>
Yes I'm serious, they were CCNP qualified, hired as a NOC engineer for
an ISP & Hosting company. For the company the NOC team was the top tier
of customer support (3rd line+), they looked after routers, switches,
firewalls, servers, leased lines, and so on.
This individual was perfectly capable of regurgitating all the facts,
figures and technical details you can imagine, probably pretty much the
entire CCNP syllabus. What they didn't seem that capable of was
actually applying that to anything. I'd bet good money that if I'd
asked him at the time what the 1918 network ranges are he'd have been
able to tell me.
This is exactly what we're teaching kids to do these days (makes me feel
so old that I've already been saying this for several years and I'm only
31) standardised tests aren't marked based on ability to apply
knowledge, just the knowledge itself. Hence my view, give me someone
who knows how to think over someone who is qualified to the hilt. These
exam cram 'do a CCNP in a week' courses only serve to make it worse.

Paul

> Yes I'm serious, they were CCNP qualified, hired as a NOC engineer for
> an ISP & Hosting company.

There was a time a new hire with all the right holes punched in his ticket deleted an item in an access-list in a PIX that was running an older version of the software than he was familiar with. The entire access-list disappeared and he was locked out, production stopped, like a train hitting a brick wall.


> For the company the NOC team was the top
> tier of customer support (3rd line+), they looked after routers,
> switches, firewalls, servers, leased lines, and so on.
> This individual was perfectly capable of regurgitating all the facts,
> figures and technical details you can imagine, probably pretty much the
> entire CCNP syllabus. What they didn't seem that capable of was
> actually applying that to anything.

You might be surprised at how common that is. If you present them with ALL the diagrams and ALL of the configs on paper, they can figure it out. In other words, if you recreate the same environment they had in their training class, they can do fine. But what some can't seem to be able to do is visualize in their head how things are. It is that layer of abstraction that separates them out. They are fine for maintaining documentation or even for participating in a design review but you don't want them designing some new addition to the network or working on something "live". My first clue often comes from the quality of diagrams they produce. If the diagrams are accurate as far as what connects to what but do not reflect the actual flow of the network, that's a telltale sign. Sort of like an electronic schematic. If they sort of have random components/stages at random locations in the drawing that doesn't really reflect the functional flow through the device, that is my clue that I am likely dealing with a concrete thinker and not an abstract thinker. Ditto if they demand that the symbol representing a particular piece of gear actually be a picture of that piece of gear. If they get lost when gear is represented by a square box then they are probably part of the normal 85% of people who find it more difficult (actually have to try) to translate a square box on a diagram to a router in the rack in their head vs the 15% who do that naturally without any effort.

The access-list guy mentioned above would be great for looking at the config and producing a new one with the correct access control, but you wouldn't want him to be the one to apply it in production on a live network. So even in that guy's case, there is a place where their skills can be quite useful and there are other places where their chance of making a costly mistake increase. It is a matter of matching the person's role to their skills.

> I'd bet good money that if I'd
> asked him at the time what the 1918 network ranges are he'd have been
> able to tell me.

You'll be surprised how many people "forget" that 172.28.0.0 is rfc1918 space. They are so used to seeing 172.16 that they tend to forget 172.17-31. I've had to change null routes and access controls to include the entire /12. They "know" that it is a /12 but seem to forget in practice when they see a second octet that isn't "16".


> This is exactly what we're teaching kids to do these days (makes me
> feel so old that I've already been saying this for several years and
> I'm only
> 31) standardised tests aren't marked based on ability to apply
> knowledge, just the knowledge itself.

Yes. We teach them facts but now how to FIND facts. Part of teaching is in teaching how to teach yourself. It started with me when I was a kid. When I had a question, my father would always say "look it up and tell me" even if he knew the answer perfectly well. He had invested in an encyclopedia and the annual updates and was determined that I would use it. It taught me how to research to find my own answers and it taught me to learn it well enough to explain it to someone else because Pop would always throw in a couple of questions for me after I explained it to him just to see if I actually "got" the underlying concept. Besides, often in the course of researching one thing, I happened across a completely unrelated thing that caught my interest in that volume of the book and learned something I hadn't even been looking for. Forget the Internet, for people with kids at home, I would recommend a hard copy set of World Book with the Year Book and Science Year annual additions. That one in particular because the style in which they are written, they are actually pretty fun to read and have a lot of illustrations. http://www.worldbook.com/browse-all-products/item/953-advanced-research-package-2012 (no affiliation at all with them, just a satisfied "customer"). Soon, going to the books when a question arose became natural.

It is one thing to produce a "teachable" child, something quite different to produce the ability to learn independently and allow their own natural curiosity to "pull" them to that knowledge.

On Thu, 16 Feb 2012, Michael Sinatra wrote:

> There was an old cruddy 1950s building on the UCB campus called Stanley Hall.
> (Now there's a new, nice, modern building on the UCB campus called Stanley
> Hall in place of the old one.)
>
> It was great to take students on tours through this operational museum.
> (Well, the LBNL net was sort of operational. It would just stop working for
> minutes on end and then come back mysteriously.) You could basically see the
> first 10-15 years of the evolution of ethernet, and it was installed and
> working.

I have a few cruddy old 1950s (or earlier) buildings on campus where I can
find thicknet and (dead for many years) vampire taps, along with thinnet,
many different vintages of voice and data cabling, and many different
vintages of fiber, including lots of OM1 multimode. Makes for some very
interesting pictures and "what *is* that?" conversations.

jms

Paul Graydon wrote:
>> Yes I'm serious, they were CCNP qualified, hired as a NOC engineer for
> an ISP & Hosting company. For the company the NOC team was the top tier
> of customer support (3rd line+), they looked after routers, switches,
> firewalls, servers, leased lines, and so on.
> This individual was perfectly capable of regurgitating all the facts,
> figures and technical details you can imagine, probably pretty much the
> entire CCNP syllabus. What they didn't seem that capable of was
> actually applying that to anything. I'd bet good money that if I'd
> asked him at the time what the 1918 network ranges are he'd have been
> able to tell me.
> This is exactly what we're teaching kids to do these days (makes me feel
> so old that I've already been saying this for several years and I'm only
> 31) standardised tests aren't marked based on ability to apply
> knowledge, just the knowledge itself. Hence my view, give me someone
> who knows how to think over someone who is qualified to the hilt. These
> exam cram 'do a CCNP in a week' courses only serve to make it worse.
>
> Paul

Ahh, I get you now...thanks.

Took me back to '64 and the battery of tests (all day!) I was given before getting hired by IBM for the 360 rollout. I
was amazed by the amount of questions of the "if gear a turns ccw, what does lever b do?" variety.
Later I was told that -all- the testing results were important, even the psychological ones, but what they really wanted
to find was the best analytical *mind*.

Best,

--Michael

On Feb 18, 2012, at 3:31 AM, Masataka Ohta wrote:

> David Barak wrote:
>
>>> From: Owen DeLong owen@delong.com
>>
>>> Sigh... NAT is a horrible hack that served us all too well in
>>
>> I understand why you say that - NAT did yeoman's work in address
> > conservation. However, it also enabled (yes, really) lots of
> > topologies and approaches which are *not* designed upon the
> > end-to-end model. Some of these approaches have found their way
> > into business proceses.
>
> I'm afraid both of you don't try to understand why NAT was
> harmful to destroy the end to end transparency nor the end
> to end argument presented in the original paper by Saltezer
> et. al:
>
> The function in question can completely and correctly be
> implemented only with the knowledge and help of the application
> standing at the end points of the communication system. Therefore,
> providing that questioned function as a feature of the
> communication system itself is not possible.
>
> While plain NAT, which actively hide itself from end systems,
> which means there can be no "knowledge and help of the
> application" expected, is very harmful to the end to end
> transparency, it is possible to entirely neutralize the
> harmful effects, by let NAT boxes ask help end systems.
>
>> An argument you and others have made many times boils down
> > to "but if we never had NAT, think how much better it
> > would be!"
>
> The reality is much better that NAT is not so harmful if NAT
> clients and gateways are designed properly to be able to
> reverse the harmful translations by NAT gateways.
>
> I have running code to make the reverse translations, with
> which protocols such as ftp with PORT commands are working.
>
> Masataka Ohta


No, I think you do not understand...

I have a NAT gateway with a single public address.

I have 15 FTP servers and 22 web servers behind it.

I want people to be able to go to ftp://<hostname> and/or http://<hostname> for each of them.

Please explain to me how your code solves this problem?

Yeah, thought so.

Owen

> > I have running code to make the reverse translations, with
> > which protocols such as ftp with PORT commands are working.
>
> No, I think you do not understand...
>
> I have a NAT gateway with a single public address.
>
> I have 15 FTP servers and 22 web servers behind it.
>
> I want people to be able to go to ftp://<hostname> and/or =
> http://<hostname> for each of them.

Owen,

Your suggestion here would set many "security experts" heads on fire.

Whatever will they do when NAT doesn't make such things virtually
impossible?

:-)

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

On Sun, Feb 19, 2012 at 6:24 PM, Owen DeLong <owen@delong.com> wrote:
> I have 15 FTP servers and 22 web servers behind it.
> I want people to be able to go to ftp://<hostname> and/or http://<hostname> for each of them.

For HTTP; You put a device on that one IP that will accept each TCP
connection, await the SNI or Host header from the client, and then
make/forward the connection to a proper server for that hostname.
The public IP address belongs to the FTP/HTTP "service" instead of
belonging to a server.


For FTP, send to a desired FTP server based on the login username or
otherwise make a SRV record for the _ftp service for each hostname,
and set aside a TCP port for each FTP service's control connection.

The ftp://user@<hostname> approach or the
ftp://user@<basehostname>/<hostname>/ is probably more convenient
than ftp://<hostname>:<1234>, since many clients do not support SRV
records.

The problem is with the FTP protocol not supporting virtual hosting,
though; this missing FTP feature is not a NAT problem per se.

The VHOST problem was solved with HTTP a long time ago.
It's just that FTP is a lot less popular / fell into some disuse, so
the deficiency (lack of virtual hosting support) was never
corrected -- and the protocol hasn't had a single update in a long
time.

So you'll have to have a workaround to do 15 FTP servers with one
global IP, because your circumstance is so unusual, that's just
life.

--
-JH

In message <201202200107.q1K17W5l000294@aurora.sol.net>, Joe Greco writes:
> > > I have running code to make the reverse translations, with
> > > which protocols such as ftp with PORT commands are working.
> >
> > No, I think you do not understand...
> >
> > I have a NAT gateway with a single public address.
> >
> > I have 15 FTP servers and 22 web servers behind it.
> >
> > I want people to be able to go to ftp://<hostname> and/or =
> > http://<hostname> for each of them.
>
> Owen,
>
> Your suggestion here would set many "security experts" heads on fire.
>
> Whatever will they do when NAT doesn't make such things virtually
> impossible?
>
> :-)

Time to write "How to use SRV with FTP". CGN is going to push
the extension of a whole lot of protocols.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Wed, 15 Feb 2012 12:47:15 -0800, John Kristoff <jtk@cymru.com> wrote:

> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.

The idea that "the more access-points, the better our WiFi".

Oh, and the use of RJ45 for the unconfigured 8P8C, but this is not that
annoying.

Cheers.

On Sun, 2012-02-19 at 19:09 -0600, Jimmy Hess wrote:
> For HTTP; You put a device on that one IP that will accept each TCP
> connection, await the SNI or Host header from the client, and then
> make/forward the connection to a proper server for that hostname.

So you need an extra device to work around NAT. Or you have to build
extra smarts into existing devices to work around NAT. There is a
pattern here...

> For FTP, send to a desired FTP server based on the login username or
> otherwise make a SRV record for the _ftp service for each hostname,
> and set aside a TCP port for each FTP service's control connection.

So NAT does indeed prevent the scenario Owen outlined.

It does not make sense to make that the application's fault. If you have
to build NAT-awareness (even indirectly, as in SRV-awareness) into every
application, then you've lost the game and it might be time to realise
that NAT is the problem, not all the applications.

> The problem is with the FTP protocol not supporting virtual hosting,
> though; this missing FTP feature is not a NAT problem per se.

I'm not sure I agree with that, see above. And while virtual hosting may
be a Good Thing for various other reasons, it seems to me that if it is
required with NAT and is not required without NAT, then it is most
certainly "the fault of NAT" that it is required.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

Owen DeLong wrote:

>> I have running code to make the reverse translations, with
>> which protocols such as ftp with PORT commands are working.

> No, I think you do not understand...

How can't I understand several minor issues with the running code.

> I have 15 FTP servers and 22 web servers behind it.
> I want people to be able to go to ftp://<hostname> and/or http://<hostname> for each of them.
> Please explain to me how your code solves this problem?

See

draft-ohta-urlsrv-00.txt

DNS SRV RRs of a domain implicitly specify servers and port numbers
corresponding to the domain.

By combining URLs and SRV RRs, no port numbers have to be specified
explicitly in URLs, even if non-default port numbers are used, which
makes URLs more concise for port based virtual and real hosting,
where port based real hosting means that multiple servers sharing an
IP address are distinguished by port numbers to give service for
different URLs, which is the case for port forwarded servers behind
NAT and servers with realm specific IP.

> Yeah, thought so.

The draft has been available since September 29, 2011.

Masataka Ohta

On Mon, 20 Feb 2012 11:17:32 +0900, Masataka Ohta
<mohta@necom830.hpcl.titech.ac.jp> wrote:
> draft-ohta-urlsrv-00.txt
>
> DNS SRV RRs of a domain implicitly specify servers and port numbers
> corresponding to the domain.
>
> By combining URLs and SRV RRs, no port numbers have to be specified
> explicitly in URLs, even if non-default port numbers are used, which
> makes URLs more concise for port based virtual and real hosting,
> where port based real hosting means that multiple servers sharing an
> IP address are distinguished by port numbers to give service for
> different URLs, which is the case for port forwarded servers behind
> NAT and servers with realm specific IP.
>

It seems to me that this will create all sorts of headaches for firewall
ALGs. Rather than just passing port 21/tcp traffic to the FTP ALG for
example, the devices would need to inspect traffic on all ports and perform
DPI. This is not as much of a problem on the firewall protecting the
servers (you know what ports to inspect), but will require a lot more
processing power on the client-side NAT firewall.

Jonesy

On Sun, Feb 19, 2012 at 10:09 PM, Andrew Jones <aj@jonesy.com.au> wrote:
> On Mon, 20 Feb 2012 11:17:32 +0900, Masataka Ohta
> It seems to me that this will create all sorts of headaches for firewall
> ALGs. Rather than just passing port 21/tcp traffic to the FTP ALG for
> example, the devices would need to inspect traffic on all ports and perform
[snip]

That doesn't work when the FTP control connection is encrypted using SSL.
Layer 4 Firewall devices should not be expecting to intercept FTP
traffic and make decisions based on the application layer contents of
the traffic.

I would suggest a requirement that FTP clients utilizing SRV records
to access FTP on an alternate port MUST utilize Firewall-Friendly FTP
as described by RFC1579.

Each FTP server can then be assigned its own port range, or the FTP
server can be configured to notify the Firewall device which ports to
forward using UpNP or a NAT traversal protocol such as STUN, and the
Firewall device can be configured to forward the appropriate range of
ports to the correct server.

--
-JH

George Bonser wrote:

>> It is seemingly working well means there is not much PMTU changes,
>> which means we had better assumes some PMTU (1280B, for example) and
>> use it without PMTUD.

> It depends on the OS and the method being used. If you set the
> option to "2" on Linux, it will do MTU probing constantly and
> react to MTU changes.

It actually does nothing.

Given the following statements in the RFC:

An initial eff_pmtu of 1400 bytes might
be a good compromise because it would be safe for nearly all tunnels
over all common networking gear, and yet close to the optimal MTU for
the majority of paths in the Internet today.

and

Each Packetization Layer MUST determine when probing has converged,
that is, when the probe size range is small enough that further
probing is no longer worth its cost. When probing has converged, a

the hosts are keep assuming PMTU of 1400B and if local MTU
is 1500B or less, no discovery is performed because "the
probe size range is small enough".

> Also, the MTU for a given path only "lives" for 5 minutes anyway
> (by default) and is "rediscovered" with Linux. (value in
> /proc/sys/net/ipv4/route/mtu_expires) but other operating
> systems may behave in other ways.

See above. Rediscovery with initial eff_pmtu of 1400B and
search_high of 1500B immediately terminates without any
probe packets sent.

Masataka Ohta

On Feb 19, 2012, at 5:21 PM, Mark Andrews wrote:

>
> In message <201202200107.q1K17W5l000294@aurora.sol.net>, Joe Greco writes:
>>>> I have running code to make the reverse translations, with
>>>> which protocols such as ftp with PORT commands are working.
>>>
>>> No, I think you do not understand...
>>>
>>> I have a NAT gateway with a single public address.
>>>
>>> I have 15 FTP servers and 22 web servers behind it.
>>>
>>> I want people to be able to go to ftp://<hostname> and/or =
>>> http://<hostname> for each of them.
>>
>> Owen,
>>
>> Your suggestion here would set many "security experts" heads on fire.
>>
>> Whatever will they do when NAT doesn't make such things virtually
>> impossible?
>>
>> :-)
>
> Time to write "How to use SRV with FTP". CGN is going to push
> the extension of a whole lot of protocols.

That would be the worst case scenario, actually.

Owen

On Sun, 19 Feb 2012 16:24:49 PST, Owen DeLong said:

> No, I think you do not understand...
>
> I have a NAT gateway with a single public address.
>
> I have 15 FTP servers and 22 web servers behind it.
>
> I want people to be able to go to ftp://<hostname> and/or =
> http://<hostname> for each of them.
>
> Please explain to me how your code solves this problem?

I suspect that Masataka thinks the fact you can say http://hostname1:81,
http://hostname2:82, and so on means it's Not A Problem.

Except of course if you're trying to deploy this to actual users on actual
networks.

On Mon, 20 Feb 2012 15:42:56 +0900, Masataka Ohta said:
> George Bonser wrote:
>
> >> It is seemingly working well means there is not much PMTU changes,
> >> which means we had better assumes some PMTU (1280B, for example) and
> >> use it without PMTUD.
>
> > It depends on the OS and the method being used. If you set the
> > option to "2" on Linux, it will do MTU probing constantly and
> > react to MTU changes.
>
> It actually does nothing.

Did you find this by just reading RFCs, or by actual code inspection?

> the hosts are keep assuming PMTU of 1400B and if local MTU
> is 1500B or less, no discovery is performed because "the
> probe size range is small enough".

And if the local MTU is 9000?

> George Bonser wrote:
>
> >> It is seemingly working well means there is not much PMTU changes,
> >> which means we had better assumes some PMTU (1280B, for example) and
> >> use it without PMTUD.
>
> > It depends on the OS and the method being used. If you set the
> option
> > to "2" on Linux, it will do MTU probing constantly and react to MTU
> > changes.
>
> It actually does nothing.


Must be magic then, because it works for me. I've got a few dozen servers with MTU 7500 that aren't having a bit of trouble talking to anyone.

George Bonser wrote:

> Must be magic then, because it works for me.

Yes, but magicians always use tricks.

> I've got a few dozen servers with MTU 7500 that aren't
> having a bit of trouble talking to anyone.

Your trick is that your routers at the border between MTUs
7500 and 1500 (or maybe, 1400 or so) generate ICMP packet
too big packets to your servers and no intermediate
entities filter them, isn't it?

Masataka Ohta

>
> Your trick is that your routers at the border between MTUs
> 7500 and 1500 (or maybe, 1400 or so) generate ICMP packet too big
> packets to your servers and no intermediate entities filter them, isn't
> it?
>
> Masataka Ohta

I am saying that MTU probing works just fine, even with a link in between that has a shorter MTU and doesn't pass ICMP. I actually have one of those.

It actively probes with packets of varying sizes and learns what the path MTU is. It does not rely on ICMP. Again, it actively probes with varying sizes of packets until it believes it has "converged". There are two modes with linux. 1: where it only probes if there is a problem and 2: where it probes all the time.



The initial value for search_high SHOULD be the largest possible
packet that might be supported by the flow. This may be limited by
the local interface MTU, by an explicit protocol mechanism such as
the TCP MSS option, or by an intrinsic limit such as the size of a
protocol length field. In addition, the initial value for
search_high MAY be limited by a configuration option to prevent
probing above some maximum size. Search_high is likely to be the
same as the initial Path MTU as computed by the classical Path MTU
Discovery algorithm.

It is RECOMMENDED that search_low be initially set to an MTU size
that is likely to work over a very wide range of environments. Given
today's technologies, a value of 1024 bytes is probably safe enough.
The initial value for search_low SHOULD be configurable.

...

The probe may have a size anywhere in the "probe size range"
described above. However, a number of factors affect the selection
of an appropriate size. A simple strategy might be to do a binary
search halving the probe size range with each probe. However, for
some protocols, such as TCP, failed probes are more expensive than
successful ones, since data in a failed probe will need to be
retransmitted. For such protocols, a strategy that raises the probe
size in smaller increments might have lower overhead. For many
protocols, both at and above the Packetization Layer, the benefit of
increasing MTU sizes may follow a step function such that it is not
advantageous to probe within certain regions at all.

As an optimization, it may be appropriate to probe at certain common
or expected MTU sizes, for example, 1500 bytes for standard Ethernet,
or 1500 bytes minus header sizes for tunnel protocols.

Some protocols may use other mechanisms to choose the probe sizes.
For example, protocols that have certain natural data block sizes
might simply assemble messages from a number of blocks until the
total size is smaller than search_high, and if possible larger than
search_low.

Each Packetization Layer MUST determine when probing has converged,
that is, when the probe size range is small enough that further
probing is no longer worth its cost. When probing has converged, a
timer SHOULD be set. When the timer expires, search_high should be
reset to its initial value (described above) so that probing can
resume. Thus, if the path changes, increasing the Path MTU, then the
flow will eventually take advantage of it. The value for this timer
MUST NOT be less than 5 minutes and is recommended to be 10 minutes,
per RFC 1981.

The timer for Linux is 5 minute by default but you can change it.