> > > lesson learned:
> > > stop using /makeshift/ layer3 switches (without naming vendor) to run
> > > L3 core
more generally... "if you want routing, buy a router."
i have a hybrid switer that i'm very happy with. at my house, that is.
(the idea of using one in commerce or production gives me
On Tue, 20 Jan 2004, Rubens Kuhl Jr. wrote:
> Not all L3-switches are flow-based; prefix-based ones should do just fine.
> Can people add/correct this initial list ?
>
> Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A)
> Prefix-based: Foundry with JetCore modules, Cisco
On Tue, Jan 20, 2004 at 10:16:03PM -0200, Rubens Kuhl Jr. wrote:
>
> Not all L3-switches are flow-based; prefix-based ones should do just fine.
> Can people add/correct this initial list ?
>
> Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A)
> Prefix-based: Foundry wit
On Tue, 20 Jan 2004, Rubens Kuhl Jr. wrote:
> > > Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with
> Sup1(A)
> > > Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600
> with
> > > Sup2(A), Sup3(A/BXL)
> > Where do the Extreme and Juniper fit into this?
>
> Pri
In message <[EMAIL PROTECTED]>, "Alexei Roudnev" writes:
>
>
>>
>> Uhm, that would be wrong. This is simply "security through obscurity".
>Yes, it is wrong for the _smart books_. But it works in real life. Of
>course, it should not be the last line of defense; but it works as a first
>line very e
> > Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with
Sup1(A)
> > Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600
with
> > Sup2(A), Sup3(A/BXL)
> Where do the Extreme and Juniper fit into this?
Private and public answers to my question indicate that both Su
On Tuesday 20 January 2004 04:16 pm, Rubens Kuhl Jr. wrote:
> Not all L3-switches are flow-based; prefix-based ones should do just fine.
> Can people add/correct this initial list ?
>
> Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A)
> Prefix-based: Foundry with JetCore
yes in concur.. prefix based ones (like FIB) are fine.
unfortunately some models from some vendors (tisk tisk) who use
slow process path to reprogram the CAM per flow can be quite painful
during situations like random dest. dos attacks and worms..
add the
Not all L3-switches are flow-based; prefix-based ones should do just fine.
Can people add/correct this initial list ?
Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A)
Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with
Sup2(A), Sup3(A/BXL)
Ruben
* [EMAIL PROTECTED] (Dave Israel) [Tue 20 Jan 2004, 18:48 CET]:
> On 1/20/2004 at 09:18:07 -0800, Alexei Roudnev said:
[..]
>> - unpatched sshd on port 30013 - safety is 7 (higher) because no one
>> automated script can find it, and no one manual scan find it in reality
> Actually, an automated sc
lesson learned:
stop using /makeshift/ layer3 switches (without naming vendor) to run
L3 core
-J
On Tue, Jan 20, 2004 at 02:22:52PM -0800, Brent Van Dussen wrote:
>
> Well folks, since the middle of August I've been tracking the spread and
> subsequent efforts by our co
: : What kind of effects did everyone see from this devastating worm and what
: : lessons did we learn for preventing network downtime in the future?
:
:
: Proper network design is a good thing... ;-)
Before I get flamed, I should say that is for end-user networks, not the
normal BANs (Big A$$
: What kind of effects did everyone see from this devastating worm and what
: lessons did we learn for preventing network downtime in the future?
Proper network design is a good thing... ;-)
scott
Flow based "attacks" can kill flow based routers.
James Edwards
Routing and Security Administrator
[EMAIL PROTECTED]
At the Santa Fe Office: Internet at Cyber Mesa
Store hours: 9-6 Monday through Friday
505-988-9200 SIP:1(747)669-1965
Well folks, since the middle of August I've been tracking the spread and
subsequent efforts by our community to stop the nachia/welchia infection
that took down so many networks.
Sadly, by my estimations, only about 20-30% of infected hosts were
cleaned. After Jan 1, 2004 it appears that the t
In message <[EMAIL PROTECTED]>, William Allen Simpson writes:
>
>Eriks Rugelis wrote:
>>
>> On the other hand, if your environment consists of a large number (100's) of
>> potential tapping points, then you will quickly determine that in-line taps
>> have very poor scaling properties.
>>
Eriks Rugelis wrote:
>
> On the other hand, if your environment consists of a large number (100's) of
> potential tapping points, then you will quickly determine that in-line taps
> have very poor scaling properties.
> a) They are not rack-dense
> b) They require external power wa
> PS. Sniffer... there are not any way to detect sniffer in the non-switched
> network, and there is not much use for sniffer in switched network, if this
> network is configured properly and is watched for the unusial events.
depends on brand and model of switch
$ portinstall ds
Remote power on :P
-HenryMichel Py <[EMAIL PROTECTED]> wrote:
> Alexei Roudnev wrote:> - turn off power - safety is 10. Secure> system, is a dark system.I have to disagree on this one; there is WOL (Wake-up On Lan), thesystem can be lit remotely.- turn off power - safety is 9- Unplug all cords -
On 1/20/2004 at 09:18:07 -0800, Alexei Roudnev said:
>
>
> >
> > Uhm, that would be wrong. This is simply "security through obscurity".
> Yes, it is wrong for the _smart books_. But it works in real life. Of
> course, it should not be the last line of defense; but it works as a first
> line ve
> Alexei Roudnev wrote:
> - turn off power - safety is 10. Secure
> system, is a dark system.
I have to disagree on this one; there is WOL (Wake-up On Lan), the
system can be lit remotely.
- turn off power - safety is 9
- Unplug all cords - safety is 10
Michel.
Correct. Microsoft's problem is not security alone, but monoculture. If we
have all systems around Windows2003, we are exposed to risk of devastating
virus attack. No matter, how secure this Windows2003 is.
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAI
>
> Uhm, that would be wrong. This is simply "security through obscurity".
Yes, it is wrong for the _smart books_. But it works in real life. Of
course, it should not be the last line of defense; but it works as a first
line very effectively.
If I rate safety as a number (10 is the best, 0 is t
Scott C. McGrath
On Tue, 20 Jan 2004, Eriks Rugelis wrote:
>
> Sean Donelan wrote:
> > Assuming lawful purposes, what is the best way to tap a network
> > undetectable to the surveillance subject, not missing any
> > relevant data, and not exposing the installer to
Sean Donelan wrote:
> Assuming lawful purposes, what is the best way to tap a network
> undetectable to the surveillance subject, not missing any
> relevant data, and not exposing the installer to undue risk?
'Best' rarely has a straight-forward answer. ;-)
Lawful access is subject to many of t
Agreed, vendor lock in is a very big problem, what the economists would call
increasing returns. Interestingly most of the research on the subjest finds that a
vendor achieves "lock in" and a dominant market position not by being the most
competitive product. Random historical accident, polici
26 matches
Mail list logo
