Mailing List Archive

I'm not a ServerIron expert and I must be missing something here.

If you're using the ServerIron's in routing mode, I'm not sure why you can't do
exactly what you're talking about. Just put the ServerIron into the L3 path,
either directly above the customer and the 802.1q VLAN (the SI would be the
default g/w) or with a router in the middle.

Same thing with bridging mode. You just have to make sure to put the SI in the
layer 2 path.

So... what am I missing here?

Tine

Quoting Matt Stockdale <mstockda@logicworks.net>:

> Greetings-
>
> We're currently using a number of pairs of ServerIron XL's on separate
> subnets/vlans to offer load balancing services for multiple customers.
> Most of these devices are sorely underutilized, and taking up valuable
> datacenter space.
>
> We had visited the issue w/ foundry a couple of years ago, ideally
> wanting to trunk up a central pair of devices via 802.1q trunk to our
> core switches, and use that to provide "virtual serverirons" on any vlan
> we needed. It turns out we couldn't do that at the time, and despite
> what their product manager told me at CeBit, it still can't.
>
> It looks like source-ip and source-nat are about as close as we can
> come, but our customers are unwilling to lose the true source ip of the
> incoming connections for log analysis purposes. I believe this is
> because the serverirons are primarily layer2 devices, no?
>
> In addition, the foundry folks seem to have lost our support contract
> (that we renewed 2 weeks ago) and seem unwilling or unable to give us a
> straight answer on this. It's astonishing, really, how hard they are
> working to not take our money. Oh well.
>
> All of that said (thanks for reading this far), is anyone aware of a
> foundry product that can do what we're looking for? Failing that, anyone
> else's product?
>
> Thanks,
> Matt
>
>
>
> --
> -----------------------
> Matt Stockdale
> Sr Network Engineer
> mstockda@logicworks.net
>
>

The ServerIron chassis units (400,800) can handle loadbalancing in
multiple VLANs in most cases if you're running the 8.x series of code.

--
thanks,

Will

On Thu, 27 May 2004, Matt Stockdale wrote:

:: All of that said (thanks for reading this far), is anyone aware of a
:: foundry product that can do what we're looking for? Failing that, anyone
:: else's product?
::

hi matt,

foundry has been able to do this for more than 4 years. What sort of
problems have you run into? Are you running dsr or inline?

-jba

__
[jba@analogue.net] :: analogue.networks.nyc :: http://analogue.net

Routing mode? Maybe I've been missing something all along.. These
ServerIron XL's I have don't seem to have any routing features.. they
are load-balancing switches.. (which is probably the problem. If a
foundry router type device can do it, we're fine with that, we just
can't get Foundry support to commit to an answer)

Going through the documentation, I don't see any way to create a vlan
interface.. i.e, trunk up vlans 1-10 on ethernet 1, then create a
virtual interface on each vlan that I want to offer load balancing
services to?

Thanks,
Matt

On Thu, 2004-05-27 at 16:42, Tine Hutchison wrote:
> I'm not a ServerIron expert and I must be missing something here.
>
> If you're using the ServerIron's in routing mode, I'm not sure why you can't do
> exactly what you're talking about. Just put the ServerIron into the L3 path,
> either directly above the customer and the 802.1q VLAN (the SI would be the
> default g/w) or with a router in the middle.
>
> Same thing with bridging mode. You just have to make sure to put the SI in the
> layer 2 path.
>
> So... what am I missing here?
>
> Tine
>
> Quoting Matt Stockdale <mstockda@logicworks.net>:
>
> > Greetings-
> >
> > We're currently using a number of pairs of ServerIron XL's on separate
> > subnets/vlans to offer load balancing services for multiple customers.
> > Most of these devices are sorely underutilized, and taking up valuable
> > datacenter space.
> >
> > We had visited the issue w/ foundry a couple of years ago, ideally
> > wanting to trunk up a central pair of devices via 802.1q trunk to our
> > core switches, and use that to provide "virtual serverirons" on any vlan
> > we needed. It turns out we couldn't do that at the time, and despite
> > what their product manager told me at CeBit, it still can't.
> >
> > It looks like source-ip and source-nat are about as close as we can
> > come, but our customers are unwilling to lose the true source ip of the
> > incoming connections for log analysis purposes. I believe this is
> > because the serverirons are primarily layer2 devices, no?
> >
> > In addition, the foundry folks seem to have lost our support contract
> > (that we renewed 2 weeks ago) and seem unwilling or unable to give us a
> > straight answer on this. It's astonishing, really, how hard they are
> > working to not take our money. Oh well.
> >
> > All of that said (thanks for reading this far), is anyone aware of a
> > foundry product that can do what we're looking for? Failing that, anyone
> > else's product?
> >
> > Thanks,
> > Matt
> >
> >
> >
> > --
> > -----------------------
> > Matt Stockdale
> > Sr Network Engineer
> > mstockda@logicworks.net
> >
> >
>
--
-----------------------
Matt Stockdale
Sr Network Engineer
mstockda@logicworks.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://puck.nether.net/pipermail/foundry-nsp/attachments/20040527/dd5a0129/attachment.bin

Ah ha, finally, a concrete answer :)

