● “Greenfield” – A brand new network that you design from the ground up.

● “Brownfield” – An existing network for which you are asked to apply changes
or implement new features.
● Network design concepts almost always apply best to greenfield
deployments. It can be difficult, if not impossible, to apply network design
concepts (related to IP addressing and routing) to existing networks
("Brownfield deployments")
● In flat or meshed network architectures, changes tend to affect a large number
of systems. Hierarchical design helps constrain operational changes to a
subset of the network.
● ---- Single sites might only require a collapsed core model (Access and
Distribution Layers only)
● ---- Campus and large Enterprises with multiple buildings or sites should use
all three layers
● The Access Layer also:
● ---Supports PoE
● ---Applies QoS markings and (for LAN-to-LAN traffic across a single Access-
Layer switch) QoS Enforcement
● Notice that Layer-3 Routing typically is NOT implemented within the Access
Layer
● Distribution Layer is also responsible for enforcing security and authorization
policies for traffic coming from one, connected Access block (such as a
fileserver connected to an access switch in the “Data Center” block) and
destined for a device in another Access Layer block that is connected to the
same Distribution Block (ie. Traffic destined for a server connected to Data
Center Access-Switch-2).
● The above is referred to as “East-West” traffic because, from source to
destination, the traffic never needs to leave the Distribution Layer and be
forwarded to the Core.
● Because everything aggregates up to the Core, keep a close eye on
oversubscription levels for your traffic and bandwidth.
● Although initially the configuration is more complex and a good design HAS to
be planned, using BGP within your Enterprise offers several benefits:
[Link]
● A non-proprietary protocol can also be important if you will be implementing
automation. Many non-Cisco automation platforms only work with OSPF and
not EIGRP.
● EIGRP is a flat (non-hierarchical) IGP protocol which means: Without proper
summarization, route flaps could be felt everywhere in the network (Queries)
● EIGRP Variance (can be a quick fix for congested links rather than
implementing complex QoS policies)
● While it is not recommended that timers be different between IGP peers, this
can be useful on slow-speed WANs in which it is known that transmissions in
one direction have a definite delay that is higher-or-lower than transmissions
in the reverse direction (especially with multiaccess segments containing
three-or-more routers)
● Without manually setting the metric of a summarized route, the best metric of
all subset routes will be used...which could change if that subset route goes
away.

● In this diagram, the network policy is that the Core router should ALWAYS
forward packets through Rtr-C if ANY route exists for subnets 300-400.
● When you implement summarization between routers that are at the same
level of the model (for example, between two connected routers at the
Distribution Layer) it can make troubleshooting difficult and lead to other
problems.
● If possible, ensure all routers are using the same EIGRP Hello and Hold
timers (otherwise, peers with mismatched timers may time-out and declare
each other dead.
● Remember that the command, "ip hold-time eigrp" does not set your OWN
LOCAL hold-time but rather advertises to your peer what HIS hold-time should
be for your transmitted Hello packets).
● Leak-maps can also be utilized within the Enterprise when you need to leak
specific subnets that would normally be suppressed via summarization.
● Normally, if ”C” and “D” were configured with EIGRP Stub then neither router
would pass along the default route to the other. They would also not pass
along each other’s WAN subnets or their local 10.1.x.x/24 subnets. Leak-
maps would be required for this.
● When configured as a “stub-site”, any routes that ”C” or “D” learn over the
interface identified as the “wan-interface” get tagged (inbound) with a special
EIGRP community that contains the site-id (100:101 in this case) and then are
allowed to be forwarded to any stub-site peers.
● The stub-site peer will install the route but will NOT advertise the route
outbound on any of its “wan-interface(s)”.
● Any other routes covered by “network” or “summary-address” statements on
”C” or “D” will be advertised to each other as well as advertised on the WAN
link to “A” and “B”.
● So no leak-maps are required yet you still get the benefit of EIGRP Stub in
that routers ”A” and “B” will never forward EIGRP Queries to “C” or “D”.
● Also ensures that “A” and ”B” will never use the Remote Stub Site as a transit
path.
● Using this method, the internal cost to reach the ABRs are irrelevant as /24’s
will always be selected over a matching /16.
● While this method is more scalable as it follows the general rule of
”summarize as much as you can, wherever you can” it is less deterministic
than the previous method. If paths change within Area-X (or new paths are
introduced) the cumulative cost might become lower for internal routers to
reach ABR-2 instead of ABR-1.
● OSPF RFC 2328 (in section 2.3) identifies why External Type-1 and External
Type-2 were created.
● External Type-1’s are to be used when the path THROUGH YOUR OWN
OSPF DOMAIN is of more concern to you than the path packets take once
they LEAVE your domain.
● External Type-2’s (according to RFC 2328) are to be used when the path
packets take once they LEAVE your domain is of MORE IMPORTANCE than
the path packets take through your own OSPF domain.

