[f-nsp] Centralized Load balancing via 802.1q?

[Matt Stockdale]

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 at 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 at logicworks.net
> >
> >
> 
-- 
-----------------------
    Matt Stockdale
  Sr Network Engineer
mstockda at logicworks.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
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.sig>