Now, is this a scenario where we aren't using this device as the access
switch? (we would generally just want to trunk it directly to our core
Cisco 6500 switches) We use exclusively DSR for this reason..

Thanks,
Matt

On Thu, 2004-05-27 at 16:51, Will Lowe wrote:
> The ServerIron chassis units (400,800) can handle loadbalancing in
> multiple VLANs in most cases if you're running the 8.x series of code.
--
-----------------------
Matt Stockdale
Sr Network Engineer
mstockda@logicworks.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://puck.nether.net/pipermail/foundry-nsp/attachments/20040527/f608b31d/attachment.bin

dsr. I think the problem is that we have ServerIron XL's, which seem to
be 90% layer2, and thus lack the feature I'm looking for, which is
heavily layer 3.

I figured they did have a product that could do it, but neither their
support nor our salesperson has been able to give us a concrete "Yes,
the 400 or new 450 chassis will work in the configuration you describe",
which is sad, because we'd pretty much just fork over the money at that
point.

Matt

On Thu, 2004-05-27 at 16:48, jeffrey.arnold wrote:
> On Thu, 27 May 2004, Matt Stockdale wrote:
>
> :: All of that said (thanks for reading this far), is anyone aware of a
> :: foundry product that can do what we're looking for? Failing that, anyone
> :: else's product?
> ::
>
> hi matt,
>
> foundry has been able to do this for more than 4 years. What sort of
> problems have you run into? Are you running dsr or inline?
>
> -jba
>
> __
> [jba@analogue.net] :: analogue.networks.nyc :: http://analogue.net
--
-----------------------
Matt Stockdale
Sr Network Engineer
mstockda@logicworks.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://puck.nether.net/pipermail/foundry-nsp/attachments/20040527/634699c2/attachment.bin

On Thu, 27 May 2004, Matt Stockdale wrote:

:: dsr. I think the problem is that we have ServerIron XL's, which seem to
:: be 90% layer2, and thus lack the feature I'm looking for, which is
:: heavily layer 3.
::

both the XL's and chassis based boxes work fine. In a dsr config, you
shouldn't need to do much more than define your router port(s) and tag
up the correct vlans. The foundry will do some L2 magic to get the
packets out with the correct vlan tags.

-jba

__
[jba@analogue.net] :: analogue.networks.nyc :: http://analogue.net

> Now, is this a scenario where we aren't using this device as the access
> switch? (we would generally just want to trunk it directly to our core
> Cisco 6500 switches) We use exclusively DSR for this reason..

Unless you're in DSR or source-nat mode, the SI will want to be in the
return layer2 path. But (almost) none of our servers are plugged
directly into our big ServerIrons -- typically we hang small stackable
switches in each rack and home-run those back to the SIs.

Note that the 8.x code requires an eeprom upgrade to the standard mgmt
modules. They've just released new management modules that might not,
but I don't have any experience with those at all. The 8.x code turns
the unit into a full layer3 device as well (OSPF, RIP, etc.).

