[f-nsp] foundry-nsp Digest, Vol 89, Issue 19

[Castellano, August]

EZ

"foundry-nsp-request at puck.nether.net"
<foundry-nsp-request at puck.nether.net> wrote:

Send foundry-nsp mailing list submissions to
	foundry-nsp at puck.nether.net

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
	foundry-nsp-request at puck.nether.net

You can reach the person managing the list at
	foundry-nsp-owner at puck.nether.net

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 <gk at ax.tc>
To: foundry-nsp at puck.nether.net
Subject: Re: [f-nsp] IPv6 BGP peer-group problem
Message-ID: <4C22398F.60508 at ax.tc>
Content-Type: text/plain; charset=ISO-8859-1

Am 23.06.2010 15:24, schrieb Niels Bakker:
> * gk at ax.tc (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 <mailers at oranged.to>
To: foundry-nsp  <foundry-nsp at puck.nether.net>
Subject: [f-nsp] Serveriron 4G-SSL with vlans and VIPs.
Message-ID:
	<1415913469.30.1277342345844.JavaMail.root at poops.oranged.to>
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 <hidden at xmission.com>
To: Jimmy Stewpot <mailers at oranged.to>
Cc: foundry-nsp <foundry-nsp at puck.nether.net>
Subject: Re: [f-nsp] Serveriron 4G-SSL with vlans and VIPs.
Message-ID: <0ED3E1FA-E439-452F-B418-433A0B474BDF at xmission.com>
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 <mailers at oranged.to> 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
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp



------------------------------

_______________________________________________
foundry-nsp mailing list
foundry-nsp at puck.nether.net
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 postmaster at sbsplanet.com.