On 2016-07-12 03:25, Sean Donelan wrote:
> RFC791 was written during the internet's anti-standard era.
>
> We reject: kings, presidents and voting. We believe in: rough consensus and
> running code
Hi Sean,
Lovely quote and all, but... do you mean that when RFC791 was
drafted the IETF didn't iss
On Mon, 11 Jul 2016, cpol...@surewest.net wrote:
Thanks for identifying the source, I wish more people did this.
My nitpick is that RFC791 doesn't label MTU=68 as "standard";
it says (section 3.2, p.25):
RFC791 was written during the internet's anti-standard era.
We reject: kings, presidents a
On 2016-07-11 11:26, Mark Andrews wrote:
>
> In message <25577fe1-6366-4d6d-b82e-a779193cb...@beckman.org>, Mel Beckman
> writ
> The Internet Standard MTU's are 68 octets for IPv4 (RFC 791) and
> 1280 octets for IPv6 (RFC 2460).
>
> Every size greater than those is subject to negotiation. Now mo
That's the one:)
Kind regards
James Greig
> On 11 Jul 2016, at 01:26, Mel Beckman wrote:
>
> James,
>
> You may be thinking of this presentation:
>
> https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
>
> -mel beckman
>
>> On Jul 10, 2016, at 4:49 PM,
In message <25577fe1-6366-4d6d-b82e-a779193cb...@beckman.org>, Mel Beckman writ
es:
> Philip,
>
> Quite often slow Web page loading and email transport -- termed an
> application-layer problem because basic transport seems unaffected -- is
> due to DNS problems, particularly reverse DNS for the IP
James,
You may be thinking of this presentation:
https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
-mel beckman
> On Jul 10, 2016, at 4:49 PM, James Greig wrote:
>
> There was a useful nanog presentation somewhere that explained this really
> well in pa
There was a useful nanog presentation somewhere that explained this really well
in particular reading traceroutes correctly
Kind regards
James Greig
> On 7 Jul 2016, at 20:17, Phillip Lynn wrote:
>
> Hi all,
>
> I am writing because I do not understand what is happening. I ran mtr
> agai
On 2016-07-07 11:53 PM, William Herrin wrote:
On Thu, Jul 7, 2016 at 3:52 PM, Ken Chase wrote:
ICMP is allowed to be dropped by intervening routers. Someone will
quote an RFC
at us shortly.
Hi Ken,
That's not correct. Routers might not generate an ICMP time-exceeded
packet for every packet
On Fri, Jul 8, 2016 at 9:09 AM, Ken Chase wrote:
> And we know the whole internet observes handling
> mtu discovery properly
> and doesnt just firewall all ICMP because 'hackers'.
>
> (OP's issue may well be MTU discovery, esp if he's on
> broadband. Don't have
> enough details. I just solved this
Philip,
Quite often slow Web page loading and email transport -- termed an
application-layer problem because basic transport seems unaffected -- is due to
DNS problems, particularly reverse DNS for the IP addresses originating your
Web queries. If you have non-existent or intermittent IN-ADDR e
And we know the whole internet observes handling mtu discovery properly
and doesnt just firewall all ICMP because 'hackers'.
(OP's issue may well be MTU discovery, esp if he's on broadband. Don't have
enough details. I just solved this exact problem a couple weeks ago for a
client with an UBNT ER
On 07/07/2016 03:52 PM, Ken Chase wrote:
No offence, but i swear that mtr should come with a license to use it. I get
more
questions from people accusing us of network issues with mtr in hand...
You shoudlnt care that there's 80% packet loss in the middle of your route,
unless
you have actual
On Thu, Jul 7, 2016 at 3:52 PM, Ken Chase wrote:
> ICMP is allowed to be dropped by intervening routers. Someone will quote an
> RFC
> at us shortly.
Hi Ken,
That's not correct. Routers might not generate an ICMP time-exceeded
packet for every packet whose TTL reaches zero, but that's not the
s
On 7/7/16 3:50 PM, Mel Beckman wrote:
Ken,
I should have made clear I wasn't replying to you. I was replying to Brielle's
comment:
> Is it bad that the first thing that came to mind is "Oh FFS, another troll"?
I'd never say I was always knowledgeable, but after the thread the other
day, and
Ken,
I should have made clear I wasn't replying to you. I was replying to Brielle's
comment:
> Is it bad that the first thing that came to mind is "Oh FFS, another troll"?
-mel beckman
> On Jul 7, 2016, at 2:35 PM, Ken Chase wrote:
>
> On Thu, Jul 07, 2016 at 08:32:19PM +, Mel Beckman
On Thu, Jul 07, 2016 at 08:32:19PM +, Mel Beckman said:
>Yes. It indicates that there was never a time when you did not know
everything :)
>
> -mel beckman
The issue isnt knowing everything, it's making accusations of issues while you
still
dont know how much you dont know. (~D. Rumsfe
Yes. It indicates that there was never a time when you did not know everything
:)
-mel beckman
> On Jul 7, 2016, at 1:28 PM, Brielle Bruns wrote:
>
>> On 7/7/16 1:17 PM, Phillip Lynn wrote:
>> Hi all,
>>
>> I am writing because I do not understand what is happening. I ran mtr
>> against ou
On 7/7/16 1:17 PM, Phillip Lynn wrote:
Hi all,
I am writing because I do not understand what is happening. I ran mtr
against our email server and www.teco.comand below are the results. I
am not a network engineer so I am at a loss. I think what I am seeing
is maybe a hand off issue, between
> On Jul 7, 2016, at 3:17 PM, Phillip Lynn wrote:
>
> Hi all,
>
> I am writing because I do not understand what is happening. I ran mtr
> against our email server and www.teco.comand below are the results. I am not
> a network engineer so I am at a loss. I think what I am seeing is maybe a
No offence, but i swear that mtr should come with a license to use it. I get
more
questions from people accusing us of network issues with mtr in hand...
You shoudlnt care that there's 80% packet loss in the middle of your route,
unless
you have actual traffic to lag-101.ear3.miami2.level3.net.
Hi Philip,
I can't address your immediate concern, but I do have some hints
regarding traceroute:
1/ Please review the excellent presentation from RA{T,S}:
https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
https://www.youtube.com/watch?v=a1IaRAVGPEE
Hi all,
I am writing because I do not understand what is happening. I ran
mtr against our email server and www.teco.comand below are the results.
I am not a network engineer so I am at a loss. I think what I am seeing
is maybe a hand off issue, between Frontier and Level3Miami2. If I am
22 matches
Mail list logo