Now that I think back I think we got the XLs to do it also. Have you
tried just setting up the XL as you'd expect for a l2 device: make the
vlans, trunk them and set ports appropriately, set the mgmt ip,
etc. and then just making the "server virtual"s with the appropriate
IP addresses? It "feels" wrong -- some of the virtual servers will be
in IP ranges other than the one actually configured on the switch --
but IIRC it works fine as long as the XL is physically in the path
between the source and the real servers.

You might have to set the router-ports.

--
thanks,

Will

Maybe I should have mentioned that the serveriron XL's have a single
ethernet connection to our core switch. We cannot use them as access
switches. We already do exclusively DSR, and this works fine for
balancing real servers on the same vlan and layer3 space as the XL.

Let me whip up a quick diagram of what we'd like to do (don't know how
well it will render for you)

ServerIron
|
|
(dot1q trunk)
(vlans 1-100)
|
|
Cat6500-----------------
| |
| |
(dot1q trunk) (dot1q trunk)
(vlans 1-100) (vlans 1-100)
| |
| |
Cat2950 Cat2950
| |
| |
(access port) (access port)
(vlan 20) (vlan 21)
| |
| |
Real Server A Real Server B
(192.168.20.101) (102.168.21.101)

I'd like to be able to have the ServerIron create a VIP on vlan 20,
192.168.20.100 for example, and balance across 192.168.20.10[1-x] I'd
also like to have the ServerIron create a VIP on vlan 21,
192.168.21.100, and balance across 192.168.21.10[1-x] at the same time.

Currently, if we have our XL configured on the 192.168.20.0/24 Space, we
can't balance anything on 192.168.21.0/24 without source-nat (at least
according to foundry support)

Does that help explain what I'm looking to do?

Matt

On Thu, 2004-05-27 at 17:02, jeffrey.arnold wrote:
> On Thu, 27 May 2004, Matt Stockdale wrote:
>
> :: dsr. I think the problem is that we have ServerIron XL's, which seem to
> :: be 90% layer2, and thus lack the feature I'm looking for, which is
> :: heavily layer 3.
> ::
>
> both the XL's and chassis based boxes work fine. In a dsr config, you
> shouldn't need to do much more than define your router port(s) and tag
> up the correct vlans. The foundry will do some L2 magic to get the
> packets out with the correct vlan tags.
>
> -jba
>
> __
> [jba@analogue.net] :: analogue.networks.nyc :: http://analogue.net
--
-----------------------
Matt Stockdale
Sr Network Engineer
mstockda@logicworks.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://puck.nether.net/pipermail/foundry-nsp/attachments/20040527/ecabb678/attachment.bin

Hmm.. Maybe this is my confusion. Will simply placing the Serveriron in
the correct Layer2 space just make it automagically work?

How will it handle a health check, for instance?. Since as a layer 2
device, it doesn't really know which vlan a given subnet lives on, will
it just send an arp-who-has out over every vlan it's trunked to to
determine where to send the health check?

Matt

On Thu, 2004-05-27 at 17:12, Will Lowe wrote:
> > Now, is this a scenario where we aren't using this device as the access
> > switch? (we would generally just want to trunk it directly to our core
> > Cisco 6500 switches) We use exclusively DSR for this reason..
>
> Unless you're in DSR or source-nat mode, the SI will want to be in the
> return layer2 path. But (almost) none of our servers are plugged
> directly into our big ServerIrons -- typically we hang small stackable
> switches in each rack and home-run those back to the SIs.
>
> Note that the 8.x code requires an eeprom upgrade to the standard mgmt
> modules. They've just released new management modules that might not,
> but I don't have any experience with those at all. The 8.x code turns
> the unit into a full layer3 device as well (OSPF, RIP, etc.).
>
> Now that I think back I think we got the XLs to do it also. Have you
> tried just setting up the XL as you'd expect for a l2 device: make the
> vlans, trunk them and set ports appropriately, set the mgmt ip,
> etc. and then just making the "server virtual"s with the appropriate
> IP addresses? It "feels" wrong -- some of the virtual servers will be
> in IP ranges other than the one actually configured on the switch --
> but IIRC it works fine as long as the XL is physically in the path
> between the source and the real servers.
>
> You might have to set the router-ports.
--
-----------------------
Matt Stockdale
Sr Network Engineer
mstockda@logicworks.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://puck.nether.net/pipermail/foundry-nsp/attachments/20040527/ce4b0fa5/attachment.bin

