>I've been going through the BCMSN course and I'm a bit baffled on how to do
>something. There's the statement that:
>
>Because VLANs terminate at the distribution device, core links are not trunk
>links and traffic is routed across the core.
>
>What I'm puzzled by is how to terminate a VLAN at the distribution layer.
>What am I missing here?
Well, like OSI, it's a model without absolute rules, and, like OSI,
it's evolved to use sublayers. I often have multiple sublayers in
distribution, which very well may physically have both VLANs and VLAN
trunks.
Don't know if it will help, but here's some partially relevant
discussion from a draft chapter of my upcoming book "Building Service
Provider Networks":
One useful and popular model to describe enterprise network
architecture was introduced by Cisco Systems. Any model, of course,
is a guideline, and, as shown in Figure 2, this model has been used
with both WAN and LAN cores.
Figure 2: 3 layer model
This model divides the network into three tiers:
o Access: contains end users and local servers. It is possible
to put centralized servers in an access tier, but, when doing so, it
is usually best to put the individual servers of a local cluster into
the access tiers. Load distribution to these servers is at the next
tier.
o Distribution: contains devices that transition between
environments (e.g., LAN to WAN, building to campus, or different
transmission technology). Often, the distribution tier is the place
that requires the greatest intelligence for protocol conversion,
buffering, etc. Another term entering usage for this function is
"Edge."
o Core: efficiently links sites of the infrastructure. May be
a collapsed LAN backbone primarily of layer 2 and inter-VLAN devices,
or may be a set of routers.
One enterprise guideline is that layer 2 relays tend to have all
their interfaces inside tiers, while layer 3 (i.e., routers) and
higher layer (e.g., firewalls and proxies) tend to have interfaces
between different tiers. This guideline is not terribly rigorous, as
a speed-shifting switch between a workgroup and a building (or
campus) core often logically straddles the top of the access tier and
the bottom of the distribution tier. Large distribution networks
will include multiple levels of concentration.
When demand access is involved (e.g., dialup), it can be convenient
to put end hosts and access routers in the access tier, dial-in
servers at the bottom of the distribution tier, and concentrating
routers inside the distribution tier. Large routers link regions to a
core router or complex of routers. Another function that fits nicely
in the distribution tier is that of firewalls or border routers
providing connectivity outside the enterprise. See Figure 3.
Figure 3: Three-Level Model Details
In this figure, note that the central servers themselves are at the
distribution tier, but that user connectivity to them comes through
the core, and they have their own inter-server links at the access
tier. Having isolated links and possibly specialized hosts, such as
backup machines, for large servers can keep a great deal of traffic
localized and avoid negative performance impact.
This model works well for networks of medium size. Small networks may
collapse certain of the tiers together, and very large networks
become more like carrier networks.
In the optimal use of this model, the customer access router is
closest to the end hosts, customer core routers link campuses or
sites, and distribution routers perform concentration and translation
functions between access and core. External connectivity is
generally a function of the distribution tier, although, if all
otherwise unknown traffic defaults to a central external router, that
router might be in the customer core.
The model had limitations in large enterprise networks, where there
may be multiple operational levels of local, regional, and
national/international corporate backbones. One approach, shown in
Figure 4, is to apply the model recursively, where the top level of
one organizational level becomes the bottom level of another
organizational level.
Figure 4: Recursive 3 Layer
The recursive approach really didn't work well, because each tier,
and the devices that commonly straddle them, really have distinctive
characteristics. An access device really does not share
characteristics with a core device in a larger network.
Another method was to create additional core layers for major
geographic levels, such as national and intercontinental. Figure 5
shows the logical design I did for an international manufacturing
company, which had relatively little communications among their
regions, but all regions had significant communications with
headquarters. It was reasonable to have all inter-region
communication go through headquarters.
Figure 5: Multilevel Enterprise Core--Centralized Organization
In this figure, note that the headquarters users and central servers
were treated as a virtual region, rather than putting them into the
core. The core should only be used for communications and carefully
selected network management devices, never for application servers.
Not every enterprise has the same requirements. Figure 6 shows my
logical design for a worldwide transportation company that had both
extensive inter-region communications, plus an Internet connectivity
requirements from each region.
Figure 6: Multilevel Enterprise Core--Distributed Organization
This model worked acceptably for centrally controlled enterprises,
but did not scale well for inter-enterprise networks such as credit
card authorization. Large banks, for example, needed to optimize
their own cores for internal use, but needed to connect to the credit
authorization network. The logical characteristics of such networks
fit best into the distribution tier, which becomes the place of
interconnection.
Interconnecting at the distribution tier allowed the core to return
to its original simple-and-fast role of interconnecting sites inside
one organization. The requirement for a distribution layer function
between access and core, however, did not disappear. Increasingly,
network architects defined two distinct sets of function at the
distribution tier: the traditional one between core and access, and
a border function concerned with inter-organizational connectivity
(Figure 7). Border functions could deal both with controlled
cooperative relationships (e.g., a bank to the Visa or MasterCard
service networks, or to the Federal Reserve), and to the Internet via
firewalls.
Figure 7: Distribution Tier Evolution
This model has its limitations in dealing with provider environments.
Figure 8 shows some of the ambiguity with which many providers
approached the model. The provider called their own POP entry point
access. There are a variety of names for interprovider connection
devices, but border router is gaining popularity.
Figure 8: Data Carrier Interconnection Evolution
Matters become especially confusing when referring to "the
thing at the customer site that connects to the provider." This
"thing" is sometimes called a subscriber access device, but certainly
that makes the term "access" rather ambiguous. To complicate matters
even further, the "subscriber access device," with respect to the
enterprise network, is probably a device in the (enterprise
network's) distribution tier.
Entangling the terminology to yet another level, there is
usually a device at the customer location that establishes the
demarcation of responsibility between subscriber and provider. It
may be either a simple interface converter and diagnostic box, or a
full-functioned router or switch.
The general terms customer premises equipment (CPE) and customer
location equipment (CLE) have emerged, but still may have some
ambiguity. The basic assumption is that the customer owns the CPE
and the provider owns the CLE, but operational responsibility may
vary from that. For example, I own my DSL access router, but I don't
have the configuration password to it; my ISP does.
CPE, not CPE
A telephony tradition resulted in a good deal of confusion, due to
acronym collision. Traditionally, "CPE" meant customer premises
equipment. In the traditional telco environment, CPE was, of course,
owned and operated by the carrier.
As more and more deregulation affected the industry, customer
premises equipment variously could be owned and operated by the
customer, leased to the customer by the provider, owned by the
customer but operated by the provider, or owned and operated by the
subscriber. Redefining the former CPE into CPE and CLE at least
identified operational responsibilities.
The customer, of course, may have a complex enterprise network. What
we think of as CLE or CPE, however, is an increasingly intelligent
interface between customer and provider. The interface may contain a
firewall functionality, which can be either at the customer site or
at the POP. As seen in Figure 9, the customer edge function may
contain equipment to multiplex outgoing Internet traffic, VPNs, and
VoIP onto a broadband access facility.
Figure 9: Intelligent Edge--Subscriber Side
Any of the edge devices may be managed by the provider; at least one
device normally will. If the provider allows the subscriber to manage
their own device, the provider will have ironclad configuration
settings, which are not negotiable.
Service Provider Models
The hierarchical enterprise model was useful, but did not quite fit
modern service provider networks, independently of whether the
provider was data or voice oriented. Particular problems came from
increased competition, with competition both in the internetwork core
and in the local access system.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=19096&t=19069
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
