netdev
[Top] [All Lists]

Re: 2.4.1: TCP assertion failed

To: Cacophonix <cacophonix@xxxxxxxxx>
Subject: Re: 2.4.1: TCP assertion failed
From: jamal <hadi@xxxxxxxxxx>
Date: Sun, 18 Feb 2001 13:35:39 -0500 (EST)
Cc: <kuznet@xxxxxxxxxxxxx>, Chris Wedgwood <cw@xxxxxxxx>, <netdev@xxxxxxxxxxx>
In-reply-to: <20010218182024.6277.qmail@xxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Policy management sounds like hell in the scenario you describe (if you
cant enforce single point of entry/exit into the network for a flow)
Mostly because you have stateful policies that dont get propagated between
the devices that provide entry into the network.
Note that this will also be difficult to do for ordinary QoS but packeteer
mucking with headers makes it a _lot_ more difficult.


cheers,
jamal


On Sun, 18 Feb 2001, Cacophonix wrote:

> Depends. I've seen networks where the device was on the ethernet prior to
> the routers attaching to the WAN - in larger networks there tend to be 
> multiple
> such ethernet "hub LANs" and multiple WAN links for redundancy. (BTW, I'm
> referring to the case where the device is on the WAN edge of the client site,
> but could be in the server site as well)
>
> The workaround to get the packeteer in the path in both directions was to play
> around with ospf costs on the LAN interfaces of the router.
>
> Of course, as you mention, a device that does naughty things could have 
> problems
> in the simple cases as well - just pointing out cases where I've seen failure 
> in
> the past...
>




<Prev in Thread] Current Thread [Next in Thread>