I do this using subnet vlans. All virtuals are in the same subnet as
the reals.

Something along these lines:

vlan 110 by port
tagged ethe 25 to 26
ip-subnet 192.168.4.0 255.255.255.0
!
vlan 111 by port
tagged ethe 25 to 26
ip-subnet 192.168.5.0 255.255.255.0

Making sure to give the serveriron all necessary source ip's:

(from global config mode)

server source-ip 192.168.5.254 255.255.255.0 0.0.0.0

The source Ip is pretty much just to make sure that the keepalives get
out on the right vlan. The catch?: You can only have 8 source ip's on
a single XL...

Here is what foundry has to say about it:
http://www.foundrynet.com/services/documentation/sribcg/VLANs.html#16034

-----Original Message-----
From: foundry-nsp-bounces@puck.nether.net
[mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Matt Stockdale
Sent: Thursday, May 27, 2004 2:22 PM
To: jeffrey.arnold
Cc: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Centralized Load balancing via 802.1q?

Maybe I should have mentioned that the serveriron XL's have a single
ethernet connection to our core switch. We cannot use them as access
switches. We already do exclusively DSR, and this works fine for
balancing real servers on the same vlan and layer3 space as the XL.

Let me whip up a quick diagram of what we'd like to do (don't know how
well it will render for you)

ServerIron
|
|
(dot1q trunk)
(vlans 1-100)
|
|
Cat6500-----------------
| |
| |
(dot1q trunk) (dot1q trunk)
(vlans 1-100) (vlans 1-100)
| |
| |
Cat2950 Cat2950
| |
| |
(access port) (access port)
(vlan 20) (vlan 21)
| |
| |
Real Server A Real Server B
(192.168.20.101) (102.168.21.101)

I'd like to be able to have the ServerIron create a VIP on vlan 20,
192.168.20.100 for example, and balance across 192.168.20.10[1-x] I'd
also like to have the ServerIron create a VIP on vlan 21,
192.168.21.100, and balance across 192.168.21.10[1-x] at the same time.

Currently, if we have our XL configured on the 192.168.20.0/24 Space, we
can't balance anything on 192.168.21.0/24 without source-nat (at least
according to foundry support)

Does that help explain what I'm looking to do?

Matt

On Thu, 2004-05-27 at 17:02, jeffrey.arnold wrote:
> On Thu, 27 May 2004, Matt Stockdale wrote:
>
> :: dsr. I think the problem is that we have ServerIron XL's, which
> seem to
> :: be 90% layer2, and thus lack the feature I'm looking for, which is
> :: heavily layer 3.
> ::
>
> both the XL's and chassis based boxes work fine. In a dsr config, you
> shouldn't need to do much more than define your router port(s) and tag

> up the correct vlans. The foundry will do some L2 magic to get the
> packets out with the correct vlan tags.
>
> -jba
>
> __
> [jba@analogue.net] :: analogue.networks.nyc :: http://analogue.net
--
-----------------------
Matt Stockdale
Sr Network Engineer
mstockda@logicworks.net

Ah ha, This is exactly what I was looking for.

Now, is there any special config on ethe 25,26? If you know cisco-speak,
are these the equivalent of an etherchannel pair?

Even with an 8 source IP limitation, that lets us reduce our XL's by a
factor of 8, since our main shared pair serves one class c currently,
and customers who need their own dedicated vlan/address space, or want
dedicated firewalls, they get their own pair of XL's.

Matt

