At 5:52 PM +0000 8/12/04, Priscilla Oppenheimer wrote:
>Very interesting, Howard. Thanks. A good example of where L3 is better than
>L2 for redundancy, load sharing, etc.
>
>I found the wireless part interesting. Cisco and other vendors have been
>saying for a while that to facillitate roaming a campus WLAN should be one
>big IP subnet of its own. That advice was bound to cause grief at some
>point!? :-)
>
>You say that the customer doesn't have mobile IP, but would it be too horrid
>to get Cisco's variety of mobile IP (mobile node, home agent, and foreign
>agent) working for this situation? It seems like it would be a solution that
>fits well with your L3-based architecture. Maybe more complexity than you
>need on top of all the other complexity, though.
Layer 8 violation. It's a hospital that has told their doctors they
don't have to change their PCs other than with a wireless card. They
use any SSL-enabled browser to set up SSL encryption to get to
sensitive files.
In other words, there's no way to get the doctors to put software on
their mobile nodes.
I suspect the problem will be self-correcting further down the road,
because the one big subnet will become overloaded, and the doctors
will complain about poor performance. At that point, there's a
chance of setting up different subnets, and maybe introducing mobile
IP as a "performance enhancement". Introducing it now would be a
political protocol violation.
Yes, it becomes easier to roam with one big subnet. But those
recommendations seem to ignore that the underlying layer 2 domain is
half duplex and slower than what many users have come to expect from
their desktops.
>
>More here:
>
>http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800a4444.shtml
>
>Priscilla
>
>
>Howard C. Berkowitz wrote:
>>
>> At 6:45 PM +0000 8/11/04, Priscilla Oppenheimer wrote:
>> > speed EIGRP!!
>> >
>> >Hee hee. It does seem like we've come full circle. Routers are
>> bad, large
>> >switched networks are good, large switched networks are bad,
>> routers are
>> >good again (oops, better say L3 switch!)
>> >
>> >We could have an entire discussion on the optimal quantity and
>> placement of
>> >L3 switches in campus network designs.
>> >
>>
>> I'll give that a shot, since I'm facing that problem right now
>> in a
>> real and messy network. It's a situation where the hardware has
>> already been purchased and the cabling is already in place.
>> The
>> original assumption had been to use more than one spanning tree
>> for a
>> larger number of VLANs, throughout, but I quickly found out I
>> could
>> get much better loadsharing with an L3 solution. L3 also helps
>> me
>> isolate some legacy non-RSTP switches from the overall
>> convergence
>> problem -- the 3548s can be in a 802.1d spanning tree, which
>> can be
>> tuned to the topology. There is, unfortunately, one part of
>> the
>> problem that doesn't lend itself to L3: the campus-wide WLAN
>> was
>> designed to be a single subnet, with WAPs terminating
>> everywhere.
>>
>> General situation:
>> 321 wire closets, 200 with 3550s (new) and the remainder
>> with 3524/3548
>> Six 6509s in the computer room, running hybrid CatOS/IOS
>> with Sup1A
>> Roughly 200 servers in the computer room, many with
>> internal clustering
>> Home-run fiber from wire closets to computer room only.
>> Almost complete freedom to renumber and define subnet size,
>> with the major
>> constraint being that the WLAN is being assumed to need a
>> large flat
>> subnet -- there's no mobile IP. Wireless access points
>> terminate
>> in wire closets. The client does picture clinical people
>> walking around
>> with handheld wireless units, so they want the single
>> subnet. Were this
>> an office environment, different subnets with short
>> address leases might
>> be fine. All the truly mobile devices will use SSL.
>> Healthcare environment (hospital) with some life-critical
>> applications.
>>
>> The assumption had been that there would be 4 distribution
> > 6509s and
>> 2 server 6509s, interconnected with GE links as a core.
>>
>> One of the first problems came when trying to use multiple
>> spanning
>> trees, when the smallest unit that can be in one spanning tree
>> is a
>> chassis. The goal had been to use both 6509 uplinks as backup
>> and
>> loadsharing, each going to a different 6509. There are
>> multiple
>> application VLANs with different topologies connected to
>> various
>> 3550s, so there's no logical way to split up into multiple
>> spanning
>> trees. Exit multiple spanning tree.
>>
>> The next most reasonable thing seemed to be to create two
>> single
>> spanning trees, each with two 6509's and half the wire closets,
>> with
>> all the 6509 L3-commencted as a ring and also star-connected to
>> the
>> core/server 6509s, both of which are connected with multiple
>> GE. I
>> still wind up with the problem that one of the 6509s, at L2, is
>> going
>> to wind up being a standby root. If I had been able to specify
>> the
>> environment with a tier of distribution/concentration switches,
>> the
>> spanning tree and failover becomes much neater, but I can't get
>> additional hardware. Yes, it is true that four of the 6509's
>> loosely
>> form a distribution tier, but they are sufficiently collapsed
>> into
>> the core that I can't get the necessary separation of tiers for
>> Cisco's model really to work.
>>
>> So, my next approach was to go all L3 from the wire closets to
>> the
>> distribution switches, which neatly cleaned up loadsharing and
>> failover.
>>
>> Then, I realized I still had a problem: the flat WLAN. I could
>> handle
>> this in OSPF with redistribute connected, but the heart of the
>> problem was that there was an assumption that the WLAN ports on
>> each
>> 3550 were trunked together via 802.1. This is one thing very
>> much
>> like the lab -- the hardware that you are forced to use, under
>> certain design assumptions, may not be an optimal combination.
>>
>> I hadn't configured the particular mixture of 3550s with hybrid
>> 6509's, and am waiting for some lab gear to get assembled at
>> the
>> customer's remote location so I can try a couple of ideas.
>> Meanwhile, I'm trying to figure out a way to have the GE
>> uplinks
>> behave as both /30 serials to the higher-layer switch, but also
>> communicate with other wire closets through that same switch
>> (or
>> other switches) such that I have the big WLAN subnet.
>>
>> If I can define L3 subinterfaces for routing on the L3 uplinks,
>> still
>> letting them be 802.1q, such that they can be trunks as well,
>> I'm
>> fine being able to route and still bridge the WLAN ports
>> together,
>> I'm fine. I suspect some version of BVI may let me do this,
>> but I
>> have to try it.
>>
>> Otherwise, things get messy. I know I could make it work by
>> bridging
>> the WLAN interfaces and running a tree of
>> bridging-over-IP-tunnels
>> among the 3550s to a pair of 6509s, one running as backup root,
>> but
>> that's incredibly ugly.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=91735&t=91735
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
