Redundant network connections

Hi,

I'm looking at implementing some redundant network
connections on some
RHEL5 servers. The idea would be to be able to suffer the
loss of any
one switch the servers are connected to, and still have
everything
working.

Sounds simple, eh? 

I'm familiar with bonding on Linux, and with VLANs and LACP
in switches,
and it seems like I could achieve what I want using LACP.
The main
problem is that I have all servers connected to two
different networks
(currently eth0 to private LAN and eth1 to public LAN) and I
need to
keep PXE booting working from eth0... but only have 2
physical network
ports in most servers...

Is it possible to do what I want? Redundancy of two
different physical
networks while still be able to PXE boot for reinstalls?
Probably not...

If not, then the idea I had was the following : With 3 or
more physical
network ports, keep one just for "maintenance"
(IPMI/DRAC and PXE boot)
and bond the others with LACP, then trunk the two VLANs for
private and
public LANs on top of that. Sounds possible? (as I've never
used VLANs
on Linux, even less on top of some bonding!)

This last setup would possibly mean loosing access to the
"maintenance"
interface if a switch dies, but never loosing access to any
of the two
production networks. The switches I have in mind are Cisco
4948, which
would be stacked together, and always have LACP configured
across two
or more devices.

Has anyone done anything similar? Sounds reasonable? Any
advice?

TIA,
Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 8 (Werewolf) - Linux kernel
2.6.23.14-107.fc8
Load : 0.47 0.27 0.19

_______________________________________________
rhelv5-list mailing list
rhelv5-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/rhelv5-list

I am able to lock the screen on my RHEL 5 as a regular user
but as root it will not lock the screen when I clcik the
lock
icon.  What is the command line to do this?

Thanks,

Néstor 

_______________________________________________
rhelv5-list mailing list
rhelv5-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/rhelv5-list

On Tue, 2008-02-12 at 16:19 +0100, Matthias Saou wrote:
> If not, then the idea I had was the following : With 3
or more physical
> network ports, keep one just for
"maintenance" (IPMI/DRAC and PXE boot)
> and bond the others with LACP, then trunk the two VLANs
for private and
> public LANs on top of that. Sounds possible? (as I've
never used VLANs
> on Linux, even less on top of some bonding!)

You can certainly do this part, although it could be argued,
probably
correctly, that VLAN's are not a strong enough security
barrier on which
to mix a "Public" and "Private" network,
although those terms can mean
slightly different things to different people.  We actually
do this in a
few cases, but the "public" VLAN is already
firewalled and restricted by
application layer proxies before it's VLAN's are mixed on
the same
wire/network infrastructure with our "public"
VLAN's.

> This last setup would possibly mean loosing access to
the "maintenance"
> interface if a switch dies, but never loosing access to
any of the two
> production networks. The switches I have in mind are
Cisco 4948, which
> would be stacked together, and always have LACP
configured across two
> or more devices.

> Has anyone done anything similar? Sounds reasonable?
Any advice?

We have a similar setup with Cisco 3750's in a stack (well,
as far as
VLAN's and redundant access), however, I don't think that an
LACP
channel bonded link can span across two different switches
on a Cisco
4948.  This works on the 3750's because they stack via a
special cable
in the back and basically become a single switch, however I
think that
Cisco 4948's stack via trunk ports and still act as separate
switches,
with separate configs and switching engines, although I'd
have to look
it up to be 100% sure.  That doesn't mean you can't used use
adaptive
load balancing or simple failover across two switches (we do
a good bit
of this as well), but LACP is designed to make the links
appear as a
single link and typically can't span switches that don't
share the same
switching fabric.  That means it usually requires chassis
based switches
or stackable switches that become a single fabric via a
fabric cable
rather than connecting via ethernet trunks.

I could be wrong on the 4948 and it's capabilities, we have
a couple of
these and I'm pulling it from my memory.  I know it supports
LACP on
multiple ports within a single switch, but I'm pretty sure
it cannot be
LACP aware across multiple switches like the 3750's.

Later,
Tom


_______________________________________________
rhelv5-list mailing list
rhelv5-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/rhelv5-list

Tom Sightler wrote :

> On Tue, 2008-02-12 at 16:19 +0100, Matthias Saou
wrote:
> > If not, then the idea I had was the following :
With 3 or more physical
> > network ports, keep one just for
"maintenance" (IPMI/DRAC and PXE boot)
> > and bond the others with LACP, then trunk the two
VLANs for private and
> > public LANs on top of that. Sounds possible? (as
I've never used VLANs
> > on Linux, even less on top of some bonding!)
> 
> You can certainly do this part, although it could be
argued, probably
> correctly, that VLAN's are not a strong enough security
barrier on which
> to mix a "Public" and "Private"
network, although those terms can mean
> slightly different things to different people.  We
actually do this in a
> few cases, but the "public" VLAN is already
firewalled and restricted by
> application layer proxies before it's VLAN's are mixed
on the same
> wire/network infrastructure with our "public"
VLAN's.

Thanks for confirming. I'll do some bonding+VLAN testing
anyway.

> > This last setup would possibly mean loosing access
to the "maintenance"
> > interface if a switch dies, but never loosing
access to any of the two
> > production networks. The switches I have in mind
are Cisco 4948, which
> > would be stacked together, and always have LACP
configured across two
> > or more devices.
> 
> > Has anyone done anything similar? Sounds
reasonable? Any advice?
> 
> We have a similar setup with Cisco 3750's in a stack
(well, as far as
> VLAN's and redundant access), however, I don't think
that an LACP
> channel bonded link can span across two different
switches on a Cisco
> 4948.  This works on the 3750's because they stack via
a special cable
> in the back and basically become a single switch,
however I think that
> Cisco 4948's stack via trunk ports and still act as
separate switches,
> with separate configs and switching engines, although
I'd have to look
> it up to be 100% sure.  That doesn't mean you can't
used use adaptive
> load balancing or simple failover across two switches
(we do a good bit
> of this as well), but LACP is designed to make the
links appear as a
> single link and typically can't span switches that
don't share the same
> switching fabric.  That means it usually requires
chassis based switches
> or stackable switches that become a single fabric via a
fabric cable
> rather than connecting via ethernet trunks.
> 
> I could be wrong on the 4948 and it's capabilities, we
have a couple of
> these and I'm pulling it from my memory.  I know it
supports LACP on
> multiple ports within a single switch, but I'm pretty
sure it cannot be
> LACP aware across multiple switches like the 3750's.

I thought the 4948's would have stacking capabilities
similar to the
3750, but I must be wrong. I was mostly interested in those
because they
can have redundant power supplies and cooling, but if I can
install the
switches in a way that any of them can fail without
affecting the
services, then it wouldn't be such a vital feature anymore,
and I could
go with some 3750's, since they are very similar from what I
can see
(i.e. there are also some with 10G X2 slots, which is what
I'm after).

Thanks for the Cisco device insight! 

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 8 (Werewolf) - Linux kernel
2.6.23.14-107.fc8
Load : 0.12 0.21 0.20

_______________________________________________
rhelv5-list mailing list
rhelv5-listredhat.com
h
ttps://www.redhat.com/mailman/listinfo/rhelv5-list