On Thu, 2004-05-27 at 17:28, Cliff Fogle wrote:
> I do this using subnet vlans. All virtuals are in the same subnet as
> the reals.
>
> Something along these lines:
>
> vlan 110 by port
> tagged ethe 25 to 26
> ip-subnet 192.168.4.0 255.255.255.0
> !
> vlan 111 by port
> tagged ethe 25 to 26
> ip-subnet 192.168.5.0 255.255.255.0
>
> Making sure to give the serveriron all necessary source ip's:
>
> (from global config mode)
>
> server source-ip 192.168.5.254 255.255.255.0 0.0.0.0
>
> The source Ip is pretty much just to make sure that the keepalives get
> out on the right vlan. The catch?: You can only have 8 source ip's on
> a single XL...
>
> Here is what foundry has to say about it:
> http://www.foundrynet.com/services/documentation/sribcg/VLANs.html#16034
>
> -----Original Message-----
> From: foundry-nsp-bounces@puck.nether.net
> [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Matt Stockdale
> Sent: Thursday, May 27, 2004 2:22 PM
> To: jeffrey.arnold
> Cc: foundry-nsp@puck.nether.net
> Subject: Re: [f-nsp] Centralized Load balancing via 802.1q?
>
> Maybe I should have mentioned that the serveriron XL's have a single
> ethernet connection to our core switch. We cannot use them as access
> switches. We already do exclusively DSR, and this works fine for
> balancing real servers on the same vlan and layer3 space as the XL.
>
> Let me whip up a quick diagram of what we'd like to do (don't know how
> well it will render for you)
>
> ServerIron
> |
> |
> (dot1q trunk)
> (vlans 1-100)
> |
> |
> Cat6500-----------------
> | |
> | |
> (dot1q trunk) (dot1q trunk)
> (vlans 1-100) (vlans 1-100)
> | |
> | |
> Cat2950 Cat2950
> | |
> | |
> (access port) (access port)
> (vlan 20) (vlan 21)
> | |
> | |
> Real Server A Real Server B
> (192.168.20.101) (102.168.21.101)
>
> I'd like to be able to have the ServerIron create a VIP on vlan 20,
> 192.168.20.100 for example, and balance across 192.168.20.10[1-x] I'd
> also like to have the ServerIron create a VIP on vlan 21,
> 192.168.21.100, and balance across 192.168.21.10[1-x] at the same time.
>
> Currently, if we have our XL configured on the 192.168.20.0/24 Space, we
> can't balance anything on 192.168.21.0/24 without source-nat (at least
> according to foundry support)
>
> Does that help explain what I'm looking to do?
>
> Matt
>
> On Thu, 2004-05-27 at 17:02, jeffrey.arnold wrote:
> > On Thu, 27 May 2004, Matt Stockdale wrote:
> >
> > :: dsr. I think the problem is that we have ServerIron XL's, which
> > seem to
> > :: be 90% layer2, and thus lack the feature I'm looking for, which is
> > :: heavily layer 3.
> > ::
> >
> > both the XL's and chassis based boxes work fine. In a dsr config, you
> > shouldn't need to do much more than define your router port(s) and tag
>
> > up the correct vlans. The foundry will do some L2 magic to get the
> > packets out with the correct vlan tags.
> >
> > -jba
> >
> > __
> > [jba@analogue.net] :: analogue.networks.nyc :: http://analogue.net
> --
> -----------------------
> Matt Stockdale
> Sr Network Engineer
> mstockda@logicworks.net
>
--
-----------------------
Matt Stockdale
Sr Network Engineer
mstockda@logicworks.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://puck.nether.net/pipermail/foundry-nsp/attachments/20040527/5ea0cf5c/attachment.bin

Yeah, those are the two gig ports on the XL which are
trunked/channeled/bonded together.

Also, check the 8 number. I might be wrong. There is some limitation
though, I just can't find the foundry doc that I read it in.

-----Original Message-----
From: Matt Stockdale [mailto:mstockda@logicworks.net]
Sent: Thursday, May 27, 2004 2:35 PM
To: Cliff Fogle
Cc: jeffrey.arnold; foundry-nsp@puck.nether.net
Subject: RE: [f-nsp] Centralized Load balancing via 802.1q?

