Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Cisco: NSP

Handling redundancy between buildings.

 

 

Cisco nsp RSS feed   Index | Next | Previous | View Threaded


kseich at gmail

Apr 30, 2012, 12:08 PM

Post #1 of 4 (475 views)
Permalink
Handling redundancy between buildings.

We have 2 buildings on our Campus right next to each other. They are
connected by 10 Gb fiber pulls. Each building has it's own generator and
UPS. Each building has it's own ISP. We have an ASA 5520 failover pair,
one in each building. We have 2 - 3750x stacked in each building as a
core. We are currently a flat network, a /16. We are in the
design/brainstorming phase of segmenting this into vlans. We'd like to
take the burden off the ASA for routing and do all inter vlan routing on
the 3750s. From what we can see, you cannot treat the 3750s as a failover
pair, like the ASAs. What are our options in segmenting this?

1 We can do all routing on the ASAs. This would achieve the same
redundancy we have now, but put the burden on the ASA for routing all vlans.

2 Put the routing on the 3750 stack. This would essentially break our 2
buildings into separate networks, separate , non-overlapping vlans in each
building. reconfigure services to talk across the buildings and vlans.

3 put in routers behind the ASAs that handle all the vlan routing. These
function in a failover pair. this keeps the redundancy we are looking for
but we are not utilizing the layer 3 capability that we paid for on the
3750s.

Are there other options? What have you guys/girls done?

Looking for any other input you have just to spark the design creativity.

Thank you !
Kevin
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


svoll.voip at gmail

Apr 30, 2012, 12:31 PM

Post #2 of 4 (435 views)
Permalink
Re: Handling redundancy between buildings. [In reply to]

run your 3750's in a HSRP setup. weight the one in the building to be
primary for the vlan's in that building and do the oppisite in the other
building.

we do it here and it works pretty slick.

Not knowing the size of your buildings.... it is possible to run out of
HSRP instances. I think we topped our 3750E off at 32.

Not sure what your looking at for total vlans.

YMMV

Scott

On Mon, Apr 30, 2012 at 12:08 PM, Kevin Seich <kseich [at] gmail> wrote:

> We have 2 buildings on our Campus right next to each other. They are
> connected by 10 Gb fiber pulls. Each building has it's own generator and
> UPS. Each building has it's own ISP. We have an ASA 5520 failover pair,
> one in each building. We have 2 - 3750x stacked in each building as a
> core. We are currently a flat network, a /16. We are in the
> design/brainstorming phase of segmenting this into vlans. We'd like to
> take the burden off the ASA for routing and do all inter vlan routing on
> the 3750s. From what we can see, you cannot treat the 3750s as a failover
> pair, like the ASAs. What are our options in segmenting this?
>
> 1 We can do all routing on the ASAs. This would achieve the same
> redundancy we have now, but put the burden on the ASA for routing all
> vlans.
>
> 2 Put the routing on the 3750 stack. This would essentially break our 2
> buildings into separate networks, separate , non-overlapping vlans in each
> building. reconfigure services to talk across the buildings and vlans.
>
> 3 put in routers behind the ASAs that handle all the vlan routing. These
> function in a failover pair. this keeps the redundancy we are looking for
> but we are not utilizing the layer 3 capability that we paid for on the
> 3750s.
>
> Are there other options? What have you guys/girls done?
>
> Looking for any other input you have just to spark the design creativity.
>
> Thank you !
> Kevin
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


kseich at gmail

Apr 30, 2012, 12:33 PM

Post #3 of 4 (433 views)
Permalink
Re: Handling redundancy between buildings. [In reply to]

Thank Scott, I will take a look at that. 32 might just be enough for what
we want to accomplish.

On Mon, Apr 30, 2012 at 3:31 PM, Scott Voll <svoll.voip [at] gmail> wrote:

> run your 3750's in a HSRP setup. weight the one in the building to be
> primary for the vlan's in that building and do the oppisite in the other
> building.
>
> we do it here and it works pretty slick.
>
> Not knowing the size of your buildings.... it is possible to run out of
> HSRP instances. I think we topped our 3750E off at 32.
>
> Not sure what your looking at for total vlans.
>
> YMMV
>
> Scott
>
> On Mon, Apr 30, 2012 at 12:08 PM, Kevin Seich <kseich [at] gmail> wrote:
>
>> We have 2 buildings on our Campus right next to each other. They are
>> connected by 10 Gb fiber pulls. Each building has it's own generator and
>> UPS. Each building has it's own ISP. We have an ASA 5520 failover pair,
>> one in each building. We have 2 - 3750x stacked in each building as a
>> core. We are currently a flat network, a /16. We are in the
>> design/brainstorming phase of segmenting this into vlans. We'd like to
>> take the burden off the ASA for routing and do all inter vlan routing on
>> the 3750s. From what we can see, you cannot treat the 3750s as a failover
>> pair, like the ASAs. What are our options in segmenting this?
>>
>> 1 We can do all routing on the ASAs. This would achieve the same
>> redundancy we have now, but put the burden on the ASA for routing all
>> vlans.
>>
>> 2 Put the routing on the 3750 stack. This would essentially break our 2
>> buildings into separate networks, separate , non-overlapping vlans in each
>> building. reconfigure services to talk across the buildings and vlans.
>>
>> 3 put in routers behind the ASAs that handle all the vlan routing. These
>> function in a failover pair. this keeps the redundancy we are looking for
>> but we are not utilizing the layer 3 capability that we paid for on the
>> 3750s.
>>
>> Are there other options? What have you guys/girls done?
>>
>> Looking for any other input you have just to spark the design creativity.
>>
>> Thank you !
>> Kevin
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp [at] puck
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


kgraham at industrial-marshmallow

May 1, 2012, 8:01 AM

Post #4 of 4 (421 views)
Permalink
Re: Handling redundancy between buildings. [In reply to]

If you're going to the effort of chopping up that /16, kill the cross-building VLANs. You've already got local redundancy in the stack, no need to involve both buildings in duplicate STP, ARP, etc.

Let each building be its own L2 domain and turn those 10GbE hauls into PtP L3 links (worst case, use a floating static default between the two, though even IP Base should get you RIPv2).

You'll benefit from traffic on both those xconnects (rather that STP blocking one all the time), and each building can get a full 3750's worth of SVIs.


On Apr 30, 2012, at 12:33 PM, Kevin Seich <kseich [at] gmail> wrote:

> I will take a look at that. 32 might just be enough

Either way you go, just be mindful of SDM templates.


_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Cisco nsp RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.