Anybody work with VMWare HCX having weird MTU issues? Can provide more info
but just curious
On Fri, 1 May 2020 at 19:00, Dovid Bender wrote:
> I currently have an airlink that is connected directly to a raritan console
> server. The public IP sits on the raritan. The airlink does not seem to have
> any MTU options. Ideally I would change the MTU on the interface of the LTE
On Fri, May 01, 2020 at 11:56:57AM -0400, Dovid Bender wrote:
>I currently have an airlink that is connected directly to a raritan
>console server. The public IP sits on the raritan. The airlink does not
>seem to have any MTU options. Ideally I would change the M
I currently have an airlink that is connected directly to a raritan console
server. The public IP sits on the raritan. The airlink does not seem to
have any MTU options. Ideally I would change the MTU on the interface of
the LTE modem wich would force the raritan to send all data < 1400 bytes
> We have VZ wireless in the data center as a backup to our core
> infrastructure. We have an issue where if packets have a large MTU they seem
> to die. Does anyone know of a good 4G modem where I can set the MTU on the
> cellular connection?
I suspect it's a bit more
Hey,
> We have VZ wireless in the data center as a backup to our core
> infrastructure. We have an issue where if packets have a large MTU they seem
> to die. Does anyone know of a good 4G modem where I can set the MTU on the
> cellular connection?
Cisco ISR with NIM-4G-LTE-VZ
--
++ytti
On Fri, May 1, 2020 at 10:10 AM Dovid Bender wrote:
>
> Hi,
>
> We have VZ wireless in the data center as a backup to our core
> infrastructure. We have an issue where if packets have a large MTU they seem
> to die. Does anyone know of a good 4G modem where I can set the MTU
Hi,
We have VZ wireless in the data center as a backup to our core
infrastructure. We have an issue where if packets have a large MTU they
seem to die. Does anyone know of a good 4G modem where I can set the MTU on
the cellular connection?
TIA.
Dovid
On Sat, 20 Jan 2018, Mark Andrews wrote:
Which doesn’t work with IPv6 as UDP doesn’t have the field to clamp.
Well, not with UDP/IPv4 either. Actually, the only protocol I know out
there that has this kind of clamping (and is in wide use for clamping), is
TCP.
Thus, my earlier comment abou
Which doesn’t work with IPv6 as UDP doesn’t have the field to clamp.
--
Mark Andrews
> On 20 Jan 2018, at 03:35, Radu-Adrian Feurdean
> wrote:
>
>> On Fri, Jan 19, 2018, at 01:14, Jared Mauch wrote:
>> If you’re then doing DSL + PPPoE and your customers really see a M
On Fri, Jan 19, 2018, at 01:14, Jared Mauch wrote:
> If you’re then doing DSL + PPPoE and your customers really see a MTU
> of 1492 or less, then another device has to fragment 5x again.
In this part of the world we have even worse stuff around: PPP over L2TP over
over IP with 15
On Fri, Jan 19, 2018 at 9:07 AM, Mike Hammett wrote:
> Wouldn't those situations be causing issues now, given the likelihood that
> someone with a less than 1,500 byte MTU is communicating with you now?
Hi Mike,
They do. These are the people calling your support line with the
com
❦ 19 janvier 2018 08:07 -0600, Mike Hammett :
> Wouldn't those situations be causing issues now, given the likelihood
> that someone with a less than 1,500 byte MTU is communicating with you
> now?
Those situations are causing issues now. If you have a MTU less than
1500 bytes
On Fri, Jan 19, 2018 at 8:58 AM, Jared Mauch wrote:
>> On Jan 18, 2018, at 8:44 PM, William Herrin wrote:
>>> Which packet? Is there a specific CDN that does this? I’d be curious to
>>> see
>>> data vs speculation.
>>
>> Path MTU discovery (whi
D not work? Honest
>> question, not troll.
>
> Mismatch of MTU interface settings between interfaces, mismatch of MTU
> between L3 devices and intermediate L2 devices, anycast services, ECMP based
> services where the ICMP error is delivered to the wrong node.
>
> S
On Fri, Jan 19, 2018 at 8:48 AM, Mike Hammett wrote:
> Other than people improperly blocking ICMP, when does PMTUD not work?
> Honest question, not troll.
>
Hi Mike,
One common scenario: the router's interface is numbered with an RFC 1918
private IP address. The packet is dropped because it tri
On Fri, 19 Jan 2018, Mike Hammett wrote:
Wouldn't those situations be causing issues now, given the likelihood
that someone with a less than 1,500 byte MTU is communicating with you
now?
If the issue is that you're letting 8996 byte packets through but not 9000
byte packet
om: "Jared Mauch"
To: "Mike Hammett"
Cc: "NANOG list"
Sent: Friday, January 19, 2018 8:13:02 AM
Subject: Re: MTU to CDN's
> On Jan 19, 2018, at 9:07 AM, Mike Hammett wrote:
>
> Wouldn't those situations be causing issues now, given the li
> On Jan 19, 2018, at 9:07 AM, Mike Hammett wrote:
>
> Wouldn't those situations be causing issues now, given the likelihood that
> someone with a less than 1,500 byte MTU is communicating with you now?
>
Tends to be more localized and less visible in many cases.
I
Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "Mikael Abrahamsson"
> To: "Michael Crapse"
> Cc: "NANOG list"
> Sent: Friday, January 19, 2018 1:22:02 AM
> Subject: Re: MTU to CDN's
>
> On Thu, 18
Wouldn't those situations be causing issues now, given the likelihood that
someone with a less than 1,500 byte MTU is communicating with you now?
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
Midwest-IX
http://www.midwest-ix.com
- Original Me
On Fri, 19 Jan 2018, Mike Hammett wrote:
Other than people improperly blocking ICMP, when does PMTUD not work?
Honest question, not troll.
Mismatch of MTU interface settings between interfaces, mismatch of MTU
between L3 devices and intermediate L2 devices, anycast services, ECMP
based
see
>>> data vs speculation.
>>
>> Howdy,
>>
>> Path MTU discovery (which sets the DF bit on TCP packets) is enabled
>> by default on -every- operating system that's shipped for decades now.
>> If you don't want it, you have to explicitly disable it.
> On Jan 18, 2018, at 8:44 PM, William Herrin wrote:
>
>> Which packet? Is there a specific CDN that does this? I’d be curious to see
>> data vs speculation.
>
> Howdy,
>
> Path MTU discovery (which sets the DF bit on TCP packets) is enabled
> by default o
: "Michael Crapse"
Cc: "NANOG list"
Sent: Friday, January 19, 2018 1:22:02 AM
Subject: Re: MTU to CDN's
On Thu, 18 Jan 2018, Michael Crapse wrote:
> I don't mind letting the client premises routers break down 9000 byte
> packets. My ISP controls end to e
less network congestion for end users for a one
time $60 service many people would want. It's also where the internet
should be heading... Not to beat a dead horse(re:ipv6 ) but why hasn't the
entire internet just moved to 9000(or 9600 L2) byte MTU? It was created for
the jump to gigabit...
time $60 service many people would want. It's also where the internet
should be heading... Not to beat a dead horse(re:ipv6 ) but why hasn't the
entire internet just moved to 9000(or 9600 L2) byte MTU? It was created for
the jump to gigabit... That's 4 orders of magnitude ago. T
❦ 19 janvier 2018 08:53 +1000, George Michaelson :
> if I was an ISP (Im not) and a CDN came and said "we want to be inside
> you" (ewww) why wouldn't I say "sure: lets jumbo"
Most traffic would be with clients limited to at most 1500 bytes.
--
Its name is Public Opinion. It is held in revere
need
>>> to fragment, then it’s your routers job to slice 9000 into 5 x 1500.
>>
>> In practice, no, because the packet you sent had the "don't fragment"
>> bit set.
>
> Which packet? Is there a specific CDN that does this? I’d be curious to see
> dat
> On Jan 18, 2018, at 7:32 PM, William Herrin wrote:
>
> On Thu, Jan 18, 2018 at 7:14 PM, Jared Mauch wrote:
>> lets say i can
>> send you a 9K packet. If you receive that frame, and realize you need
>> to fragment, then it’s your routers job to slice 9000 into 5 x 1500.
>
> In practice, no,
> On Jan 18, 2018, at 4:32 PM, William Herrin wrote:
>
> On Thu, Jan 18, 2018 at 7:14 PM, Jared Mauch wrote:
>> lets say i can
>> send you a 9K packet. If you receive that frame, and realize you need
>> to fragment, then it’s your routers job to slice 9000 into 5 x 1500.
>
> In practice, no,
On Thu, Jan 18, 2018 at 7:14 PM, Jared Mauch wrote:
> lets say i can
> send you a 9K packet. If you receive that frame, and realize you need
> to fragment, then it’s your routers job to slice 9000 into 5 x 1500.
In practice, no, because the packet you sent had the "don't fragment"
bit set. That
eap dumb switches, but
> even dumb switches like bigger packets dont they? less forwarding
> decision cost, for more throughput?
The reason is most customers are at a lower MTU size. lets say i can
send you a 9K packet. If you receive that frame, and realize you need
to fragment, then it’s
en sure go ahead and use jumbo frames otherwise use the lowest
> common denominator MTU when transmitting. This is less than 1500 on
> today Internet and encapsulated traffic is reasonable common.
>
> embedded CND <--> NAT64 <--> CLAT <--> client
>
common denominator MTU when transmitting. This is less than 1500 on
today Internet and encapsulated traffic is reasonable common.
embedded CND <--> NAT64 <--> CLAT <--> client
1500 14XX 1500
embedded CDN <-->
hroughput?
On Fri, Jan 19, 2018 at 6:21 AM, Dovid Bender wrote:
> Vincent,
>
> Thanks. That URL explained a lot.
>
> On Tue, Jan 9, 2018 at 3:11 AM, Vincent Bernat wrote:
>
>> ❦ 8 janvier 2018 15:08 -0800, joel jaeggli :
>>
>> >> N00b here trying to un
Vincent,
Thanks. That URL explained a lot.
On Tue, Jan 9, 2018 at 3:11 AM, Vincent Bernat wrote:
> ❦ 8 janvier 2018 15:08 -0800, joel jaeggli :
>
> >> N00b here trying to understand why certain CDN's such as Cloudfare have
> >> issues where my MTU is low. For in
❦ 8 janvier 2018 15:08 -0800, joel jaeggli :
>> N00b here trying to understand why certain CDN's such as Cloudfare have
>> issues where my MTU is low. For instance if I am using pptp and the MTU is
>> at 1300 it wont work. If I increase to 1478 it may or may not wor
destination will work fine.
This is understandable, but if this is also an operational practice we as
the operational community want to condone (people using solutions where
PMTUD doesn't work), then we also need to make sure that all applications
do PLMTUD (RFC4821, Packet Level MTU Discovery).
On Mon, 08 Jan 2018 17:55:55 -0500, Dovid Bender said:
> Hi,
>
> N00b here trying to understand why certain CDN's such as Cloudfare have
> issues where my MTU is low. For instance if I am using pptp and the MTU is
> at 1300 it wont work. If I increase to 1478 it may or may n
such as Cloudfare have
>> issues where my MTU is low. For instance if I am using pptp and the MTU is
>> at 1300 it wont work. If I increase to 1478 it may or may not work.
>
> I've done some measurements over the internet in the past year or
> so and 1400 byte packets
On Mon, Jan 08, 2018 at 05:55:55PM -0500, Dovid Bender wrote:
> Hi,
>
> N00b here trying to understand why certain CDN's such as Cloudfare have
> issues where my MTU is low. For instance if I am using pptp and the MTU is
> at 1300 it wont work. If I increase to 1478 it
On 1/8/18 2:55 PM, Dovid Bender wrote:
> Hi,
>
> N00b here trying to understand why certain CDN's such as Cloudfare have
> issues where my MTU is low. For instance if I am using pptp and the MTU is
> at 1300 it wont work. If I increase to 1478 it may or may not work.
PMTUD
Hi,
N00b here trying to understand why certain CDN's such as Cloudfare have
issues where my MTU is low. For instance if I am using pptp and the MTU is
at 1300 it wont work. If I increase to 1478 it may or may not work.
TIA.
range with underlying transport network
mtu possibly causing ospf neighbor adjacency to be broken ?
Yes, the neighbor state will loop between init/Exchange and it will never
become Full.
As others said, you need to test the MTU size without fragmentation and
adjust in your L3 interface (ping w
be pretty big. According to:
https://supportforums.cisco.com/t5/service-providers-documents/ospf-and-mtu/ta-p/3118885
"RFC 2328 (OSPF version 2 specification) says...If
necessary, the length of OSPF packets can be up to
65,535 bytes (including the IP header). The OSPF
packet types tha
Anyone ever experienced anything strange with underlying transport network
> mtu possibly causing ospf neighbor adjacency to be broken ? I'm asking if
> the underlying 3rd party transport layer 2 network
>has a smaller mtu than the endpoint ospf ip interface have, could this cause
>thos
transport network
mtu possibly causing ospf neighbor adjacency to be broken ? > I'm asking if
the underlying 3rd party transport layer 2 network has a smaller mtu than
the endpoint ospf ip interface have, could this cause those ospf neighbors
to not fully establish ?
Yes. Easy to check wit
This is a *single area* ospf environment, that has been stable for years..
But now suddenly is having issues with new ospf neightbor adjacencies ,
which are riding a 3rd party transport network
Anyone ever experienced anything strange with underlying transport network
mtu possibly causing
> On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka wrote:
>
> On 2016-07-22 15:57, William Herrin wrote:
>> On a link containing only routers, you can safely increase the MTU to
>> any mutually agreed value with these caveats:
>
> What I noticed a few years ago was th
On 23/Jul/16 13:32, Tore Anderson wrote:
>
> That said, I've never tried extending our MPLS backbone outside of
> our own administrative domain or autonomous system. That sounds like a
> really scary prospect to me, but I'll admit I've never given serious
> consideration to such an arrangement b
* Baldur Norddahl
> I did not say we were doing internet peering...
Uhm. When you say that you peer with another ISP (and keep in mind what
the "I" in ISP stands for), while giving no further details, then folks
are going to assume that you're talking about a standard eBGP peering
with inet/inet6
On 23 July 2016 at 10:28, Tore Anderson wrote:
> * Baldur Norddahl
>
> > What is best practice regarding choosing MTU on transit links?
> >
> > Until now we have used the default of 1500 bytes. I now have a
> > project were we peer directly with another small ISP. H
* Baldur Norddahl
> What is best practice regarding choosing MTU on transit links?
>
> Until now we have used the default of 1500 bytes. I now have a
> project were we peer directly with another small ISP. However we need
> a backup so we figured a GRE tunnel on a common IP
On 22/Jul/16 19:37, Grzegorz Janoszka wrote:
>
>
> What I noticed a few years ago was that BGP convergence time was
> faster with higher MTU.
> Full BGP table load took twice less time on MTU 9192 than on 1500.
> Of course BGP has to be allowed to use higher MTU.
>
&
On 7/22/16, Phil Rosenthal wrote:
>
>> On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka
>> wrote:
>> What I noticed a few years ago was that BGP convergence time was faster
>> with higher MTU.
>> Full BGP table load took twice less time on MTU 9192 than on 1500.
&
On 2016-07-22 20:20, Phil Rosenthal wrote:
On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka wrote:
What I noticed a few years ago was that BGP convergence time was faster with
higher MTU.
Full BGP table load took twice less time on MTU 9192 than on 1500.
Of course BGP has to be allowed to use
> On 22 Jul 2016, at 19:37, Grzegorz Janoszka wrote:
>
>> On 2016-07-22 15:57, William Herrin wrote:
>> On a link containing only routers, you can safely increase the MTU to
>> any mutually agreed value with these caveats:
>
> What I noticed a few years ago was
> On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka wrote:
> What I noticed a few years ago was that BGP convergence time was faster with
> higher MTU.
> Full BGP table load took twice less time on MTU 9192 than on 1500.
> Of course BGP has to be allowed to use higher MTU.
&
On 2016-07-22 15:57, William Herrin wrote:
On a link containing only routers, you can safely increase the MTU to
any mutually agreed value with these caveats:
What I noticed a few years ago was that BGP convergence time was faster
with higher MTU.
Full BGP table load took twice less time on
Worth reading this on choosing MTU on transit link.
http://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/
-Sad
>>
>> On Fri, Jul 22, 2016 at 10:01 PM, Baldur Norddahl <
>> baldur.nordd...@gmail.com> wrote:
>>
>&g
imple enough. I've only experienced one situation for which the MTU must
match and that is on OSPF neighbor relationships, for which John T. Moy's
book (OSPF - Anatomy of an Internet Routing Protocol) clearly explains why
MTU became an issue during development of that protocol. As more and mo
t; avoid the troubles you get by having an effective MTU smaller than 1500
> inside the tunnel, so the IP transit carrier agreed to configure a MTU of
> 9216.
>
> Obviously I only need to increase my MTU by the size of the GRE header. But
> I am thinking is there any reason not to go all
On Fri 2016-Jul-22 14:01:36 +0200, Baldur Norddahl
wrote:
Hi
What is best practice regarding choosing MTU on transit links?
Until now we have used the default of 1500 bytes. I now have a project were
we peer directly with another small ISP. However we need a backup so we
figured a GRE
On 22/Jul/16 15:42, Chris Kane wrote:
>
> My experience has been making a view phone calls and agreeing on 9,000
> is simple enough. I've only experienced one situation for which the
> MTU must match and that is on OSPF neighbor relationships, for which
> John T. Moy'
On Fri, Jul 22, 2016 at 8:01 AM, Baldur Norddahl
wrote:
> What is best practice regarding choosing MTU on transit links?
Hi Baldur,
On a link containing only routers, you can safely increase the MTU to
any mutually agreed value with these caveats:
1. Not all equipment behaves well with la
On 22/Jul/16 14:01, Baldur Norddahl wrote:
>
> Obviously I only need to increase my MTU by the size of the GRE header. But
> I am thinking is there any reason not to go all in and ask every peer to go
> to whatever max MTU they can support? My own equipment will do MTU of 9600
>
Hi
What is best practice regarding choosing MTU on transit links?
Until now we have used the default of 1500 bytes. I now have a project were
we peer directly with another small ISP. However we need a backup so we
figured a GRE tunnel on a common IP transit carrier would work. We want to
avoid
the MTU values configured in the following order; PE's
egress interface to P1, P1 ingress interface, P1 egress interface, P2
ingress, P2 egress and eventually GW ingress.
Q1: What do you think would be the impact in terms of data-plane traffic
(HTTP/s browsing, Video streaming etc), trave
Suppose you have the below network topology, where PE is connected to
P1, P1 is connected to P2 and P2 is connected to GW, all through 1G links.
[PE]-15001500-[P1]-16001600-[P2]-15001600-[GW]
The numbers represent the MTU values configured in the
Suppose you have the below network topology, where PE is connected to
P1, P1 is connected to P2 and P2 is connected to GW, all through 1G links.
[PE]-15001500-[P1]-16001600-[P2]-15001600-[GW]
The numbers represent the MTU values configured in the following
MTU Flow-label (related to
draft-v6ops-pmtud-ecmp-problem-01)
Date: Mon, 10 Nov 2014 11:31:52 +0100
From: Jeroen Massar
Organization: Massar
To: i...@ietf.org, v6...@ietf.org
Hola folks (and folks in BCC ;),
With the recent Google and Akamai outages (latter still ongoing afaik),
it came to
Hi everybody,
I have change my core router from 7206 VXR to 7606 with RSP720 since last 1
month.
I had GRE Tunnel in 7206 with one of my regions with this config:
interface Tunnel1
> ip mtu 1500
> ip policy route-map clear-df
I have copy this config to new 7606 with the same config but
reach wp.com content over
>> IPv6.
>>
>> IPv4 content does work fine, using the IPv6 literal returns a 404 which is
>> small enough to fit in a smaller 1480 byte MTU.
>>
>> I have another test site that has a clean 1500 byte mtu and I can fetch the
>> s0.wp.c
On Nov 6, 2012, at 4:33 AM, Seth Mos wrote:
> Hi,
>
> Since about a week or so it's become impossible to reach wp.com content over
> IPv6.
>
> IPv4 content does work fine, using the IPv6 literal returns a 404 which is
> small enough to fit in a smaller 1480 byte MTU
> Since about a week or so it's become impossible to reach wp.com content
> over IPv6.
>
> IPv4 content does work fine, using the IPv6 literal returns a 404 which
> is small enough to fit in a smaller 1480 byte MTU.
>
> I have another test site that has a clean 150
On 2012-11-06 13:33, Seth Mos wrote:
> Hi,
>
> Since about a week or so it's become impossible to reach wp.com content
> over IPv6.
>
> IPv4 content does work fine, using the IPv6 literal returns a 404 which
> is small enough to fit in a smaller 1480 byte MTU.
>
&g
> Is anyone else experiencing similar issues?
Not from here (AS 2116, Norway). No problem getting up the web page,
tcpdump shows MSS 1440.
> My traceroute shows they are employing a CDN for s0.wp.com, so not
> everyone might be affected.
>
> 7 asd2-rou-1022.NL.eurorings.net (2001:680:0:800f:
On Nov 6, 2012 6:35 AM, "Seth Mos" wrote:
>
> Hi,
>
> Since about a week or so it's become impossible to reach wp.com content
over IPv6.
[snip]
> It looks like tunneled IPv6 users might be in hurt here.
>
> Is anyone else experiencing similar issues?
I've definitely had problems from my home netw
Hi,
Since about a week or so it's become impossible to reach wp.com content
over IPv6.
IPv4 content does work fine, using the IPv6 literal returns a 404 which
is small enough to fit in a smaller 1480 byte MTU.
I have another test site that has a clean 1500 byte mtu and I can fetch
t
Hi Chris,
> -Original Message-
> From: Chris Woodfield [mailto:rek...@semihuman.com]
> Sent: Monday, October 29, 2012 4:40 PM
> To: Templin, Fred L
> Cc: William Herrin; Ray Soucy; NANOG list
> Subject: Re: IP tunnel MTU
>
> True, but it could be used as an alt
On 2012-10-30 11:19, Sander Steffann wrote:
> Hi,
>
Certainly fixing all the buggy host stacks, firewall and compliance
devices to realize that ICMP isn't bad won't be hard.
>>>
>>> Wait till you get started on "fixing" the "security" consultants.
>>
>> Ack. I've yet to come across a *
Hi,
>>> Certainly fixing all the buggy host stacks, firewall and compliance devices
>>> to realize that ICMP isn't bad won't be hard.
>>
>> Wait till you get started on "fixing" the "security" consultants.
>
> Ack. I've yet to come across a *device* that doesn't deal properly with
> "packet t
>> Certainly fixing all the buggy host stacks, firewall and compliance devices
>> to realize that ICMP isn't bad won't be hard.
>
> Wait till you get started on "fixing" the "security" consultants.
Ack. I've yet to come across a *device* that doesn't deal properly with
"packet too big". Lots (
points may send
packets a little larger than 1280B, which means physical link
MTU of 1500B or a little smaller than that is enough for
nested tunnels.
Thus, no new tunneling protocol is necessary.
The harder part of the job is to disable PMTUD on all the
IPv6 implementations.
> I have also heard
gmentation.
>
> That is in fact what SEAL is doing, but there is no guarantee
> that the size of the largest fragment is going to be an accurate
> reflection of the true path MTU. RFC1812 made sure of that when
> it more or less gave IPv4 routers permission to fragment packets
>
, but there is no guarantee
that the size of the largest fragment is going to be an accurate
reflection of the true path MTU. RFC1812 made sure of that when
it more or less gave IPv4 routers permission to fragment packets
pretty much any way they want.
Thanks - Fred
fred.l.temp...@boeing.com
On Mon, Oct 29, 2012 at 10:54 AM, Ray Soucy wrote:
> The core issue here is TCP MSS. PMTUD is a dynamic process for
> adjusting MSS, but requires that ICMP be permitted to negotiate the
> connection. The realistic alternative, in a world that filters all
> ICMP traffic, is to manually rewrite the
bmann...@vacation.karoshi.com wrote:
you mean its safe to turn off the VPNs?
/bill
Quite the reverse.
Joe
so its tunnels all the way down... maybe we should just go back to
a circuit oriented network, eh?
/bill
Its not safe to turn on VPNs.
Joe
On Mon, Oct 29, 2012 at 04:44:40PM -0400, Joe Maimon wrote:
>
>
> bmann...@vacation.karoshi.com wrote:
> >On Mon, Oct 29, 2012 at 03:46:57PM -0400, Joe Maimon wrote:
> >>
> >>
> >>Templin, Fred L wrote:
> >>
> >>>Yes; I was aware of
Jared Mauch wrote:
ICMP is just not the way it is ever going to work.
I wish you luck in getting your host IP stacks to work properly without ICMP,
especially as you deploy IPv6.
- Jared
Precisely the state we are in. Looking for luck.
Joe
> I wish you luck in getting your host IP stacks to work properly without
> ICMP, especially as you deploy IPv6.
>From what I've heard, ICMPv6 is already being filtered, including
PTBs. I have also heard that IPv6 fragments are also being dropped
unconditionally along some paths. So, if neither IC
On Oct 29, 2012, at 4:43 PM, Joe Maimon wrote:
>
>
> Jared Mauch wrote:
>>
>> On Oct 29, 2012, at 3:46 PM, Joe Maimon wrote:
>>
>>>
>>>
>>> Templin, Fred L wrote:
>>>
>>>> Yes; I was aware of
bmann...@vacation.karoshi.com wrote:
On Mon, Oct 29, 2012 at 03:46:57PM -0400, Joe Maimon wrote:
Templin, Fred L wrote:
Yes; I was aware of this. But, what I want to get to is
setting the tunnel MTU to infinity.
Essentially, its time the network matured to the point where
inter
Jared Mauch wrote:
On Oct 29, 2012, at 3:46 PM, Joe Maimon wrote:
Templin, Fred L wrote:
Yes; I was aware of this. But, what I want to get to is
setting the tunnel MTU to infinity.
Essentially, its time the network matured to the point where inter-networking
actually works (again
On Mon, Oct 29, 2012 at 03:46:57PM -0400, Joe Maimon wrote:
>
>
> Templin, Fred L wrote:
>
> >Yes; I was aware of this. But, what I want to get to is
> >setting the tunnel MTU to infinity.
>
>
> Essentially, its time the network matured to the point where
On Mon, Oct 29, 2012 at 4:01 PM, Jared Mauch wrote:
>
> On Oct 29, 2012, at 3:46 PM, Joe Maimon wrote:
>
>>
>>
>> Templin, Fred L wrote:
>>
>>> Yes; I was aware of this. But, what I want to get to is
>>> setting the tunnel MTU to infinity.
&g
On Oct 29, 2012, at 3:46 PM, Joe Maimon wrote:
>
>
> Templin, Fred L wrote:
>
>> Yes; I was aware of this. But, what I want to get to is
>> setting the tunnel MTU to infinity.
>
>
> Essentially, its time the network matured to the point where inter-ne
Templin, Fred L wrote:
Yes; I was aware of this. But, what I want to get to is
setting the tunnel MTU to infinity.
Essentially, its time the network matured to the point where
inter-networking actually works (again), seamlessly.
I agree.
Joe
Hi there,
I have the same problem in my network, I have GRE tunnel for transfering
users real internet traffic, they have problems with browsing websites like
yahoo.com or microsoft.com.
I had to set ip mtu 1500 to solve it, and it occurs fragmantation...
Thanks
On Mon, Oct 29, 2012 at 10:47 PM
1 - 100 of 163 matches
Mail list logo
