BRKRST 2310 PDF

Deploying OSPF in a
Large Scale Network
BRKRST-2310
BRKRST-2310
14445_04_2008_c1 © 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 2
© 2006, Cisco Systems, Inc. All rights reserved. 1

Presentation_ID.scr
Deploying OSPF in a Large
Scale Network
Market Segments
Service Provider Deployments
Enterprise Deployments
Dialup Design techniques
Design Best Practices
Fast Convergence
OSPF as PE-CE Protocol
BRKRST-2310
Market Segments
Market Segments
a) Service Providers
b) Enterprise
Manufacturing
Retail
BRKRST-2310

Presentation_ID.scr
Service Providers
SP networks are divided
into pops
Transit routing information is
carried via BGP
IGP is used to carry next
hop only
Optimal path to the next hop
is critical
BRKRST-2310
Enterprise Retails
IGP scalability requirements
on retail side is on the Hub
and Spoke
OSPF were designed keeping
the Service Provider
infrastructure in mind
Lacks clear vision towards hub
and spoke architecture
Acquisitions brings more
topological restrictions
Distance Vector are better
choice for e.g., EIGRP,
RIPv2, ODR
BGP?
BRKRST-2310

Presentation_ID.scr
Enterprise Manufacturing
Closet type infrastructure for
host to host communications
Large number of end
devices connections
Campus networks
BRKRST-2310
Service Providers
Deployments
BRKRST-2310

Presentation_ID.scr
SP Deployment Characteristics
SPs should have only one POP POP
instance of IGP running
throughout the network Area 1 Area 2
BGP 1 BGP 1
(exceptions are there)
BGP carries
external reachability Area 6
IP Backbone
Area 3
BGP 1 Area0 BGP 1
IGP carries only next-hop BGP 1
POP POP
(loopbacks are better for e.g.,
Area 5
next-hop-self) Area 4
BGP 1 BGP 1
POP
POP
BRKRST-2310
SP Architecture
Major routing information is
~250K via BGP POP POP
Largest known IGP routing Area 1 Area 2

BGP 1 BGP 1
table is ~6–7K
Total of 267K IP Backbone
Area 6 Area 3
Area0
6K/267K ~ 2% of IGP routes in BGP 1
BGP 1
BGP 1
POP POP
an ISP network
Area 5 Area 4
A very small factor but has a BGP 1 BGP 1
huge impact on POP POP
network convergence!
BRKRST-2310

Presentation_ID.scr
SP Architecture
You can reduce the IGP size Regional
from 6K to approx the number Core
of routers in your network NMS
This will bring really

fast convergence RR WAN
Optimized where you must
and summarize where you can
Stops unnecessary flapping Access IGP
PE
PE PE
CE CE CE
BRKRST-2310
SP Architecture
The link between PE-CE Regional
needs to be known for Core
management purpose
NMS
BGP next-hop-self should be done on
all access routers—unless PE-CE are
BGP
on shared media (rare case)
RR WAN
This will cut down the size
of the IGP
For PE-CE link do redistributed
connected in BGP Access
These connected subnets should
ONLY be sent through RR to NMS for
management purpose; this can be
done through BGP communities
Link Suppression can be done in PE
OSPF via OSPF prefix PE PE
suppression feature
CE CE CE
BRKRST-2310

Presentation_ID.scr
OSPF Prefix Suppression
When OSPF is enabled on the interface, it always

advertises directly connected subnet
Only way to prevent the connected subnet to be advertised is to
make the link unnumbered (not possible on
broadcast segments)
Users may want to keep the links numbered for management
and troubleshooting purposes
WAN link routes can be suppressed to keep the routing

table smaller
Keep the network more secure
Makes the network more scalable
BRKRST-2310
OSPF Prefix Suppression (CLI)
Router Mode
[no] prefix-suppression
Suppress all prefixes except loopbacks and passive interfaces
Interface Mode
[no] ip ospf prefix-suppression [disable]
Suppress all prefixes on interface
Loopbacks and passive interfaces are included
Takes precedence over router-mode command
Disable keyword makes OSPF advertise the interface
ip prefix, regardless of router mode configuration
Available 12.4(15)T
BRKRST-2310

Presentation_ID.scr
SP Architecture
Where do we define area Regional
boundaries? WAN routers can Core
be the ABRs NMS
Hide the pop infrastructure

from your core WAN ABR
Traffic engineering if needed
can be done in core from
WAN routers Access Area
PE
PE PE
CE CE CE
BRKRST-2310
SP Architecture
Physical address between ABR and
PE should be in a contiguous blocks Regional
Core
These physical links should be filtered NMS
via Type 3 filtering from area 0 into
other areas or suppressed via prefix
suppression feature Area 0
Why? To reduce the size of the routing
table within each pop WAN
ABR
Every area will carry only loopback
addresses for all routers Access
Only NMS station will keep track of
Area 1
those physical links
These links can be advertised in BGP
via redistribute connected
PE
PE device will not carry other Pop’s PE PE
PE’s physical address in the
routing table CE CE CE
BRKRST-2310

Presentation_ID.scr
SP Architecture
Area 0 will contain all
the routes POP
POP
This is the most intelligent Area1 Area 2
form of routing and also there BGP 1 BGP 1
will not be too many routes
in IGP Area 3
IP Backbone Area 6
BGP 1 Area 0
If there are 500 pops and BGP 1
BGP 1
POP POP
every pop contains 4 routers;
Area 4 Area 5
then instead of BGP 1 BGP 1
having 6K routes you will only POP POP
have 2K
This is scalable and hack
proof network!
BRKRST-2310
Dealing with Redistribution
Don’t do it!
If you’re an SP you shouldn’t be carrying external
information in your IGP
Let BGP take care of external reachability
Use OSPF or to carry only next-hop
information—i.e., loopbacks
BRKRST-2310

Presentation_ID.scr
Enterprise
Deployments
BRKRST-2310
Enterprise Retail
OSPF is not a very good
choice for hub and spokes
Enhancements are being
made in IETF to make OSPF
more robust on hub and spoke
EIGRP, ODR, RIPv2 and
BGP are better choices at
the moment
Enterprise BGP is
not complicated
You do not need to play with
lot of attributes
BRKRST-2310

Presentation_ID.scr
OSPF Border Connections
Dual homed connections in Summarization
hub and spoke networks

Backbone C
illustrate a design challenge in B
OSPF: connections parallel to A
an area border
Assume the D to E link is in D
E
area 0 ABR-1 ABR-2
If the D to E link fails, traffic
from A to F will:
Route towards the summary
advertised by D Area 1
G
Route via the more specific along
F
the path G, E, F
BRKRST-2310

Backbone Area
Let’s take a closer look at 100
B
the problem 10 10
ABR-1 ABR-2
Traffic prefers to stay within 10.1.1.0/24, cost 10
the area no matter what the
actual link costs are 100 A
To reach A, we will take the higher Area 1
cost link if the border link is in
the backbone Backbone Area
To reach B, we will take the higher 100
B
cost link if the border link is in
10 10
the area ABR-1 ABR-2
10.1.1.0/24, cost 10
This is because we will always use
an intra-area path over an
inter-area path 100 A
Area 1
BRKRST-2310

Presentation_ID.scr
Backbone Area
Then, either: 100
B
Decide which traffic you want to 10 10
route optimally ABR-1 ABR-2
10.1.1.0/24, cost 10
Use either virtual circuits (sub-
interfaces) or real links to create
one adjacency between the ABRs 100 A
per routed area Area 1
Configure the link in Area 1 Backbone Area
with a virtual link in backbone 100
B
(won’t work for more than
10 10
1 area) ABR-1 ABR-2
10.1.1.0/24, cost 10
100 A
Area 1
BRKRST-2310
Enterprise Retail
Summarization of areas will
require specific routing information
between the ABR’s
This is to avoid suboptimal routing
The link between 2 hub routers
should be equal to the number
of areas
As you grow the number of areas,
you will grow the number of
VLAN/PVC’s–scalability issue
Possible solution is to have a
single link with adjacencies in
multiple areas (draft-ietf-ospf-
multi-area-adj-07.txt)
Trunk with One VLAN in Each Flooding Domain

BRKRST-2310

Presentation_ID.scr
OSPF Hub and Spoke
Every router within a flooding
domain receives the
same information
A Reachability
Although B can only reach C Only
through A, it still receives all of C’s
routing information
Through A
Because of this, OSPF B D

requires additional tuning for
hub and spoke deployments
All Link
State
C Information
Is Flooded
to B
BRKRST-2310
OSPF Hub and Spoke

One of our primary goals is to
control the amount of flooding Block Flooding Here
towards the remotes
A
You can reduce flooding by
configuring the hub not to flood
any information to the remotes
at all B D
ip ospf database-filter all out
The remote routers must
supply their own remote, or the
hub router must originate a
default locally C
This isn’t a
Static Routes Here
common configuration
BRKRST-2310

Presentation_ID.scr
OSPF Hub and Spoke
The spoke areas should always router ospf 100
area 1 stub no-summary
be the “most stubby” you can get ....
away with
router ospf 100
If possible, make them totally stubby area 1 nssa no-summary
If there is redistribution at the spokes, ....
make the area totally not-so-stubby ABR
The fewer spokes in each area
the less flooding redundancy
Area 1
However, less can be summarized
in the backbone and a separate
sub-interface is needed per area
Totally stubby makes more sense
in multiple area situation
router ospf 100

redistribute rip metric 10
....
BRKRST-2310
OSPF Hub and Spoke: Network Types

OSPF could treat a multi-point interface s0/0
ip address 10.1.1. 255.255.255.0
link as a broadcast network or ip ospf priority 200
NBMA, but there are issues ....
interface s0
with flooding and forwarding ip ospf priority 0
....
B and D don’t receive C’s packets, “C Is DR”
so they think A has the highest IP A
address, and elect A as DR
C elects itself as DR
Flooding will fail miserably in
this situation
B C D
We can set the OSPF DR
priorities so the hub router is “A Is DR” “C Is DR” “A Is DR”
always elected DR
Set the spokes to 0 so they don’t
participate in DR election
BRKRST-2310

Presentation_ID.scr
OSPF Hub and Spoke: NBMA/Broadcast
OSPF will still have forwarding
issues since the OSPF
broadcast and NBMA assume
a full mesh
There is bi-directional
connectivity between A and B, A
C, and D
B, C, and D cannot
communicate amongst
themselves and traffic will be
black-holed
One can get around this using B C D
DLCI routing at the Frame
Relay layer
BRKRST-2310
OSPF Hub and Spoke: P2MP

You can also configure the
serial interface at the hub interface s0/0
router as a ip address 10.1.1.1 255.255.255.0
ip ospf network point-to-multipoint
point-to-multi-point type
All the remotes are in a single
IP subnet 10.1.1.2/32
OSPF treats each remote as a A 10.1.1.3/32
separate point-to-point link 10.1.1.4/32
for flooding ....
OSPF will advertise a host

route to the IP address of each C D
B
spoke router to
provide connectivity
Smaller DB Size compare
to p2p interface s0
ip address 10.1.1.x 255.255.255.0
Most natural OSPF solution ip ospf network point-to-multipoint
BRKRST-2310

Presentation_ID.scr
OSPF Hub and Spoke: P2P Sub-
Interfaces
interface s0/0.1 point-to-point
OSPF can also use point-to- ip address 10.1.1.0 255.255.255.254
point sub-interfaces, treating ....
each one as a separate point- ip address 10.1.1.2 255.255.255.254
to-point link ....
Increase the DB size ip address 10.1.1.4 255.255.255.254
A
These use more address
space and require more
administration on the router
Use /31 addresses for these point
to point links
B C D
interface s0.1 point-to-point

ip address 10.1.1.x 255.255.255.254
....
BRKRST-2310
OSPF Hub and Spoke
Network Type Advantages Disadvantages
Manual Configuration
of Each Spoke with the Correct
Single Interface Single IP Subnet
OSPF Priority
at the Hub Treated as an OSPF Fewer Host Routes
Broadcast or NBMA Network No Reachability Between
in Routing Table
Spokes or Labor-Intensive Layer
2 Configuration
Single Interface Single IP Subnet

at the Hub Treated as an OSPF
No Configuration per Spoke Additional Host Routes Inserted
Point-to-Multipoint Network
Most Natural Solution in the Routing Table
ip ospf Network-Type
Point-to-Multipoint Smaller database
Lost IP Address Space
Individual Point-to-Point
Interface at the Hub Can Take Advantage of End- More Routes
for Each Spoke to-End Signaling for Down in the Routing Table
ip ospf Network-Type State Larger database
Point-to-Point
Overhead of Sub-Interfaces
BRKRST-2310

Presentation_ID.scr
OSPF Hub and Spoke
The other consideration is
determining how many spokes
should fall within the area
If the number of remotes Small Number
Backbone of Spokes
are low, we can place the hub
and its spokes within an area
Summarize Here
However, as the count rises, ABR Large Number
we want to make the hub an of Spokes
ABR, and split off the spokes
in a single area
If you’re going to summarize
into and out of the remotes,
the hub needs to be a
border router Area 1
BRKRST-2310
OSPF Hub and Spoke

Low speed links and large
numbers of spoke may require
multiple flooding domains Backbone
Balance the number of
flooding domains on the
hub against the number of
Area 2
spokes in each Area 1
flooding domain
The link speeds and the
amount of information being
passed through the network
determines the right balance
BRKRST-2310

Presentation_ID.scr
Enterprise Manufacturing
Can have multiple ‘islands’
of IGPs
Canada
Islands tied together by a Brazil
BGP core IGP 5
IGP 6
One Island’s instability will not
impact other Islands
This increases IGP 1 BGP Core IGP 4
network stability
USA Japan
May be a requirement
for redistribution IGP 2 IGP 3
France
Germany
BRKRST-2310
The number of redistribution boundaries should be kept

to a minimum
Why?
Because you have better things to do in life besides; build the
access lists
When redistributing try to place the DR

as close to the ASBR as possible to minimize flooding
BRKRST-2310

Presentation_ID.scr
Be aware of metric requirements going from one

protocol to another
RIP metric is a value from 1–16
OSPF Metric is from 1–65535
Include a redistribution default metric command as a

protection
router ospf 1
network 130.93.0.0 0.0.255.255 area 0.0.0.0
redistribute rip metric 1 subnets
BRKRST-2310
Redistribute only what is absolutely necessary

Don’t redistribute full Internet routes
into OSPF
Default route into BGP core; let the

core worry about final destination
BRKRST-2310

Presentation_ID.scr
Dialup Design Tips
BRKRST-2310
Dialup Design Practices

Two kinds of Pools can
be defined on NAS: Static
Pools and Distributed Pools
Static Pool: address range
remain within a single NAS— Core
easier to manage from routing
perspective
Dynamic Pool: address range Agg. Router
may be distributed over
multiple NAS’s—hard to
manage from a
routing perspective
…
1000+ Routes Injected
by Each NAS
BRKRST-2310

Presentation_ID.scr
Dialup Design with
Static Pool Addresses
Three ways to propagate
dialup routes from NAS:
Either Static route to pool address
to null 0 with redistribute static on
NAS or
Assign the pool add on a loopback Area 0
on NAS with OSPF p2p network-
type including loopback in an
OSPF area or
Static route on ABR for the pool ABR
address pointing towards NAS
(ASBRs)—
Static pool do not require …

redistribute connected subnets
on NAS 1000+ Routes Injected
by Each NAS
BRKRST-2310
Dialup Design with

Dynamic Pool Addresses
Distributed pool REQUIRES
redistribute connect subnets
If pool is distributed, you can’t
summarize the pools at ABR
because of redistribute
connected subnets on NASs’ Area 0
unless its an NSSA, why?
NSSA can summarize the
ABR
Type 7 routes at the ASBR as NSSA
well as ABR
…
by Each NAS
BRKRST-2310

Presentation_ID.scr
Dialup Design
Practices Scalability Issues
If an area has too many routes
injected by NAS then break it
up into more than one area
Area should be configured as Area 0
NSSA for controlling type 5 at
ABR level
ABR
NSSA ABR can filter type 5
originated by NAS servers Area 1 Area 2
Configure totally NSSA to filter

internal area routes from
NAS
… … NAS
each other NAS NAS

by Each NAS
BRKRST-2310
BRKRST-2310

Presentation_ID.scr
Accidental Redistribution
Prevention (OSPF)
Areas should be defined as
stub to prevent accidental
redistribution of eBGP into OSPF
eBGP
Type 3 LSA filtering should be ABR eBGP
used at ABR’s and only routers’
loopbacks should be allowed to OSPF OSPF
leak into other areas Stub Area Stub Area
POP POP
Loopback should be in private
address space to make LSA type iBGP Core/Area 0
3 filtering easier; for POP
e.g., 10.0.0.0/8 OSPF
OSPF POP
iBGP routes can not be Stub Area
Stub Area
redistributed into IGP by default
eBGP eBGP
NMS resides in area 0 here
BRKRST-2310
Area Size: How Many Router in an Area?
Number of adjacent neighbors is more a factor

More important from the standpoint of amount of
information flooded in area
Keep router LSAs under MTU size—
exceeding is bad
Implies lots of interfaces (and possibly lots of neighbors)
Exceeding results in IP fragmentation which should
be avoided
BRKRST-2310

Presentation_ID.scr
OSPF Border Area Filtering: Ranges
Backbone 3.3.1.0
1.1.1.0 Area 0 3.3.2.0
1.1.2.0 3.3.3.0
1.1.3.0 3.3.4.0
1.1.4.0
2.2.1.0
2.2.2.0 3.3.1.0 3.3.4.0
1.1.1.0 1.1.4.0 2.2.3.0
2.2.1.0 3.3.4.0
1.1.2.0 1.1.3.0 3.3.3.0
2.2.3.0
2.2.2.0
Only summary LSA advertised out
Link-state changes do not propagate
BRKRST-2310
OSPF Border Area Filtering: Ranges
Backbone
1.0.0.0 Area #0 3.0.0.0
2.0.0.0
1.1.1.0 1.1.4.0 3.3.1.0 3.3.4.0
2.2.1.0 3.3.4.0
1.1.2.0 1.1.3.0 3.3.3.0
2.2.3.0
2.2.2.0
Only summary LSA advertised out
Link-state changes do not propagate
BRKRST-2310

Presentation_ID.scr
Summarization Technique
Configure on Both ABRs

Area 0
Area-Range 11.1.0/17
Area-Range 11.1.128/17
ABR1 ABR2
Cost to Range 1:
Via ABR1: 30 10
Via ABR2: 80 R3 Area 10 10
11.1/16 11.1.129/24
Cost to Range 2:
11.1.1/24 50 R4
Via ABR1: 80 50
Via ABR2: 30 20
20
R6
11.1.2/24 R5
11.1.130/24
BRKRST-2310
OSPF Border Inter-Area Filtering
Type-3 LSA filtering on ABR

Uses prefix-list to filter prefixes from being advertised
from/to a specific area
Works both directions—out of a specific area or into a
specific area
BRKRST-2310

Presentation_ID.scr
OSPF and Filtering: Inter-Area Filtering
Area 1 OSPF Backbone Area 0

LSA Type 3
LSA Type 3
LSA Type 3
LSA Type 3 Area 4
Out Filter Applied Here
In Filter Applied Here
LSA Type 3
Area 2 Area 3
area 0 filter-list prefix AREA_0_OUT out

area 0 filter-list prefix AREA_0_IN in
BRKRST-2310
OSPF Full Mesh

Full Mesh Topologies Are Complex:
2 routers == 1 link
3 routers == 3 links
N routers == ((N) (N-1)) / 2
…
BRKRST-2310

Presentation_ID.scr
OSPF Full Mesh
Flooding routing information
through a full mesh topology is the
MAIN concern
Each router will, with optimal timing,
receive at least one copy of every new
piece of information from each neighbor
on the full mesh
Link down is n2 and node down is

n3. For a very large router LSA it
could become n4
There are several techniques you
can use to reduce the amount of
flooding in a full mesh
Mesh groups reduce the flooding in a
full mesh network
Mesh groups are manually configured
“designated routers” New Information
BRKRST-2310
OSPF Full Mesh

Pick a subset (>=2) of routers
to flood into the mesh and
block flooding on the
remainder; leave flooding to
these routers open
This will reduce the number of
times information is flooded
over a full mesh topology
! Point-to-Point
interface serial 1/0
ip ospf database-filter all out
....
! Point-to-Multipoint New Information

router ospf 1
neighbor 10.1.1.3 database-filter all out
BRKRST-2310

Presentation_ID.scr
OSPF Flood Reduction
LSA have an age (1–3600)
When LSA is originated its age is set to 0
LSA is flushed from the area/domain when its age
reaches MAXAGE (3600 sec)
Each router must periodically refresh all self-generated
LSAs every 1800 seconds (jittered)
Demand Circuits (RFC 1793) introduces concept of
DoNotAge LSAs—high order or DoNotAge bit of LSA
header age indicates not to age the LSA
RFC 4136 extends this concept to all interface types
Eliminates periodic refresh of unchanged LSAs
BRKRST-2310
OSPF Flood Reduction (Cont.)

Configured at interface level
! All interfaces types

interface ethernet 0/0
ip ospf flood-reduction
....
Very useful in fully meshed topologies
Possible extension to force refresh at an increased interval, e.g.
every four hours; currently not implemented
Changes could be missed if the sum of the changes results in an
identical checksum
Periodic refresh provides recovery from bugs and glitches
BRKRST-2310

Presentation_ID.scr
Fast Convergence
Detect the Event, Process the Event
BRKRST-2310
Fast Convergence
Network convergence is the time needed for traffic to

be rerouted to the alternative or more optimal path after
the network event
Network convergence requires all affected routers to
process the event and update the appropriate data
structures used for forwarding
Network convergence is the time required to:
Detect the event
Propagate the event
Process the event
Update the routing table/FIB
BRKRST-2310

Presentation_ID.scr
Network Convergence
Techniques/tools for fast convergence
Carrier Delays Detect
Hello/dead timers Detect
Bi-Directional Forwarding Detection—(BFD) Detect
LSA packet pacing Propagate
Interface event dampening— Propagate
Exponential throttle timers for LSA & SPF Process
MinLSArrival Interval Process
Incremental SPF Process
Techniques/tools for Resiliency
Stub router (e.g., max-metric)
Graceful Restart
BRKRST-2310
OSPF Stub Router (RFC 3137)

E is learning 10.1.1.0/24 10.1.1.0/24
through iBGP from D with a
next hop of A; E’s best path to
A is through D C Starts and A
Provides a Better
eBGP
C comes up, and OSPF Path to A
converges quickly; E now Original
Best Path
chooses C to reach A 10 B 20 to A
BGP takes longer to converge; C D

when E forwards packets to C
for 10.1.1.1, C hasn’t finished 10 20
building its BGP tables
C Has No
C drops the packets Path to
E Full iBGP
10.1.1.0/24
Mesh
Not to Be Confused with Stub Areas

BRKRST-2310

Presentation_ID.scr
OSPF Stub Router
C signals E and B through 10.1.1.0/24
OSPF that they should not
route this direction (through
stub router) A
eBGP
When BGP converges, C
changes back to its normal
metric, so B and E will now 65535 B 20
route through it
C D
OSPF uses max-metric router-
lsa on-startup wait-for-bgp to 65535 20
E
configure this feature Don’t Use Me Yet! Full iBGP
Mesh
BRKRST-2310
Stub Router Advertisement

max-metric router-lsa [ on-startup {wait-for-bgp | <announce-time>} ]
Syntax Description
router-lsa Always originate router-LSAs with maximum metric
on-startup Set max-metric temporarily after reboot
announce-time Time, in seconds, router-LSAs are originated with max-
metric (default is 600s)
wait-for-bgp Let BGP decide when to originate router-LSA with normal
metric (i.e., stop sending router-LSA with max-metric)
Can be used to take a router out of service since default is indefinite
BRKRST-2310

Presentation_ID.scr
Stub Router: show ip ospf max-metric
OSPF allows for a r201#sh ip ospf max-metric
Routing Process "ospf 1" with ID 1.0.0.201
configurable option to wait for
Start time: 00:00:01.876, Time elapsed: 00:00:56.668
BGP at startup Originating router-LSAs with maximum metric, Time
remaining: 00:00:09
OSPF announces maximum Condition: on startup for 66 seconds, State: active
metric while BGP is coming up
r201#sh ip ospf max-metric
This enhancement shows real- Routing Process "ospf 1" with ID 1.0.0.201
time status on what is Start time: 00:00:01.876, Time elapsed: 00:01:12.560
happening internally Originating router-LSAs with maximum metric
Condition: on startup for 66 seconds, State: inactive
Unset reason: timer expired, Originated for 66 seconds
Unset time: 00:01:07.932, Time elapsed: 00:00:06.504
r201#sh ip ospf 2 max-metric

Routing Process "ospf 2" with ID 2.2.2.2
Start time: 00:07:42.052, Time elapsed: 00:00:20.684
Router is not originating router-LSAs with maximum metric
BRKRST-2310
Graceful Restart
Non Stop Forwarding, Grace Restart
BRKRST-2310

Presentation_ID.scr
Graceful Restart
Graceful Restart (GR) allows a
router’s control plane to reset
without impacting A
global routing
Consider two routers
connected over a single circuit
BRKRST-2310
Graceful Restart
Router A loses its control
plane for some period
of time A Control Data
It will take some time for

Router B to recognize this
failure and react to it
B Control Data
BRKRST-2310

Presentation_ID.scr
Graceful Restart
During the time that A has Reset
failed and B has not detected
the failure, B will continue A Control Data
forwarding traffic through A
Once the control plane resets,
the data plane will reset as
well, and this traffic will
be dropped
NSF reduces or eliminates the
traffic dropped while A’s
control plane is down
B Control Data
BRKRST-2310
Graceful Restart
If A is NSF capable, the No Reset
control plane will not reset the
data plane when it restarts A Control Data
Instead, the forwarding

information in the data plane is
marked as stale
Any traffic B sends to A will
still be switched based on the
last known
forwarding information
B Control Data
Mark Forwarding
Information as Stale
BRKRST-2310

Presentation_ID.scr
Graceful Restart
While A’s control plane is
down, B’s hold timer
counts down A Control Data
A has to come back up and

signal B before B’s hold timer
expires, or B will route
around it
When A comes back up, it
signals B that it is still
forwarding traffic and would
like to resynchronize
B Control Data
A and B get resynchronized
and this completes the
NSF process Hold Timer: 15
6
7
8
9
10
11
12
13
14
BRKRST-2310
Graceful Restart
NSF is a protection scheme
NSF and fast hellos/BFD do A Control Data
not go well and should
be avoided
NSF makes more sense in a
singly homed edge devices
Multihomed edge devices
should go on restoration
scheme instead and switch
over to the alternate path
B Control Data
BRKRST-2310

Presentation_ID.scr
Graceful Restart Mechanism Comparison
GR Signaling Resynchronization
Cisco NSF Out-of-Band Synchronization

(LLS/OOB) Link Local Signaling (LLS), (OOB), Creates a New Form of
Extending Hellos to Add Synchronization (Similar to
RFC 4811, 4812, Optional Information Standard Database
4813 Synchronization)
IETF RFC 3623 Grace LSA Normal Database Exchange

(Opaque LSAs) (Opaque Link Local LSA) (Adjacency Advertised as FULL)
BRKRST-2310
OSPF as PE-CE
MPLS Related Techniques
BRKRST-2310

Presentation_ID.scr
OSPF as PE-CE Routing Protocol
Different OSPF Process ID
In service provider networks, the OSPF process id should match, otherwise external type-5 routes
are generated
Site 2 expects Type-3 inter-area routes from Site1 via PE2 but instead receives external type-5
OSPF process-ID is usually locally significant. In MPLS VPN, consider service provider cloud acting as a single
router from OSPF perspective
Instead of removing and reconfiguring the OSPF process, service provider may configure same domain-id on
both ingress and egress PEs to solve the problem
Mismatch ospf process id
VPN-IPv4 Update router ospf 1 vrf <name>
router ospf 2 vrf <name> RD:Net-1, Next-hop=PE-1 domain-id 99
RT=xxx:xxx
domain-id 99 OSPF-Route-Type= 1:2:0
OSPF-Domain: xxx
OSPF-RID= PE-1:0
Provider Edge Router
PE-1 MPLS-VPN Backbone
(PE) PE-2
Type-3 (Summary-LSA)
Type-5 (External-LSA) Link-State-ID: C-1
Link-State-ID: Net-1 Link-ID: Net-1
Type-1 (Router-LSA)
Adv. Router: PE-2 Adv. Router: PE-2
Link-State-ID: C-1
Metric : 20
Link-ID: Net-1
Area: 1
Adv. Router: C-1
CE-1 CE-2 Site2 - Area 2
Net-1
Site1 - Area 1
BRKRST-2310
C-1

Summarization (Ingress PE)
Customer wants to send a summary route to all other sites from site1 (area 1)
Summarization not possible since ABR does not exist in site1
Provider can summarize in BGP and advertise a aggregate block to all other sites
router bgp 1
…
address-family ipv4 vrf <name>
aggregate-address 30.1.0.0 255.255.0.0 summary-only
VPN-IPv4 Update
RD:30.1.0.0, Next-hop=PE-1
RT=xxx:xxx
atomic-aggregate
BGP
BGP
PE-3
PE-1 PE-2
OSPF Type-5 (External-LSA) OSPF
Link-State-ID: 30.1.0.0
Adv. Router: PE-2
Site1/Area 1 Metric : 20
30.1.1.0 - 30.1.255.0 Site2/Area 2 Site3/Area 3
CE-1 CE-3
CE-2
BRKRST-2310

Presentation_ID.scr
Summarization—Egress PE
Customer needs to send a summary route to site3–area3

Customer can’t summarize from each individual site. No ABR exists within
the site (area 1 or area 2)
Service provider can summarize all the other site routes on PE3
router ospf 1 vrf <name>
summary-address 30.0.0.0 255.0.0.0
VPN-IPv4 Update VPN-IPv4 Update

RD:30.1.1.0, Next-hop=PE-1 RD:30.2.1.0, Next-hop=PE-2
RT=xxx:xxx RT=xxx:xxx
MED: 68 MED: 58
OSPF-Route-Type= 1:2:0 OSPF-Route-Type= 2:2:0
OSPF-Domain:xxx OSPF-Domain:xxx
BGP
BGP BGP
BGP PE-3
PE-1 PE-2
OSPF OSPF
OSPF OSPF
Type-5 (External-LSA)
Type-3 (Summary- Adv. Router: PE-3
LSA) Metric : 58
30.1.1.0 - 30.1.255.0 30.2.1.0 - 30.2.255.0
Link-State-ID: C-1
Link-ID: 30.1.1.0
CE-1
Adv. Router: PE-2 CE-3
Sit1-Area 1 Site2- Area 2 CE-2 Site3-Area 3
BRKRST-2310

Summarization—Egress PE—Loop Prevention
Summary is originated in OSPF

Summary route will be propagated to all customer sites as a result of redistribution from OSPF into BGP
Summary route should be filtered while redistributing OSPF into BGP on PE3 unless it is desirable to send
summary to some select PEs
router bgp xx
address-family ipv4 vrf vpna
redistribute ospf 99 vrf vpna route-map block_summary
VPN-IPv4 Update
route-map permit 10 block_summary
RD:30.0.0.0, Next-hop=PE-3 match ip address 99
RT=xxx:xxx
MED: 58 access-list 99 deny 30.0.0.0 0.0.0.255
OSPF-Route-Type= 0:5:0 access-list 99 permit any
BGP
x
OSPF-Domain:xxx
PE-3
PE-1
PE-2
OSPF
30.0.0.0/8 summary route Type-5 (External-LSA)
Area 1 Adv. Router: PE-3
Area 2 Area 3
Metric : 58
30.1.1.0 - 30.1.255.0 30.2.1.0 - 30.2.255.0
router ospf 1 vrf <name>
CE-1 summary-address 30.0.0.0
CE-3
CE-2 255.0.0.0
BRKRST-2310

Presentation_ID.scr
OSPF as
PE-CE Protocol
Area Placement Considerations
BRKRST-2310
Common Design Consideration:

OSPF Area Placement
OSPF sites have area 0

OSPF sites belong to different areas
All OSPF sites belong to the same area
No backdoor exists
Backdoor is present
BRKRST-2310

Presentation_ID.scr
Common Design Consideration–OSPF Area Placement
OSPF Sites Have Area 0
Type 1 or Type2 LSA converted into summary LSA by the Customer ABR
Local PE receives a Type-3 LSA and remote PE forwards the same Type LSA towards the remote CE
VPN-IPv4 Update
RD:Net-1, Next-hop=PE-1
RT=xxx:xxx
MED: 6
OSPF-Route-Type= 0:3:0
OSPF-Domain:xxx MPLS-VPN Backbone
PE-1
Type-3 (Summary-LSA) PE-2
Down Bit Is NOT Set Type-3 (Summary-LSA)
Link-State-ID: Net-1 Down Bit Is Set
Adv. Router: CE-1 Link-State-ID: Net-1
Metric: 6 Area 0 Area 0 Adv. Router: PE-2
Metric: 6
CE-1
Type-1 Router-LSA Link-ID: CE-2
Net-1
Adv. Router: x.x.x.x
Type-3 (Summary-LSA)
Area 1
Area 2 Down Bit Is Ignored
Type-2 Network-LSA Link- Network = Net-1 Link-State-ID: Net-1
or State-ID: Net-1 Adv. Router: CE-2
Adv. Router: x.x.x.x Metric: 6
BRKRST-2310
Common Design Consideration—OSPF Area Placement

OSPF Sites Belong to Different Areas
Area 0 is not mandatory when migrating to MPLS VPN service

VPN sites may have different Sites configured for different areas
If Area 0 exists, it must touch MPLS VPN PE routers
VPN-IPv4 Update
RT=xxx:xxx
MED: 6
OSPF-Domain:xxx
MPLS-VPN Backbone
OSPF-RID= PE-1:0
PE-1 PE-2
Type-1 (Router-LSA) Type-3 (Summary-
Link-State-ID: Net-1 LSA) Down bit is set
Metric: 6
CE-1
CE-2
Network = Net-1
Site1 Site2
BRKRST-2310

Presentation_ID.scr
All Sites Belong to the Same Area—Backdoor Does Not Exist
All VPN sites belong to same OSPF area (area 1 in the example)
Service provider PEs acts as OSPF ABR routers
Type1 or 2 LSA are always converted into Type 3
Remote Site receives a summary LSA
Not an issue if the topology for simple topologies
VPN-IPv4 Update
RT=xxx:xxx Type-3 LSA created even though
MED: 6 local area number is same
OSPF-Domain:xxx
MPLS-VPN Backbone
OSPF-RID= PE-1:0
PE-1 PE-2
Type-1 (Router-LSA) Type-3 (Summary-

Link-State-ID: Net-1 LSA) Down bit is set
Metric: 6
CE-1 CE-2
Network = Net-1
Site1 Site2
BRKRST-2310

All Sites Belong to the Same Area—Backdoor Exists
Customers Sites are in the same area and there is a backdoor link
Route is advertised to MPLS VPN backbone
Same prefix is learnt as intra-area route via backdoor link
PE2 does not generate Type3 LSA once type-1 LSA is received from the site
Traffic is sent over backdoor link instead of MPLS VPN cloud
VPN-IPv4 Update
RT=xxx:xxx No LSA Type 3 created
OSPF-Route-Type= 1:2:0 MPLS VPN Backbone Not used
OSPF-Domain: xxx
OSPF-RID= PE-1:0 MPLS-VPN Backbone
PE-1 PE-2
Type-1 (Router-LSA)
Type-1 (Router-LSA)
Link-State-ID: C-1
Link-State-ID: C-1
Link-ID: Net-1
Link-ID: Net-1
Area: 1
Area: 1
Adv. Router: C-1
Adv. Router: C-1 CE-1/CE-2 link
Area 1
Type-1 (Router-LSA) CE-1 CE-2

Link-State-ID: C-1 Type-1 (Router-LSA)
Net-1
Link-ID: Net-1 Area Link-State-ID:
1 C-1 Area 1
Area: 1 Link-ID: Net-1
C-1
Adv. Router: C-1 Area: 1
Site1 Adv. Router: C-1 Site2
BRKRST-2310

Presentation_ID.scr
Sites Belong to the Same Area—Backdoor with Sham Link
The sham link is treated as a virtual-link : unnumbered, ptp, DC link

The sham link is reported in the router LSA’s type 1 originated by the two routers connecting to
the sham link
The MPLS VPN backbone or the backdoor link can be made preferred path by tweaking
the metrics
Type-1 (Router-LSA)
Link-State-ID: C-1
Link-ID: Net-1
MPLS-VPN Backbone
Area: 1
Adv. Router: C-1
PE-1 PE-2 Type-1 (Router-LSA)

Type-1 (Router-LSA) Sham-Link
Link-State-ID: C-1 Link-State-ID: C-1
Link-ID: Net-1 Link-ID: Net-1
Area: 1 Area: 1
Adv. Router: C-1 Adv. Router: C-1
CE-1/CE-2 link
Area 1
Type-1 (Router-LSA)
Link-State-ID: C-1 CE-1 CE-2
Link-ID: Net-1 Net-1 Area 1 Type-1 (Router-LSA) Area 1 With Metric manipulation,
Area: 1 Link-State-ID: C-1 MPLS Backbone Can be
Adv. Router: C-1 Link-ID: Net-1 made preferable
C-1 Area: 1
Site1 Adv. Router: C-1 Site2
BRKRST-2310

Other Scenarios
Some OSPF sites entirely belong to area 0 and some other sites can belong to non area 0
Some sites may consist of hierarchical OSPF topology consisting of area 0 as well as
non-zero areas
Both scenarios are valid
MPLS VPN Super

Backbone
PE-1
PE-2
VPN red
VPN red
area 0
area 1
CE-1
area 2
Site1 Site2
BRKRST-2310

Presentation_ID.scr
Area 0 Placement
As before some sites may consist of hierarchical OSPF topology consisting of area 0 as well as non-zero areas.
If site contains area 0, it must touch provider PE router
OSPF RULE: Summary LSAs from non-zero area’s are not injected into backbone area 0
Inter-area routes will not show up unless a Virtual link is created
MPLS VPN Super

Backbone vpnv4 update
LSA Type 3
xPE-1
PE-2
LSA Type 1 or 2
VPN red
VPN red
virtual-link
area 0 LSA Type 3
area 1
CE-1
LSA Type 3
area 2 x LSA type 3
Summary routes is NOT advertised into area 0
BRKRST-2310
Database Overload Protection
Protects router from a large number of received LSAs

Possibly as a result of the misconfiguration on remote router
Router keeps the number of received

(non self-generated) LSAs
Maximum and threshold values are configured
When threshold value is reached, error message
is logged
When maximum value is exceeded, no more new
LSAs are accepted
If the counter does not decrease below the max value
within one minute we enter ‘ignore-state’
BRKRST-2310

Presentation_ID.scr
Database Overload Protection (Cont.)
In ‘ignore-state’ all adjacencies are taken down and

are not formed for ‘ignored-interval’
Once the ‘ignored-interval’ ends we return to normal
operations
We keep the count on how many times we entered
‘ignore-state’—‘ignore-count’
When ‘ignore-count’ exceeds its configured value,
OSPF process stays in the ‘ignore state’ permanently
Ignore-count is reset to 0, when we do not exceed maximum
number of received LSAs for a ‘reset-time’
The only way how to get from the permanent ignore-state is by
manually clearing the OSPF process
BRKRST-2310
Database Overload Protection

(Deployment Example)
RR
CE
MPLS PE
VPN CE
CE
CE
PE protected from being overloaded by CE

One misbehaving VRF affected, other works OK
BRKRST-2310

Presentation_ID.scr
Database Overload Protection (CLI)
Router mode
max-lsa <max> [<threshold> [warning-only]
[ignore-time <value>]
[ignore-count <value>
[reset-time <value>]]
Available in: 12.3(7)T 12.2(25)S 12.0(27)S

12.2(18)SXE 12.2(27)SBC
With CSCsd20451 deployable without flapping of all
neighbors. Available in 12.2(33)SXH,
12.2(33)SRC, 12.5
BRKRST-2310
OSPF Limit on Number of

Redistributed Routes
Maximum number of prefixes (routes) that are allowed

to be redistributed into OSPF from other protocols (or
other OSPF processes)
Self-originated LSAs are limited
Summarized prefixes counted
Type-7 to Type -5 translated prefixes not counted
CLI:
redistribute maximum-prefix maximum [threshold]
[warning-only]
Availability
12.0(25)S, 12.3(2)T, 12.2(18)S
BRKRST-2310

Presentation_ID.scr
OSPF Limit On Number Of Redistributed
Routes (Deployment Example)
RR
CE
iBGP OSPF
MPLS
VPN CE
PE CE
CE
PE protected from being overloaded from BGP
BRKRST-2310
Summary
What We Learned?
Deployment issues in Service Providers and
Enterprise Networks
Dialup deployments techniques
Understand OSPF fast convergence and
resiliency techniques
OSPF deployments techniques in MPLS environment
BRKRST-2310

Presentation_ID.scr
Q and A
BRKRST-2310
Recommended Reading
Continue your Cisco Live

learning experience with further
reading from Cisco Press
Check the Recommended
Reading flyer for suggested
books
Available Onsite at the Cisco Company Store

BRKRST-2310

Presentation_ID.scr
Complete Your Online
Session Evaluation
Give us your feedback and you could win Don’t forget to activate
fabulous prizes. Winners announced daily. your Cisco Live virtual
account for access to
Receive 20 Passport points for each session all session material
evaluation you complete. on-demand and return
for our live virtual event
Complete your session evaluation online now in October 2008.
(open a browser through our wireless network Go to the Collaboration
to access our portal) or visit one of the Internet Zone in World of
stations throughout the Convention Center. Solutions or visit
www.cisco-live.com.
BRKRST-2310
BRKRST-2310

Presentation_ID.scr

BRKRST 2310 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BRKRST 2310 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Deploying OSPF in a

Large Scale Network

© 2006, Cisco Systems, Inc. All rights reserved. 1

© 2006, Cisco Systems, Inc. All rights reserved. 2

© 2006, Cisco Systems, Inc. All rights reserved. 3

© 2006, Cisco Systems, Inc. All rights reserved. 4

 Largest known IGP routing Area 1 Area 2

© 2006, Cisco Systems, Inc. All rights reserved. 5

 This will bring really

© 2006, Cisco Systems, Inc. All rights reserved. 6

 When OSPF is enabled on the interface, it always

 WAN link routes can be suppressed to keep the routing

OSPF Prefix Suppression (CLI)

© 2006, Cisco Systems, Inc. All rights reserved. 7

 Hide the pop infrastructure

© 2006, Cisco Systems, Inc. All rights reserved. 8

Dealing with Redistribution

© 2006, Cisco Systems, Inc. All rights reserved. 9

© 2006, Cisco Systems, Inc. All rights reserved. 10

hub and spoke networks

OSPF Border Connections

© 2006, Cisco Systems, Inc. All rights reserved. 11

Trunk with One VLAN in Each Flooding Domain

© 2006, Cisco Systems, Inc. All rights reserved. 12

 Because of this, OSPF B D

OSPF Hub and Spoke

© 2006, Cisco Systems, Inc. All rights reserved. 13

router ospf 100

OSPF Hub and Spoke: Network Types

© 2006, Cisco Systems, Inc. All rights reserved. 14

OSPF Hub and Spoke: P2MP

 OSPF will advertise a host

© 2006, Cisco Systems, Inc. All rights reserved. 15

interface s0.1 point-to-point

OSPF Hub and Spoke

Network Type Advantages Disadvantages

Single Interface Single IP Subnet

© 2006, Cisco Systems, Inc. All rights reserved. 16

OSPF Hub and Spoke

© 2006, Cisco Systems, Inc. All rights reserved. 17

Dealing with Redistribution

 The number of redistribution boundaries should be kept

 When redistributing try to place the DR

© 2006, Cisco Systems, Inc. All rights reserved. 18

 Be aware of metric requirements going from one

 Include a redistribution default metric command as a

Dealing with Redistribution

 Redistribute only what is absolutely necessary

 Default route into BGP core; let the

© 2006, Cisco Systems, Inc. All rights reserved. 19

Dialup Design Practices

© 2006, Cisco Systems, Inc. All rights reserved. 20

 Static pool do not require …

Dialup Design with

© 2006, Cisco Systems, Inc. All rights reserved. 21

 Configure totally NSSA to filter

1000+ Routes Injected

Design Best Practices

© 2006, Cisco Systems, Inc. All rights reserved. 22

Area Size: How Many Router in an Area?

 Number of adjacent neighbors is more a factor

© 2006, Cisco Systems, Inc. All rights reserved. 23

OSPF Border Area Filtering: Ranges

Largest known IGP routing Area 1 Area 2

This will bring really

When OSPF is enabled on the interface, it always

WAN link routes can be suppressed to keep the routing

Hide the pop infrastructure

Because of this, OSPF B D

OSPF will advertise a host

The number of redistribution boundaries should be kept

When redistributing try to place the DR

Be aware of metric requirements going from one

Include a redistribution default metric command as a

Redistribute only what is absolutely necessary

Default route into BGP core; let the

Static pool do not require …

Configure totally NSSA to filter

Number of adjacent neighbors is more a factor

Type-3 LSA filtering on ABR

Link down is n2 and node down is

Network convergence is the time needed for traffic to

BGP takes longer to converge; C D

It will take some time for

Instead, the forwarding

A has to come back up and

Customer needs to send a summary route to site3–area3

Summary is originated in OSPF

OSPF sites have area 0

Area 0 is not mandatory when migrating to MPLS VPN service

The sham link is treated as a virtual-link : unnumbered, ptp, DC link

Protects router from a large number of received LSAs

Router keeps the number of received

In ‘ignore-state’ all adjacencies are taken down and