● The downside to this approach is that the route that each router has will
always show up as “x” as a cost in the routing table and OSPF LSDB.
● So this gives you zero visibility into the path that is actually being selected in
your network to reach ASBR-1.
● If links are flapping within your network, and congestion is occurring because
packets are being forwarded on non-optimal links to reach ASBR1, you will
have no visibility into this by simply viewing the OSPF cost value of your
routes.
● With this approach you still meet your objective of having all routers prefer
ASBR-1 because O E1 is always preferred over O E2 (regardless of cost)
● However, each router’s routing table will now show you a cost value that more
accurately reflects the internal cost to reach ASBR1 and this can be tracked.
● Now, if internal paths to reach ASBR1 change, you can easily see this as a
new/different costs reflected in your external routes.
● Ensure that a matching summary route to Null0 exists to prevent routing loops
(this should happen by default but be sure to doublecheck).
● Scalability means limiting the size of OSPF LSDBs…and restricting how far
LSAs can travel.
● In this scenario, scalability involves eliminating as much as possible the OSPF
traffic flowing across the WAN links.
● Another benefit of P2P network type is that it eliminates Type-2 LSAs thus
reducing the overall size of OSPF LSDBs.
● LIMITATION: OSPFv3 (Cisco) doesn't currently support virtual-links
● If you suspect that an area may (in the future) contain an edge router that
must connect to a non-contiguous OSPF area that would normally require a
virtual link (eg. Partner, Acquisition, Merger, etc) create a secondary OSPF
process on the edge router and redistribute between the OSPF processes.
● This allows you to retain the benefits of OSPFv3
● Remember that NSSA areas with two-or-more ABRs connecting NSSA AREA-
X to Normal Area-Y, only ABR with highest router-ID will translate from Type-
7's to Type-5's.
● As a Link State protocol, this means that all routers within an area must share
a common IS-IS LSP database.
● max-lsp-lifetime 65535 --> maximum value (approximately 18.2 hours)
● Determine the set of routers that will become your IS-IS backbone and
configure these as Level-2 only
● Configure P2P routers at the remote ends of WAN connections as Level-1-2.
These will become your aggregation points
● Future routers added to existing remote sites should be configured as Level-1
only.
● With this design, prefix summarization can be performed on the L1/L2 routers
into the Core (Headquarters).
● IS-IS uses the following command for summarization: summary-address
<summarized prefix> <dotted-decimal mask>
● Remember that IS-IS L1 routers only create a default route to their nearest
L1/L2 router IF that router has generated an LSP with the “Attached” bit set.
And that bit is ONLY set when a L1/L2 router is “attached” to two or more
areas.
● An L1/L2 router (or a Level-2 only router) that has formed an adjacency with
another L1/L2 router (or an L2-only router) in another area is considered an
ABR (Area Border Router).
● In this scenario, without IS-IS LSP Leaking configured on router-X, routers C
and D would send all of their Inter-Area traffic to router-Y because it was
closer than router-X. This would lead to non-optimal traffic forwarding.
● Implement route filtering with as-path access-lists to ensure that only locally-
originated routes are advertised to each ISP (prevents your ASN from
becoming a Transit ASN).
● The Cisco Press book recommends that you implement a full-mesh of the core
iBGP routers, but I see no reason why route reflectors couldn’t be
implemented if the size of the core demands it.
● Because the IGP running in a single region doesn’t have any IGP peerings
with different regions, technically all regions COULD run the same EIGRP
ASN. While this could potentially simplify automation, it might also introduce
additional complexity into troubleshooting and potentially lead to unwanted
IGP peerings between regions (i.e., “Sites”) if you’re not careful.
● BGP was designed that a single BGP ASN should be under one source of
administrative control. So this topology would NOT be suitable if each Region
contains their own administrative control, claiming sole control over all aspects
of routers within their region.
● Since each regional router is located within its own unique BGP ASN, it makes
more sense here that the IGP be configured with its own unique AS (or
process-ID) as well.
● Without the command ”bgp best path compare-routerid”, if there is a tie in the
AS-Path length then the default behavior (for eBGP) is to select the path that
was learned first (the oldest path).
● If you know (when configuring BGP in the first place) that eBGP path selection
may come down to router-ids, this allows you to deterministically set your
router-ids in advance.
● BGP was designed that a single BGP ASN should be under one source of
administrative control. So this topology would be ideal if each Region contains
their own administrative control, claiming sole control over all aspects of
routers within their region.
● Each region would be responsible for the BGP policy of their own ASN.
● Remember to have a full-mesh of iBGP within the Core, unless you plan on
implementing Route Reflectors.
● If multiple Regional Routers exist within a region (like Router-3 and 4) they
would run iBGP between themselves.
● Because this topology is well-suited to providing administrative control to
groups of engineers who are each in charge of their own Region, it allows
engineers controlling Site-1 to determine the inbound BGP policy between
their routers and Router-A.
● Whether or not routers “A” and “B” are RR-Clients of the two Route Reflectors
depends on just how much redundancy you want in your network.
● When it comes to BGP, higher redundancy comes with a cost (greater BGP
resource consumption in the form of more duplicated BGP prefix entries and
more process time spent on best-path selection).
● Remember that if a RR receives a BGP update from one of its Clients…that
RR will reflect that update to other Clients as WELL AS non-Clients. So in this
case if RR1 receives an iBGP update from its client, if an iBGP peering exists
between RR1 and RR2, (whether these two routers are clients of each other
or not) RR2 will have the update reflected from RR1.
● If you WANT RR2 to store these reflected updates, it received from RR1 (as
potential backup paths for RR2) then both RR1 and RR2 need to have
different Cluster-IDs.
● If neither of the above conditions are true, then there is no need to have an
iBGP peering between RR1 and RR2.
● The “no-export” community only works if your eBGP peer also has another
eBGP peer. It will NOT prevent your eBGP peer from propagating the route to
his iBGP peers
● The “no-export” community is non-transitive so when your eBGP peer receives
the community it will REMOVE IT prior to forwarding the route to his iBGP
peers.
● From Cisco documentation:
● “The major benefit you achieve when you specify a BGP peer group is that a
BGP peer group reduces the amount of system resources (CPU and memory)
necessary in an update generation. In addition, a BGP peer group also
simplifies the BGP configuration. A BGP peer group reduces the load on
system resources by allowing the routing table to be checked only once, and
updates to be replicated to all peer group members instead of being done
individually for each peer in the peer group.”
● Remember that with OSPF you can’t control what OSPF LSAs are received
and placed into your Link State Database. But an inbound Distribute-List CAN
control if those LSAs are translated into routes for your Routing Table.
● This is especially important to do when working with EIGRP, as EIGRP
External routes have the worst (lowest preferred) Administrative Distance
value of all routing protocols (outside of iBGP).
● notice that we're setting the bandwidth here to "1" and the lower the
bandwidth...the higher the computed distance value.

● An EIGRP route's distance will increase as it goes further and further from the
redistribution point

● The route might quickly reach the point of "infinity" and no longer be
considered usable

● You don't have to put much other thought into the metric UNLESS you have
two-or-more redistribution points for the same routes.