Ah ha, This is exactly what I was looking for.

Now, is there any special config on ethe 25,26? If you know cisco-speak,
are these the equivalent of an etherchannel pair?

Even with an 8 source IP limitation, that lets us reduce our XL's by a
factor of 8, since our main shared pair serves one class c currently,
and customers who need their own dedicated vlan/address space, or want
dedicated firewalls, they get their own pair of XL's.

Matt

On Thu, 2004-05-27 at 17:28, Cliff Fogle wrote:
> I do this using subnet vlans. All virtuals are in the same subnet as
> the reals.
>
> Something along these lines:
>
> vlan 110 by port
> tagged ethe 25 to 26
> ip-subnet 192.168.4.0 255.255.255.0
> !
> vlan 111 by port
> tagged ethe 25 to 26
> ip-subnet 192.168.5.0 255.255.255.0
>
> Making sure to give the serveriron all necessary source ip's:
>
> (from global config mode)
>
> server source-ip 192.168.5.254 255.255.255.0 0.0.0.0
>
> The source Ip is pretty much just to make sure that the keepalives get

> out on the right vlan. The catch?: You can only have 8 source ip's
> on a single XL...
>
> Here is what foundry has to say about it:
> http://www.foundrynet.com/services/documentation/sribcg/VLANs.html#160
> 34
>
> -----Original Message-----
> From: foundry-nsp-bounces@puck.nether.net
> [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Matt
> Stockdale
> Sent: Thursday, May 27, 2004 2:22 PM
> To: jeffrey.arnold
> Cc: foundry-nsp@puck.nether.net
> Subject: Re: [f-nsp] Centralized Load balancing via 802.1q?
>
> Maybe I should have mentioned that the serveriron XL's have a single
> ethernet connection to our core switch. We cannot use them as access
> switches. We already do exclusively DSR, and this works fine for
> balancing real servers on the same vlan and layer3 space as the XL.
>
> Let me whip up a quick diagram of what we'd like to do (don't know how

> well it will render for you)
>
> ServerIron
> |
> |
> (dot1q trunk)
> (vlans 1-100)
> |
> |
> Cat6500-----------------
> | |
> | |
> (dot1q trunk) (dot1q trunk)
> (vlans 1-100) (vlans 1-100)
> | |
> | |
> Cat2950 Cat2950
> | |
> | |
> (access port) (access port)
> (vlan 20) (vlan 21)
> | |
> | |
> Real Server A Real Server B
> (192.168.20.101) (102.168.21.101)
>
> I'd like to be able to have the ServerIron create a VIP on vlan 20,
> 192.168.20.100 for example, and balance across 192.168.20.10[1-x] I'd
> also like to have the ServerIron create a VIP on vlan 21,
> 192.168.21.100, and balance across 192.168.21.10[1-x] at the same
time.
>
> Currently, if we have our XL configured on the 192.168.20.0/24 Space,
> we can't balance anything on 192.168.21.0/24 without source-nat (at
> least according to foundry support)
>
> Does that help explain what I'm looking to do?
>
> Matt
>
> On Thu, 2004-05-27 at 17:02, jeffrey.arnold wrote:
> > On Thu, 27 May 2004, Matt Stockdale wrote:
> >
> > :: dsr. I think the problem is that we have ServerIron XL's, which
> > seem to
> > :: be 90% layer2, and thus lack the feature I'm looking for, which
> > is
> > :: heavily layer 3.
> > ::
> >
> > both the XL's and chassis based boxes work fine. In a dsr config,
> > you shouldn't need to do much more than define your router port(s)
> > and tag
>
> > up the correct vlans. The foundry will do some L2 magic to get the
> > packets out with the correct vlan tags.
> >
> > -jba
> >
> > __
> > [jba@analogue.net] :: analogue.networks.nyc :: http://analogue.net
> --
> -----------------------
> Matt Stockdale
> Sr Network Engineer
> mstockda@logicworks.net
>
--
-----------------------
Matt Stockdale
Sr Network Engineer
mstockda@logicworks.net