sounds to me like a lab scenario. and while it may not be a good idea in a
production network, it should still work. gonna try labbing it up as well.
what code versions you running, Adam?
Charles
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Feger, J
On Thursday, 2002-10-10 at 00:55 ZE2, Iljitsch van Beijnum
<[EMAIL PROTECTED]> wrote:
> You can also get around this by making the first hop the one with the
> lowest MTU. This is no fun for ethernet-connected stuff, but for dial-up
> this is easy. Then this box will announce a smaller TCP MSS w
Not the first time one of our clients has been impacted by AOL, nor
the first time AOL has failed respond to requests/complaints.
Though this isn't a DDOS like previous AOL-based network abuse, and
probably isn't a dictionary attack, it is placing considerable
strain on a couple of leased lines
Greetings
Does anyone know if AOL blocks the capability to use a VPN client
over their DUI service?
Sorry if this is off topic...
GW
Title: RE: Who does source address validation? (was Re: what's that smell?)
> -Original Message-
> From: Jared Mauch [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 10, 2002 12:59 PM
> To: Iljitsch van Beijnum
> Cc: Richard A Steenbergen; [EMAIL PROTECTED]
> Subject: Re: Who does
On Thu, Oct 10, 2002 at 06:36:33PM +0200, Iljitsch van Beijnum wrote:
> So what then if someone runs a secure tunnel over wireless over a PPPoE
> over ADSL using mobile IPv6 that runs over a tunnel or two ad nauseum
> until the headers get bigger than 374 bytes? Then you'll have your problem
> ri
On Thu, 10 Oct 2002, Richard A Steenbergen wrote:
> Even Windows 2000+ includes blackhole detection which will eventually
> remove the DF bit if packets aren't getting through and ICMP messages
> aren't coming back, something many unixes lack.
Wow, now I'm impressed. And what about the 1999 oth
On Thu, Oct 10, 2002 at 01:06:15AM -0400, [EMAIL PROTECTED] wrote:
> On Wed, 09 Oct 2002 23:05:59 BST, "Stephen J. Wilcox" said:
>
> > On a related issue (pMTU) I recently discovered that using a link with MTU <
> > 1500 breaks a massive chunk of the net - specifically mail and webservers who
>
I am not sure what is happening for you, but as a general rule of thumb I
don't run per-packet load sharing on circuits that are not 'the same'.
The need for packet re-ordering goes way up when you are running
per-packet on two types of circuit. Are the circuits provisioned for the
same speed at
At 10:43 PM 09-10-02 -0700, Steve Francis wrote:
>[EMAIL PROTECTED] wrote:
>>My personal pet peeve is the opposite - we'll try to use pMTU, some
>>provider
>>along the way sees fit to run it through a tunnel, so the MTU there is
>>1460
>>instead of 1500 - and the chuckleheads number the tunnel e
On Thu, 10 Oct 2002 [EMAIL PROTECTED] wrote:
> On Thu, 10 Oct 2002 00:55:24 +0200, Iljitsch van Beijnum said:
>
> > You can also get around this by making the first hop the one with the
> > lowest MTU. This is no fun for ethernet-connected stuff, but for dial-up
> > this is easy. Then this box
per-packet load sharing in cef / dcef just doesn't seem to want to work.
I have two 7500s joined by a frame relay link and a fast ethernet.
Traffic is coming in to one of the 7500s via a third link, and goes
to a loopback on the second 7500.
I have cef turned on
I have "ip load-sharing per-pa
12 matches
Mail list logo
