EZ
"[email protected]"
<[email protected]> wrote:
Send foundry-nsp mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://puck.nether.net/mailman/listinfo/foundry-nsp
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of foundry-nsp digest..."
Today's Topics:
1. Re: IPv6 BGP peer-group problem (Gerald Krause)
2. Serveriron 4G-SSL with vlans and VIPs. (Jimmy Stewpot)
3. Re: Serveriron 4G-SSL with vlans and VIPs. (Jared Valentine)
----------------------------------------------------------------------
Message: 1
Date: Wed, 23 Jun 2010 18:42:55 +0200
From: Gerald Krause <[email protected]>
To: [email protected]
Subject: Re: [f-nsp] IPv6 BGP peer-group problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Am 23.06.2010 15:24, schrieb Niels Bakker:
> * [email protected] (Gerald Krause) [Wed 23 Jun 2010, 15:22 CEST]:
>> Does anyone ever observed problems regarding XMRs and BGP peer-groups
>> with IPv6 neighbors?
>>
>> In my setup (XMR4k, v4.0.1a) the configured "prefix-filter" and
>> "route-map" in a peer-group won't be used for any IPv6 neighbor within
>> that certain peer-group but other things like "update-source" and
>> "remote-as" work well.
Ooops, I've found (my?) fault: I've forgot to *activate* the peer-group
under "address-family ipv6 unicast". It's not enough to activate the
neighbor itself under "address-family ipv6 unicast". Now it works.
> "show ipv6 bgp neighbor" sometimes lies and says it is applying a filter
> where it's not. Try clearing the neighbor before unshutting it (and I
> strongly advise enabling "auto-shutdown-new-neighbors").
Thx - this "auto-shutdown-new-neighbors" is really useful! I was not
aware of this command.
--
Gerald
------------------------------
Message: 2
Date: Thu, 24 Jun 2010 01:19:05 +0000 (UTC)
From: Jimmy Stewpot <[email protected]>
To: foundry-nsp <[email protected]>
Subject: [f-nsp] Serveriron 4G-SSL with vlans and VIPs.
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8
Hi All,
I am currently managing a pair of 4G-SSL's which handle a very busy web
service. The load on those web servers has now increased beyond what our
back end application servers can handle so we need to start load balancing
on the back end too. I have looked at the configuration and was trying to
see if its possible to have multiple vlans and segregate the traffic and
vips between VLAN's so we have something like this
Internet -> FW -> Load Balancer A (vlan2) -> Web -> FW -> Load Balancer A
(vlan3) -> Application Tier -> FW -> DB Tier.
The Application tier has intelligence at the app level that does load
balancing and so on which makes that area scale, however the web page runs
on rpc over https.. That is what we need to load balance so we can scale
out sideways. Now my question is do we need to have the routing/advanced
l3 feature set to be able to accommodate this type of requirement on the
4G-SSL?
Regards,
Jimmy Stewpot.
------------------------------
Message: 3
Date: Thu, 24 Jun 2010 00:19:28 -0600
From: Jared Valentine <[email protected]>
To: Jimmy Stewpot <[email protected]>
Cc: foundry-nsp <[email protected]>
Subject: Re: [f-nsp] Serveriron 4G-SSL with vlans and VIPs.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
I've configured something similar with switch code before. It was a little
convoluted and there wasn't a firewall between the different load balanced
layers.
You can use source-nat-ip addresses as the default gateway for the
different tiers. They NAT overload out when they initiate Internet-bound
traffic
The only problem we ran into was that real servers couldn't access VIPs in
other subnets. We fixed that by duplicating some VIPs in different
subnets.
Also look at ACL-based source-nat. You might need that tool as well.
Prem code doesn't have this limitation according to TAC. So upgrading
might be in the cards for you.
If this isn't clear, send over a network diagram and I will see if I can
provide a little more help.
Good luck,
Jared
On Jun 23, 2010, at 7:19 PM, Jimmy Stewpot <[email protected]> wrote:
> Hi All,
>
> I am currently managing a pair of 4G-SSL's which handle a very busy web
service. The load on those web servers has now increased beyond what our
back end application servers can handle so we need to start load balancing
on the back end too. I have looked at the configuration and was trying to
see if its possible to have multiple vlans and segregate the traffic and
vips between VLAN's so we have something like this
>
> Internet -> FW -> Load Balancer A (vlan2) -> Web -> FW -> Load Balancer
A (vlan3) -> Application Tier -> FW -> DB Tier.
>
> The Application tier has intelligence at the app level that does load
balancing and so on which makes that area scale, however the web page runs
on rpc over https.. That is what we need to load balance so we can scale
out sideways. Now my question is do we need to have the routing/advanced
l3 feature set to be able to accommodate this type of requirement on the
4G-SSL?
>
> Regards,
>
> Jimmy Stewpot.
> _______________________________________________
> foundry-nsp mailing list
> [email protected]
> http://puck.nether.net/mailman/listinfo/foundry-nsp
------------------------------
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp
End of foundry-nsp Digest, Vol 89, Issue 19
*******************************************
The information contained in this transmission may contain privileged and
confidential information.
It is intended only for the use of the person(s) named above. If you are not
the intended
recipient, you are hereby notified that any review, dissemination, distribution
or
duplication of this communication is strictly prohibited. If you are not the
intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.
To reply to our email administrator directly, please send an email to
[email protected].
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp
