n't that much unless
you're suffering from hardware routing table limitations. In my world
the cost of a false positive match would far outweigh the cost of
upgrading hardware. YMMV.
Do you have a git repo?
On Sun, Oct 27, 2019 at 9:58 PM Joe Maimon <mailto:jmai...@jmaimon.com
is welcome to it.
Joe
Joe Maimon wrote:
Does anyone have or seen any such tool? I have a script that seems to
work, but its terribly slow.
Currently I can produce aggregated subnets that can be mising up to a
specified number of individual addresses. Which can be fed back in for
multiple passes
> On Sun, Oct 27, 2019 at 3:09 PM Joe Maimon wrote:
>>
>
> your aim is to get to maximum aggregation .. with some overage, like
> 90% of a /24 ?
> so missing like 25 addresses in a whole /24.. (for instance)
I would be happy to get /29's missing 3 /28's missing
2.0/24
> 203.0.113.0/32
> 203.0.113.2/31
> 203.0.113.4/30
> 203.0.113.8/29
> 203.0.113.16/28
> 203.0.113.32/27
> 203.0.113.64/26
> 203.0.113.128/25
> 203.0.114.0/23
> 203.0.116.0/22
> 203.0.120.0/21
> 203.0.128.0/17
> 203.1.0.0/16
> 203.2.0.0/15
> 203.4.0.0/14
Does anyone have or seen any such tool? I have a script that seems to
work, but its terribly slow.
Currently I can produce aggregated subnets that can be mising up to a
specified number of individual addresses. Which can be fed back in for
multiple passes.
Doing RTBH on individual /32 does not sc
Ethan O'Toole wrote:
If it’s in an interduct by itself, how much would the square footage per
month occupied by the average cross connect be worth?
These big datacenter companies are REITs. Similar to self-storage
units and apartment buildings, they exist to extract as much money as
possib
Michel Py wrote:
Aaron Gould wrote :
Hi, does anyone know how to use flow data to trigger a rtbh (remotely triggered
blackhole) route using bgp ? ...I'm thinking we could use
quagga or a script of some sort to interact with a router to advertise to bgp
the /32 host route of the victim under
Hey All,
Centralized logging is a good thing. However, what happens is that every
repetitive, annoying but not (usually) important thing fills up the log
with reams of what you are not looking for.
Networks are a noisy place and silencing every logged condition is
impractical and sometimes u
Owen DeLong wrote:
200 might be optimistic, agreed. I think 100 is pretty well assured absent
something much more profligate than current policies.
Profligacy based on the assumption of exhaustion impossibility needs to
be avoided. Agreed.
we've run a number conversion / renumbering on
valdis.kletni...@vt.edu wrote:
On Wed, 20 Dec 2017 18:15:44 -0500, Joe Maimon said:
There is plenty more to wonder about, for example, will the rest of the
unicast space get Class E'd?
That's a non-starter, as pretty much all the gear out there has code that says
'Clas
William Herrin wrote:
It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 orders
of magnitude to just 9 orders of magnitude. Your link which needed at most
2 bits of IPv4 address space now consumes 64 bits of IPv6 address space.
Then we do /48s from which the /64s are assigned
There is a distance to travel between cant and cant effectively.
Perhaps they can share how they ever so effectively have solved this
conundrum. After all, they are apparently not getting any abuse reports
ever. As an operator of several open resolvers (with rate limiting and
automatic mitigat
Tony Finch wrote:
Joe Maimon wrote:
www.kissimmee.org
Windows appears to believe the rfc2308 type 2 response,
RFC 2308 isn't relevant to this domain. The responses aren't NXDOMAIN, so
section 2.1 doesn't apply, and the response includes answers, so section
2.2 doens't
Mark Andrews wrote:
Nameresovle.com's servers are returning answers that can be seen
as a cache poisioning attempt. They are NOT authorative for
".hosting" but have been configured as if they are. This is a big
NO NO. You don't configure youself as authoritative for a zone
that has not bee
William Herrin wrote:
On Wed, Aug 10, 2016 at 2:05 PM, Joe Maimon wrote:
www.kissimmee.org
Windows 2008 dns cannot resolve it.
BIND can.
Hi Joe,
Does Windows 2008 like anything in the "hosting" TLD?
I notice that the nameresolve.com servers returning the CNAME to
www.kissimmee.org
Windows 2008 dns cannot resolve it.
BIND can.
Windows appears to believe the rfc2308 type 2 response, even though
recursing the CNAME results in a different authority, ns, and A
response, which I assuming is why BIND returns the answer.
I must be missing a switch somewhere
I would appreciate it if anyone could put me in touch or send me any
tips to deal with packet loss and problems routing to google, but only
along certain paths from certain points in the network (like as in ecmp
problems) from as21719
I would like to rule out local issues if possible and that
You can use a 2600 or 2800 with the 16 port serial module.
Stephen Satchell wrote:
On 03/08/2016 07:30 AM, greg whynott wrote:
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 por
Mark Tinka wrote:
You may want to signal failure more quickly than BGP's own timers can
handle.
I dont want to churn a full table any quicker then BGP timers. And if
you choose to run that ebgp loopback multihop on the same router, you
can track routes and interfaces in realtime, to th
Mark Tinka wrote:
On 25/Jan/16 20:13, Joe Maimon wrote:
Maybe not for some people, but I have a hard time understanding why
one extra ebgp session is such a novel concept for all you networking
folk.
It's not that novel - I share my view of the Internet with various
ind
Mark Tinka wrote:
On 25/Jan/16 12:15, Joe Maimon wrote:
No static routes, dedicated BGP routed loopbacks on each side from an
allocated /31, strict definitions on which routes belong to which
session. Its gone about very properly.
And all of this is simpler than having a native BGP
Mark Tinka wrote:
On 22/Jan/16 22:28, Joe Maimon wrote:
I like that setup. And it never struck me as crazy. In fact, their
implementation avoids all multihop setup shortcuts and is quite purist
from a routing standpoint.
First time I've heard that...
Mark.
No static r
Owen DeLong wrote:
Crazy multihop BGP setups
I like that setup. And it never struck me as crazy. In fact, their
implementation avoids all multihop setup shortcuts and is quite purist
from a routing standpoint.
The multihop approach gives you the option of where to slice and dice
yo
Apparently there is still raison d'etre for everyone not a giant telco.
We placed the circuit with tagging expected for the service vlan.
We got it delivered without.
We requested it be changed.
Apparently that takes a change order, which when it is finally filed,
takes 7-10BD to complete.
So we all know that its much more difficult to diagnose using that tool
than just reading its output more often than not.
Whats usually more important is correlation, over time and at any
specific time.
While tools such as mtr provide over time viewpoints, what can be run,
user style, that w
Owen DeLong wrote:
On Jul 16, 2015, at 15:29 , Joe Maimon wrote:
All I am advocating is that if ever another draft standard comes along to
enable people to try and make something of it, lead follow or get out of the
way.
Sometimes good leadership is knowing when to say “not just no
Baldur Norddahl wrote:
On 17 July 2015 at 00:29, Joe Maimon wrote:
All I am advocating is that if ever another draft standard comes along to
enable people to try and make something of it, lead follow or get out of
the way.
If I understand correctly you want someone (not you) to write a
Lee Howard wrote:
>
>
> On 7/16/15, 4:32 PM, "Joe Maimon" wrote:
>
>>
>>
>> Lee Howard wrote:
>>>
>>> So, you would like to update RFC 1112, which defines and reserves Class
>>> E?
>>> That¹s easy enough. If
John Levine wrote:
Just as nobody is preventing you from going ipv6 only right now, I
advocate against hindering anybody going ipv4 only for as long as they
want/can.
But you're asking other people to spend their own time and money to
change their equipment to handle class E. For reasons
Lee Howard wrote:
I don¹t see anybody hindering any efforts; I don¹t see any efforts.
There were efforts in the past. I am highlighting our malfeasance as a
community in our past behavior. I have little hope of it changing in the
future, but I can vent about it every couple years or so.
Jacques Latour wrote:
Hi,
Dual stack is where we need to go 'now', but we need to think about the future
where we run an IPv6 only stack and stop thinking how to leverage, extend,
expand and create ugly IPv4 solutions. IPv4 is done; it served its purpose
well, thank you. We need a date wher
Doug Barton wrote:
Joe,
In this post, and in your many other posts today, you seem to be
asserting that this would work if "$THEY" would just get out of the way,
and let it work. You've also said explicitly that you believe that this
is an example of top-down dictates. I know you may find th
Jared Mauch wrote:
This isn’t really a giant set of naysayers IMHO, but there is enough embedded
logic in devices that it doesn’t make that much sense.
Enough to scuttle all previous drafts.
linux
a little google comes up with this
http://www.gossamer-threads.com/lists/linux/kernel/86
Owen DeLong wrote:
On Jul 15, 2015, at 10:24 , Joe Maimon wrote:
I suspect a 16 /8 right about now would be very welcome for everybody other
then the ipv6 adherents.
But it wouldn’t be right now. It would be after everyone put lots of effort
into updating lots of systems so that they
John Levine wrote:
I suspect a 16 /8 right about now would be very welcome for everybody
other then the ipv6 adherents.
It would, if the software supported it. But it doesn't.
Is there any reason to think the world would update its TCP stacks to
handle those extra IPv4 addresses any sooner t
Doug Barton wrote:
On 7/15/15 10:24 AM, Joe Maimon wrote:
I suspect a 16 /8 right about now would be very welcome for everybody
other then the ipv6 adherents.
Globally we were burning through about a /8 every month or two in "the
good old days." So in the best case scenario we
Ricky Beam wrote:
On Wed, 15 Jul 2015 15:20:08 -0400, Owen DeLong wrote:
That's the big difference - IPv6 has been designed to provide abundant
address space.
There is no amount of fixed address space that can't be consumed with
stupid allocation policies.
True. However, are you making th
joel jaeggli wrote:
On 7/15/15 10:24 AM, Joe Maimon wrote:
The jury is still out on class E, but the verdict is in for the
community who created it.
joel@ubuntu:~$ uname -a
Linux ubuntu 3.8.0-44-generic #66~precise1-Ubuntu SMP Tue Jul 15
04:01:04 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Mark Andrews wrote:
In message
We don't use Class E because were using up IPv4 space too quickly
to make it worthwhile to make it work cleanly for everyone.
That is a self fulfilling prophecy.
I suspect a 16 /8 right about now would be very welcome for everybody
other then the ipv6 adhe
Owen DeLong wrote:
JimBob’s ISP can apply to ARIN for a /16
Like I said, very possibly not a good thing for the address space.
There has been tomes on this topic. There will continue to be many more.
That is because many of you continue in trying to defend the following
concept.
customer subnet bits == isp customers bits
So now, the ISP is supposed to put some effort and gain more bits. Why
not the customer?
Its
Beeman, Davis wrote:
rather the authoritative name server in these domains is the rouge DNS server
in use by the bad actor running a botnet.
Davis Beeman
Network Security Engineer
Somebody must be registering these domain names.
And I should be able to compile a list of the auth servers
Dobbins, Roland wrote:
On Feb 19, 2014, at 1:07 PM, Joe Maimon wrote:
There are ways to deal with it on resolvers as well, like RRL and IDS and
iptables
None of these things work well for recursive resolvers; they cause more
problems than they solve.
Whatever I am doing appears to
Owen DeLong wrote:
On Feb 18, 2014, at 9:48 PM, Joe Maimon wrote:
This assumes several facts not in evidence:
1. It is an attack.
2. It is deliberate
3. There is a target
4. It is more effective than others
On what do you base those assumptions? To me this looks to
Dobbins, Roland wrote:
On Feb 19, 2014, at 12:48 PM, Joe Maimon wrote:
What I cant figure out is what is the target and how this attack method is any
more effective then the others.
The target appears to be the authoritative servers for the domain in question,
yes?
I dont think so
Dobbins, Roland wrote:
On Feb 19, 2014, at 12:44 PM, Joe Maimon wrote:
Get back to me when the same cant be done with auth servers.
There are ways to deal with it on authoritative servers, like RRL.
There are ways to deal with it on resolvers as well, like RRL and IDS
and iptables
George Herbert wrote:
Right. Nonzero chances that you (Joe's site) are the target...
Also, check if you have egress filtering of spoofed addresses below these
DNS resources, between them and any user objects. You could be sourcing
the spoofing if not...
It seems to me that the same|similar
Doug Barton wrote:
On 02/18/2014 07:59 PM, Joe Maimon wrote:
Are you running open resolvers?
Yes
If so, please stop doing that,
No
it's
widely known to be a bad idea for over a decade now,
At this point, doing anything on the internet is a bad idea.
and you are
providin
Dobbins, Roland wrote:
On Feb 19, 2014, at 10:08 AM, Joe Maimon wrote:
What is the purpose of this?
Resource-exhaustion attack against the recursive DNS?
On anything that is going to stay open, not even close.
Doug Barton wrote:
On 02/18/2014 07:08 PM, Joe Maimon wrote:
Thousand of queries with thousands of source ip addresses.
Pardon if I missed a memo, but how are your resolver systems receiving
these thousands of very different source addresses?
Doug
Thousands of queries _from_ thousands
Mark Andrews wrote:
What is the purpose of this?
Indirect attack on the 5kkx.com servers?
18-Feb-2014 21:45:24.982 queries: info: client 38.89.3.12#19391: query:
swe.5kkx.com IN A + (66.199.132.5)
I have seen dozens of different second level parts.
How is this any more effective then s
Hey all,
DNS amplification spoofed source attacks, I get that. I even thought I
was getting mitigation down to acceptable levels.
But now this. At different times during the previous days and on
different resolvers, routers with proxy turned on, etc...
Thousand of queries with thousands of
Adam Greene wrote:
Hi guys,
I have a customer who peers via eBGP with Lightpath aka Cablevision (AS
6128) and Level3 (AS 3356) and wants to do some dual-WAN router redundancy.
I am not optimistic for your odds in having 6128 do anything other than
/30 for you.
(Though even then you st
Tim Durack wrote:
I was under the impression Cogent no longer did the multi-hop BGP thing,
but then I got a copy of their NA user guide, and saw the peer-a/peer-b
configuration. Not a fan.
Anyone know if this is still required for Cogent IP transit service?
(on/off list is fine.)
A/B multih
Constantine A. Murenin wrote:
On 28 January 2013 13:57, david peahi wrote:
http://www.nbn.gov.au/2012/12/03/did-you-know-that-our-copper-network-is-being-switched-off/
Do they have any customers object?
I recall a few recent stories about Verizon having problems after
Sandy with NYC cust
. The first nationwide 4G network.
Original message
From: Brent Jones
Date: 01/28/2013 10:07 AM (GMT-08:00)
To: Joe Maimon
Cc: North American Networking and Offtopic Gripes List
Subject: Re: Looking for success stories in Qwest/Centurylink land
s/CenturyLink/ATT and I'v
Eugeniu Patrascu wrote:
On Sat, Jan 26, 2013 at 11:26 AM, Pavel Dimow wrote:
As being personally involved deploying IPv6 on an enterprise network,
here's how I did it (keeping in mind the fact that we have our own
ASN):
I suggest this be step 0
- get a /48 PI from the local LIR
And t
Anybody have some happy success stories to share about service in Qwest
service area post Centurylink acquisition?
Unfortunately the ones I have contain more humor than success.
Story #1
Ethernet/Fiber service near Tampa ordered via partner, misordered as
MPLS, re-ordered as vpls.
Delivered
Lee Howard wrote:
If an ISP is so close to running out of addresses that they need CGN,
let's say they have 1 year of addresses remaining. Given how many ports
apps use, recommendations are running to 10:1 user:address (but I could
well imagine that increasing to 50:1). That means that for e
Lee Howard wrote:
You are welcome to deploy it if you choose to.
Part of the reason I'm arguing against it is that if everyone deploys it,
then everyone has to deploy it. If it is seen as an alternative to IPv6
by some, then others' deployment of IPv6 is made less useful: network
effect. Als
Owen DeLong wrote:
Clearly we have run out of trickery as multiple layers of NAT stumps even the
finest of our tricksters.
Yes, we can dedicate thousands more developer hours to making yet more
extensions to code to work around yet more NAT and maybe make it sort of kind
of work almost a
Owen DeLong wrote:
And this is where you run off the rails… You are assuming that NAT today
and CGN provide similar functionality from an end-user perspective.
To the extent that CGN functions like the clueless linksys daisy-chain,
then yes it does.
The reality is that they do not. CGN is
valdis.kletni...@vt.edu wrote:
On Tue, 15 Jan 2013 14:52:24 -0500, Joe Maimon said:
I only ever say class-c sized. And only when trying to communicate with
the slash-whats.
Your mistake there is trying to communicate with people who have been in
networking long enough to understand "
joel jaeggli wrote:
On 1/15/13 9:31 AM, Bruce H McIntosh wrote:
On Tue, 2013-01-15 at 17:23 +, Warren Bailey wrote:
I still call a /24 a class c too.. :/ lol
More efficient that way - "class c" uses fewer syllables than "slash
twenty four" :-)
You realize that class-c address space was
Hey All,
Its that time of the year again, and I am looking for verizon ATM/DSL
wholesale DSL ports for NY/NJ latas.
Off-list replies are welcome.
Thanks,
Joe
Owen DeLong wrote:
less than 60% of the internet will still be IPv4 at that time.
Do you mean "IPv4" or "IPv4 Only"?
Because unless the remaining percentage of IPv4 is noticeably less
usable, it will still not incur any user demand, and IPv6 is still a
cost mitigation strategy, and unl
Arturo Servin wrote:
It won't.
Users do not care about IPv6 or IPv4. They want a fast and reliable
Internet connection.
Which likely decreases the network effect.
Joe
Tony Hain wrote:
Tomas Podermanski wrote:
Hi,
It seems that today is a "big day" for IPv6. It is the very first time
when
native IPv6 on google statistics
(http://www.google.com/intl/en/ipv6/statistics.html) reached 1%. Some
might say it is tremendous success after 16 years of deployi
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
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
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
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
Justin M. Streiner wrote:
On Fri, 28 Sep 2012, Joe Maimon wrote:
Just got told by a Lightpath person that in order to do BGP on a
customer gig circuit to them they would need a visio diagram (of what
I dont know).
Has anybody else seen this brain damage?
I can understand wanting to
Just got told by a Lightpath person that in order to do BGP on a
customer gig circuit to them they would need a visio diagram (of what I
dont know).
Has anybody else seen this brain damage?
Joe
TJ wrote:
Let us spin this another way. If you cannot even expect mild change such
as 240/4 to become prevalent enough to be useful, on what do you base your
optimism that the much larger changes IPv6 requires will?
Joe
Easy - Greater return on the investment; i.e. - instead of getting an I
George Herbert wrote:
We could have started it at a more opportune time in the past. We could also
have done other things like a straight IPv4-48 or IPv4-64, without the other
protocol suite foo that's delayed IPv6 rollout. Operators could have either
used larger baseball bats or more par
Leo Vegoda wrote:
There was even a dedicated mailing list. But the drafts never made it beyond
drafts, which suggests there was not a consensus in favour of an extra 18
months of IPv4 space with dubious utility value because of issues with
deploy-and-forget equipment out in the wild.
The
valdis.kletni...@vt.edu wrote:
On Wed, 19 Sep 2012 18:36:08 -0400, Joe Maimon said:
So 6-8 years to try and rehabilitate 240/4 was not even enough to try?
6 years of work
What I said is that they knew they would have had at least 6 years or
_more_ to rehabilitate it, had they made a
Doug Barton wrote:
We were already looking at the IPv4 runout problems when I was at IANA
in 2004. We already knew (in large part thanks to folks like Tony Hain
and Geoff Huston) that we'd run out in the 2010-2012 time frame, and a
lot of us pushed a lot of rocks up a lot of hills to get our
shthead wrote:
Hi all,
I have a 7200 series router (7204) here and I am trying to figure out
something with it. Currently the router has a NPE-G1 card in it, giving
it 3 gig interfaces but I need an extra gig interface on it to make 4.
Having a look around the available options are either get
Joe Maimon wrote:
Hey All,
I would greatly appreciate it if somebody would point me to the release
notes for the change I see in 15.1 where BGP neighbor route-map
configurations happen in real time, without needing any clearing, soft
or otherwise.
Much obliged.
Best,
Joe
So I opened the
David Walker wrote:
Self signed certificates does sound great and for most purposes,
certainly in this case, fulfills all the requirements. There's no need
to verify anything about me is correct other than to tie my
authentication to my account. If I fail to meet the TOS then the plug
is easil
Michael Thomas wrote:
Linkedin has a blog post that ends with this sage advice:
* Make sure you update your password on LinkedIn (and any site that you
visit on the Web) at least once every few months.
I have accounts at probably 100's of sites. Am I to understand that I am
supposed to remembe
Stephane Bortzmeyer wrote:
On Fri, Jun 08, 2012 at 03:09:04PM -0400,
Joe Maimon wrote
a message of 7 lines which said:
Is there any publicly available rate limiting for BIND?
Not as far as I know. I'm not sure it would be a good idea. BIND is
feature-rich enough.
I really hop
Dobbins, Roland wrote:
On Jun 9, 2012, at 2:09 AM, Joe Maimon wrote:
Google and Level3 manage to run open resolvers, why cant I?
Because they have probably have opsec resources you don't. If you can't defend
it/keep it from being abused, don't do it.
;>
I think
Is there any publicly available rate limiting for BIND?
How about host-based IDS that can be used to trigger rtbh or iptables?
Google and Level3 manage to run open resolvers, why cant I?
Joe
Owen DeLong wrote:
Really, no. The L3 MTU on an interface should be configured to the
lowest MTU reachable via that link without crossing a router. It's
just that simple. Anything else _IS_ a misconfiguration.
Perhaps this should be thought of as a limitation, rather then a feature.
Joe
Owen DeLong wrote:
> Given the combination of Moore's law and the deployment
> lifecycle, designs we do today in this regard can be expected
> to last ~12 years or more, so they should be prepared for
> at least 16x. At 1,600 Gbps, that puts our target maximum
> MTU up around 200M octets.
>
I
Owen DeLong wrote:
But that's a whole lot more packets than working PMTU-D to get there and
you're also waiting for all those round trips, not just the 4 timeouts.
The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at
100ms is 2.2 seconds. That's a long time to go without fi
Jeroen Massar wrote:
That indeed matches most of the corporate world quite well. That they
are heavily misinformed does not make it the correct answer though.
Either you are correct and they are all wrong, or they have a
perspective that you dont or wont see.
Either way I dont see them
Owen DeLong wrote:
Fail.
What, exactly are you saying is a failure? The single word here even in context
is
very ambiguous.
The failure is that even now, when tunnels are critical to transition, a
proper solution that improves on the IPv4 problems does not exist
And if tunnels do be
Jeroen Massar wrote:
If people want to use a tunnel for the purpose of a VPN, then they will,
be that IPv4 or IPv6 or both inside that tunnel.
Instead of having a custom VPN protocol one can do IPSEC properly now as
there is no NAT that one has to get around. Microsoft's Direct Access
do
Jeroen Massar wrote:
Tunnels therefor only should exist at the edge where native IPv6 cannot
be made possible without significant investments in hardware and or
other resources. Of course every tunnel should at one point in time be
replaced by native where possible, thus hopefully the folks p
Owen DeLong wrote:
There should be no such thing as packet fragmentation in the current
protocol. What is needed is for people to simply configure things
correctly and allow PTB messages to pass as designed.
Owen
You are absolutely correct. Are you talking about IPv4 or IPv6?
Joe
Cameron Byrne wrote:
#1 don't tunnel unless you really need to.
Tunnels are ipv4 only now?
#2 see #1
#3 use happy eyeballs, http://tools.ietf.org/html/rfc6555, Chrome has
a good implementation, but this does not solve MTU issues.
Because the initial connections are made just fine.
Joe Maimon wrote:
Looks like a tunnel mtu issue. I have not as of yet traced the
definitive culprit, who is (not) sending ICMP too big, who is (not)
receiving them, etc.
The culprit is the v6 tunnel, which wanders into v4 ipsec/gre tunnels,
which means the best fix is ipv6 mtu 1280 on the
Well, IPv6 day isnt here yet, and my first casualty is the browser on
the wife's machine, firefox now configured to not query .
Now www.facebook.com loads again.
Looks like a tunnel mtu issue. I have not as of yet traced the
definitive culprit, who is (not) sending ICMP too big, who is (no
Michael J McCafferty wrote:
Jason,
I agree with John. You can't use them as your only provider, but you
wouldn't do that with *any* provider. I will add that they answer the
phone quickly, and the person who answers usually has a clue, has access
to the routers, and can be helpful. It's one of
Owen DeLong wrote:
RWHOIS is a perfectly valid alternative to SWIP.
Owen
I actually got RWHOIS working a while back. But then faced with the
prospect of loading it up, I decided that ARIN templates were actually
easier to use.
And with their restful interface, even more so.
Unless
101 - 200 of 289 matches
Mail list logo
