AJER-12.a C7 EnterpriseRoutingPolicies

Enterprise Routing Policies
© 2014 Juniper Networks, Inc. All rights reserved. | www.juniper.net | Worldwide Education
Services
Objectives
 After successfully completing this content,
you will be able to:
• Explain reasons to use BGP for internal
connectivity
• Explain ISP policies that affect external
connectivity
• Describe three common routing policies used in
external connectivity for the enterprise
environment
© 2014 Juniper Networks, Inc. All rights reserved. Worldwide Education Services www.juniper.net | 2
Agenda: Enterprise Routing Policies
Enterprise BGP Core Network Design

 Enterprise External Network Deployment
Enterprise BGP Core Network Design
 BGP strengths
• Routing policy control
• Diverse administrative control
• Can handle large prefix counts
 BGP weaknesses
• Increased convergence time
• Increased complexity
 Simple enterprise topology
OSPF AREA
0 INTERNET
 Complex enterprise topology
Data DMZ
OSPF Area
Center
0
IBGP IBGP IBGP

EBGP
EBGP
Internet Internet
EB
AS 5700
GP
P
B G
E
VP
N MPLS WAN
AS 65000
Inter
EB
AS 65001
net
GP
VPN
Branch Offices AS 65002
HQ
BGP in the Enterprise Case Study
Overview
 The engineers at Enterprise, Inc. are
implementing BGP in an enterprise network
 By using BGP, the following goals are met:
• Better handling of large prefix counts
• Easier summarization of prefixes
• A scalable design allowing a seamless introduction
of complex routing scenarios (e.g., MPLS WAN)
• Flexible routing policy for optimal routing of
latency- and jitter-sensitive traffic
• Diverse administrative control by adding ASs to
scope administrative boundaries
BGP Case Study Topology
 Enterprise, Inc. initial topology
Remote Sites
Remote Sites B
A
R1 R2
10.0.0.0/9
10.128.0.0/ 20
9 Mbps
GRE
20
Internet R3 R4
Mbps
GRE
MPLS R6
WAN R5
Site
B
Site
A
BGP Case Study Goals
 Based on the topology on the previous slide,
our design goals are the following:
• Advertise the minimum amount of prefixes from
the remote sites to Site A and Site B
• Keep traffic off the 20 Mbps links between R1 and
R2 and between R3 and R4, but still use these in
case of outage
• Only use the GRE tunnel between Site A and R1
for backup in case there are problems with the
MPLS provider at Site A
• Scope Site A and Site B to their own AS for ease of
administration
BGP Case Study Topology
 Topology after proposed solutions
Remote Sites
Remote Sites
B
A
R1 R2
EBG GP
P
IBGP EB 10.0.0.0/9
10.128.0.0/
9
IBG
GP
EBGP AS 65000
IB
P
IBGP R4
Internet R3
GP
OSPF Area 0
EB
EBG
EBGP EBGP
P
MPLS R6
AS 3356 EB
WAN GP R5
AS 65002
AS 65001 Site
B
Site
A
BGP Case Study: Prefix Count (1 of 4)
 Reduce number of prefixes to Site A and Site
Buser@R5>
...
show bgp summary
172.16.1.33 3356 451 1279 0 0

2:57:13 11047/11047/11047/0 0/0/0/0
Site A is currently receiving

11407 routes from the MPLS
WAN provider.
user@R6> show bgp summary
...
172.16.1.29 65000 771 955 0 0 4:24:38
9843/11046/11046/0 0/0/0/0
172.16.1.41 65000 745 932 0 1 4:10:15
1203/11046/11046/0 0/0/0/0
Site B is currently receiving

11406 routes from both
peering routers in the
Enterprise core.
[edit] [edit]
user@R4# show routing-options user@R4# show policy-options
policy-statement EXPORT-EBGP {
... term 1 {
aggregate { from {
route 10.0.0.0/8; protocol aggregate;
} route-filter 10.0.0.0/8 exact;
}
then accept;
1. An aggregate route is }
term 2 {
created representing routes
then reject;
from remote Sites A and B. }
}
[edit]
2. A policy matching the aggregate user@R4# show protocols bgp
with an accept action and rejecting ...
everything else is created. group EBGP {
3. The policy is then applied to the type external;
EBGP neighbors. export EXPORT-EBGP;
4. The same policy is created and peer-as 65002;
applied on R3. ...
...
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
172.16.1.33 3356 3151 3757 0 0 22:24:01
2/2/2/0 0/0/0/0
user@R5> show route protocol bgp 10/8
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
10.0.0.0/8 *[BGP/170] 00:26:45, localpref 100

AS path: 3356 65000 {65003 65004} I
> to 172.16.1.33 via ge-0/0/1.0
 After the policy is applied, Site A receives

two prefixes, including the 10/8 aggregate
...
172.16.1.29 65000 4490 3373 0 0 23:27:10
1/1/1/0 0/0/0/0
172.16.1.41 65000 3592 3351 0 1 23:12:47
0/1/1/0 0/0/0/0
user@R6> show route protocol bgp 10/8
inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
10.0.0.0/8 *[BGP/170] 01:06:26, localpref 100

AS path: 65000 {65003 65004} I
> to 172.16.1.29 via ge-0/0/1.0
[BGP/170] 00:27:12, localpref 100
AS path: 65000 {65003 65004} I
> to 172.16.1.41 via ge-0/0/2.0
 After the policy is applied, Site B receives

one prefix (the 10/8 aggregate) from both
peers
BGP Case Study: Traffic Engineering (1
of 6)
 Keep traffic off the 20 Mbps links between
R1/R2 and between R3/R4
Remote Sites
EBG R1 B
Remote Sites P R2
A 20 Mbps 10.0.0.0/9
GP
EBGP EB
10.128.0.0/
9 AS 65000
R3
20 Mbps
R4
EB
GP BGP
E
AS 65002
R6
Based on the route selection Site
process and without any other B
manipulation, Site B will choose the
10.0.0.0/8 aggregate route on
whichever path became active
first.
of 6)
user@R6> show route 10.128.100.1
...
10.0.0.0/8 *[BGP/170] 03:53:31, localpref 100 Site B chooses the
AS path: 65000 {65003 65004} I path to R4 for
> to 172.16.1.29 via ge-0/0/1.0 destinations to
[BGP/170] 03:14:17, localpref 100
AS path: 65000 {65003 65004} I 10.0.0.0/8.
> to 172.16.1.41 via ge-0/0/2.0
user@R6> traceroute 10.128.100.1 source 192.168.10.7

...
1 R4 (172.16.1.29) 0.438 ms 0.363 ms 0.326 ms
2 R3 (172.16.1.18) 0.584 ms 0.543 ms 0.545 ms
3 R1 (172.16.1.22) 0.995 ms 0.992 ms 0.933 ms
4 RemoteA (10.128.100.1) 1.371 ms 1.275 ms 1.254 ms
Site B sends traffic destined to 10.128.0.0/9

through R4, which causes it to use the 20 Mbps link
between R3 and R4.
of 6)
[edit routing-options]
user@R3# set aggregate route 10.128.0.0/9
[edit] 1. R3 creates a more

user@R3# show policy-options policy-statement EXPORT-EBGP specific aggregate route
term 1 {
from {
toward the remote Sites A.
protocol aggregate; 2. R3 adds the newly
route-filter 10.0.0.0/8 exact; created aggregate to the
route-filter 10.128.0.0/9 exact; existing EBGP policy.
}
then accept;
...
[edit routing-options]
user@R4# set aggregate route 10.0.0.0/9
[edit]
user@R4# show policy-options policy-statement EXPORT-EBGP
term 1 { The same thing is done on
from { R4, only toward the
protocol aggregate; remote Sites B.
route-filter 10.0.0.0/8 exact;
}
then accept;
...
of 6)
user@R6> show route 10.128.100.1

Now Site B has a more
...
10.128.0.0/9 *[BGP/170] 00:25:35, localpref 100 specific destination
AS path: 65000 65003 I toward the remote
> to 172.16.1.41 via ge-0/0/2.0 Sites A.
...
1 R3 (172.16.1.41) 0.576 ms 0.395 ms 0.367 ms
2 R1 (172.16.1.22) 0.770 ms 0.773 ms 0.887 ms
3 RemoteA (10.128.100.1) 1.133 ms 1.045 ms 1.048 ms
After R3 advertises the more specific

aggregate, traffic destined toward
remote Sites A takes a more optimal
path avoiding the 20 Mbps link.
of 6)
user@RemoteA> traceroute 192.168.10.7 source 10.128.100.1

...
1 R1 (172.16.1.2) 0.409 ms 0.324 ms 0.321 ms
2 R3 (172.16.1.21) 0.728 ms 0.667 ms 0.688 ms
3 SiteB (192.168.10.7) 1.365 ms 1.073 ms 1.135 ms
Traffic from the remote sites toward

Site B is already taking the more
optimal path.
user@R1> show route 192.168.10.7 extensive | match "^192|Source:|Inactive reason"
192.168.10.7/32 (2 entries, 1 announced)
Source: 192.168.10.5
Source: 192.168.10.6
Inactive reason: Not Best in its group - IGP metric
R1 is choosing the IGP metric as the

determining factor in picking the path
toward Site B.
of 6)
[edit]
user@R3# deactivate protocols bgp group EBGP
[edit]
user@R3# commit
commit complete

...
1 R4 (172.16.1.29) 0.441 ms 0.401 ms 0.373 ms
2 R3 (172.16.1.18) 0.778 ms 0.909 ms 0.951 ms
3 R1 (172.16.1.22) 1.194 ms 2.258 ms 1.254 ms
4 RemoteA (10.128.100.1) 1.567 ms 1.571 ms 1.485 ms
Because R3 and R4 are still sending the less-specific

10/8 prefix, Site B still has connectivity if one of the
neighbors fails.
BGP Case Study: Backup Link (1 of 4)
 Use of backup link between Site A and R1 in
case of failure in the MPLS WAN network
Remote Sites
B
EBG
Remote Sites P EBG R1 R2 GP
P EB 10.0.0.0/9
A IBGP
10.128.0.0/
9
IBG
EBGP
GP
AS 65000
IB
P
R3 IBGP
GRE Internet R4
tunnel
EB
GP
EBGP MPLS WAN • Site A has a GRE tunnel to

AS 3356
R1
GP
R5 EB • EBGP is chosen as the
protocol to run within the
Site
A AS 65001 tunnel
172.20.128.0/1
7
[edit routing-options] 1. An aggregate route matching the
user@R1# show aggregate remote sites is created in R1.
route 10.0.0.0/8 {
as-path { 2. A policy is then created that
path 65000; matches the aggregate route and
} prepends the local AS number 5
} times.
[edit policy-options]
user@R1# show policy-statement GRE-EBGP
term 1 { 3. The policy is then applied to the
from { Site A BGP neighbor.
protocol aggregate;
}
then { [edit protocols bgp group EBGP]
as-path-expand last-as count 5; user@R1# show
accept; ...
} /* Connection to Site A */
} neighbor 172.16.1.37 {
term 2 { export GRE-EBGP;
then reject; peer-as 65001;
} }
user@R5> show route 10/8 exact
...
10.0.0.0/8 *[BGP/170] 00:58:24, localpref 100
AS path: 3356 65000 {65003 65004} I
> to 172.16.1.33 via ge-0/0/1
[BGP/170] 00:01:11, localpref 100
AS path: 65000 65000 65000 65000 65000 65000 65000 I
> to 172.16.1.38 via gre.0
The path toward R1 from Site A using the GRE tunnel is

installed but it is not preferred, as designed by the
policy on R1.

...
1 MPLSWAN (172.16.1.33) 0.385 ms 0.323 ms 0.329 ms
2 R3 (172.16.1.25) 1.086 ms 1.034 ms 1.000 ms
3 R1 (172.16.1.22) 0.868 ms 0.807 ms 0.789 ms
4 RemoteA (10.128.100.1) 1.189 ms 1.467 ms 1.388 ms
The current path uses the MPLS WAN

path.
[edit]
user@R5# deactivate interfaces ge-0/0/1.0
[edit]
user@R5# commit
commit complete
[edit]
user@R5# run traceroute 10.128.100.1 source 192.168.10.8
traceroute to 10.128.100.1 (10.128.100.1) from 192.168.10.8, 30 hops max, 40
byte packets
1 R1 (172.16.1.38) 0.480 ms 0.333 ms 0.347 ms
2 RemoteA (10.128.100.1) 0.864 ms 0.671 ms 0.678 ms
By forcing a failure on the interface

toward the MPLS WAN, you can see
the policy take effect and direct traffic
toward the GRE path.
BGP Case Study: Administration Scope
 Scope Site A and Site B to their own AS for ease of administration
R1 R2
IBGP
Created separate ASs for

GP
EBGP AS 65000 Site A and Site B,

IB
R4 allowing for easier

IBGP
Internet R3 delegation of
administration duties
GP
EB
EBG
EBGP EBGP
P
MPLS WAN R6
AS 3356 EB R5
GP
AS 65002
AS 65001
Site Site
A B
BGP Case Study Summary
 The Enterprise, Inc. goals were accomplished
with the following steps:
• Created an aggregate route to reduce the number
of routes from ~11000 to two
• Used strategic advertising to keep traffic off the
20 Mbps links
• Used routing policy to only activate traffic on the
tunnel in case of outage
• Set up ASs for delegation of administration duties
to personnel
Agenda: Enterprise Routing Policies
 Enterprise BGP Core Network Design

Enterprise External Network Deployment
External Traffic Enterprise Routing
Policies
 Common routing policies
• Inbound:
• Topology driven
• Primary/secondary
• Load-shared per prefix
• Outbound:
• Topology driven
• Primary/secondary
• Load-shared per prefix
Enterprise Topologies for External Traffic
 Common topologies:
• Multiple providers, one router:
• One or more providers, multiple routers:
EBG R1 P
ISP B
P EB G
ISP C
(AS 65002) (AS
65003)
Enterprise
Network
EBG R1 R2
P GP
ISP B IBGP EB ISP C
(AS 65002) (AS
65003)
Enterprise
Network
Common ISP Routing Policies
 Use local preference to prefer certain routes
• Usually prefers customer routes over peer routes by
default
• Usually can be modified by use of communities
 Filter all routes by length
• Usually do not accept routes > /24
• Can accept long routes from customers but cannot
announce them
 Filter customer routes by prefix, AS path, or
both
• Sometimes automatic (routing registry), sometimes
manual
Topology-Driven Routing Policies
 Accept all routes without attribute
modification
 Choose an active route based
Hammer on:
Saws
s, Inc.
Corp.
• AS path
(AS
• Origin ISP A 65502)
• MED (next AS only) (AS
65001)
• Closest exit ISP B ISP C
(AS (AS
65002)EBG GP 65003)
P R1 R2 EB
IBGP
Nails, Inc. (AS

65501)
Topology-Driven Outbound Routing
Policy
Hammer
Saws
s, Inc.
Corp.
Hammer (AS
s
ISP A 65502)
(AS
65001)
Hammer Saw
s s
ISP B ISP C
(AS (AS
65002) 65003)
R1 R2
Hammer Saw Saw
s s s
Hammer
s
Nails, Inc. (AS
65501)
Topology-Driven Inbound Routing Policy
Hammer Saws Corp.

s, Inc.
(AS 65502)
Nail
s
ISP A
(AS 65001)
Nail
s
ISP B ISP C
(AS 65002) (AS
Nail
65003)
Nail
s R1 R2 s
Nails, Inc. (AS

65501)
Multiple Versus Single Routers
 When all else is equal, routers choose the
closest exit
Drills, Inc. Drills, Inc.
(AS 65503) (AS
65503)
ISP B ISP C ISP B ISP C

(AS (AS (AS (AS 65003)
65002) 65003) 65002)
R1
Drills, R1 R2 Drills, Drills, Drills,
Inc. Inc. Inc. Inc.
?? ??
Nails, Inc. (AS

65501)
Primary/Secondary Routing Policies
 Multiple variations:
• Strict primary/secondary: always prefer the
primary connection unless it is down, no traffic
over secondary connection
• Loose primary/secondary: prefer the primary
connection unless it is down, except allow certain
traffic over the secondary connection
 Equal-bandwidth links and strict
primary/secondary provide assured
redundancy
Primary/Secondary Outbound Routing
Policy
 Enforce correct exit through local preference
 Use for single and multiple border routers
Hammer
Saws
s, Inc.
Corp.
Hammer (AS
s 65502)
ISP A
(AS
Hamme 65001) Saw
rs s
ISP B Hammer ISP C
s
(AS (AS
65002) 65003)
R1 R2
Saw Saw
s s
Hamme Hamme
rs rs
Nails, Inc. (AS
65501)
Strict Primary/Secondary Outbound
Routing Policy
 To enforce strict primary/secondary, receive
only a default
I can reach
192.168.16.0/2
3 through AS
ISP B 65002 ISP C
(AS (AS
65002)
I can reach 65003) I can reach
192.168.16.0/23, 192.168.16.0/23
192.168.16.0/24, through AS 65003
and and AS 65002
192.168.17.0/24
through AS 65002
R1 R2 192.168.16.0/2
3
192.168.16.0/2
4
192.168.17.0/2
4 Nails, Inc. (AS
65501)
Loose Primary/Secondary Outbound
Policy
 To allow loose primary/secondary, receive a
default from both the primary and secondary
provider, but also allow specific routes from
the secondary that you want to prefer (such
as customersISPofB that ISP) ISP C
(AS 65002) (AS 65003)
I can reach I can reach
0.0.0.0/0, 0.0.0.0/0
172.30.12.0/24, through AS
and 172.30.15.0/24 65003
through AS 65002
R1 R2 0.0.0.0/
0
172.30.12.0/2
4
172.30.15.0/2 Nails, Inc. (AS
4
65501)
Primary/Secondary Outbound:
Configuration Example—Strict
 Strict sample configuration excerpts:
protocols { policy-options {
bgp { policy-statement localpref-80 {
group primary-isp { then {
[...] local-preference 80;
import [ localpref-80 default-only ]; }
} }
[...] policy-statement localpref-70 {
group secondary-isp { then {
} }
[...] policy-statement default-only {
} term match-default {
} from {
}
then accept;
}
then reject;
}
}
Primary/Secondary Outbound:
Configuration Example—Loose
 Loose sample configuration excerpts:
bgp { policy-statement localpref-80 {
group primary-isp { then {
} }
[...] policy-statement localpref-70 {
group secondary-isp { then {
import [ localpref-70 isp-b-customers default- }
only ]; }
} policy-statement isp-b-customers {
[...] from community isp-b-customer-routes;
} then accept;
} }
policy-statement default-only {
term match-default {
from {
This policy accepts the }
routes for ISP B’s }

then accept;
customers. Because they }

then reject;
are accepted from ISP B, }

community isp-b-customer-routes members 65002:8000;
but not the primary ISP,

the secondary ISP will be
used for these routes.
Primary/Secondary Inbound Policy
 Enforce correct entrance through both
communities to set local preference and AS
path prepending
Hammer Saws
 Use for single and s, Inc. Corp.
multiple border routers (AS
65502)
Nail
s
ISP A
(AS
65001)
Nail
s
ISP B ISP C
(AS 65002) Nail (AS 65003)
s Nail
R1 R2 s
Nails, Inc. (AS

65501)
Primary/Secondary Inbound:
Configuration Example
 Sample configuration excerpts:
protocols {
bgp {
group primary-isp {
[...]
export routes-to-ISP;
}
[...]
group secondary-isp {
[...]
export [ set-backup routes-to-ISP ];
}
[...]
}
}
policy-options {
prefix-list announce-to-ISP {
172.31.128.0/20;
}
policy-statement routes-to-ISP {
from {
prefix-list announce-to-ISP;
}
then accept;
}
policy-statement set-backup {
then {
community set ISP-B-localpref-70;
as-path-prepend "65501 65501 65501";
}
}
community ISP-B-localpref-70 members 65002:70;
}
Load-Shared Per-Prefix Routing Policies
 Direct traffic to certain prefixes over certain
links
• Leads to load sharing over multiple providers
• Is a variation on primary/secondary routing policy,
but on a per-prefix basis
• Requires monitoring and adjustment to ensure
that desired load sharing is achieved
 Use same configuration for single or multiple
border routers
• On multiple routers, keep configurations
synchronized
Load-Shared Per-Prefix Outbound Policy
 Set a higher local preference for the specific
routes within a large range for each provider
Hammer Saws Corp.
s, Inc. (AS 65502)
ISP A
(AS
65001)
ISP B ISP C
(AS (AS
65002) 65003)
R1 R2
0.0.0.0/1 128.0.0.0/
1
Nails, Inc. (AS
65501)
Load-Shared Per-Prefix Outbound:
 Sample configuration excerpts:
bgp { policy-statement isp-b-import {
group isp-b { term primary {
[...] from {
import isp-b-import; route-filter 0.0.0.0/1 orlonger;
} }
[...] then {
group isp-c { local-preference 80;
[...] accept;
import isp-c-import; }
} }
[...] then {
} local-preference 70;
} accept;
}
}
policy-statement isp-c-import {
term primary {
from {
route-filter 128.0.0.0/1 orlonger;
}
then {
local-preference 80;
accept;
}
}
then {
local-preference 70;
accept;
}
}
}
Load-Shared Per-Prefix Inbound Policy
 Announce entire aggregate to all providers, but also
announce more specific prefixes to each provider
Hammer
Saws
s, Inc.
Corp.
(AS
ISP A 65502)
(AS
65001)
ISP B ISP C
(AS (AS
65002) 65003)
R1 R2
I can reach
172.31.128.0/20 I can reach
and 172.31.128.0/20
172.31.128.0/21
Nails, Inc. (AS and
through AS 65501 65501) 172.31.136.0/21
through AS 65501
Load-Shared Per-Prefix Inbound:

S amp le confi g urat ion excerp ts:
bgp { prefix-list aggregates {
group isp-b { 172.31.128.0/20;
[...] }
export [ isp-b-export accept-aggregates reject-all ]; prefix-list isp-b-specifics {
} 172.31.128.0/21;
[...] }
group isp-c { prefix-list isp-c-specifics {
[...] 172.31.136.0/21;
export [ isp-c-export accept-aggregates reject-all ]; }
} policy-statement accept-aggregates {
[...] from {
} prefix-list aggregates;
} }
then accept;
}
policy-statement isp-b-export {
from {
prefix-list isp-b-specifics;
}
then accept;
}
policy-statement isp-c-export {
from {
prefix-list isp-c-specifics;
}
then accept;
}
policy-statement reject-all {
then reject;
}
}
Summary
 In this content, we:
• Explained reasons to use BGP for internal
connectivity
• Explained ISP policies that affect external
connectivity
• Described three common routing policies for
external connectivity in the enterprise
Review Questions
1. What are three BGP strengths over an IGP?

2. What is the longest subnet mask that ISPs
usually accept from their customers?
3. Name three routing policy strategies for
external connectivity. What are the
advantages and disadvantages of each
policy strategy?
Implementing Enterprise Routing
Policies Lab
 Implement enterprise routing policies for
internal and external connectivity.
Worldwide Education
Services

AJER-12.a C7 EnterpriseRoutingPolicies

Uploaded by

Copyright:

Available Formats

AJER-12.a C7 EnterpriseRoutingPolicies

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AJER-12.a C7 EnterpriseRoutingPolicies

Uploaded by

Copyright:

Available Formats

Enterprise Routing Policies

Enterprise BGP Core Network Design

IBGP IBGP IBGP

172.16.1.33 3356 451 1279 0 0

Site A is currently receiving

Site B is currently receiving

user@R5> show route protocol bgp 10/8

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

10.0.0.0/8 *[BGP/170] 00:26:45, localpref 100

 After the policy is applied, Site A receives

user@R6> show route protocol bgp 10/8

inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)

10.0.0.0/8 *[BGP/170] 01:06:26, localpref 100

 After the policy is applied, Site B receives

user@R6> traceroute 10.128.100.1 source 192.168.10.7

Site B sends traffic destined to 10.128.0.0/9

[edit] 1. R3 creates a more

user@R6> show route 10.128.100.1

After R3 advertises the more specific

user@RemoteA> traceroute 192.168.10.7 source 10.128.100.1

Traffic from the remote sites toward

R1 is choosing the IGP metric as the

user@R6> traceroute 10.128.100.1 source 192.168.10.7

Because R3 and R4 are still sending the less-specific

EBGP MPLS WAN • Site A has a GRE tunnel to

The path toward R1 from Site A using the GRE tunnel is

user@R5> traceroute 10.128.100.1 source 192.168.10.8

The current path uses the MPLS WAN

By forcing a failure on the interface

Created separate ASs for

EBGP AS 65000 Site A and Site B,

R4 allowing for easier

 Enterprise BGP Core Network Design

• One or more providers, multiple routers:

Nails, Inc. (AS

Hammer Saws Corp.

Nails, Inc. (AS

ISP B ISP C ISP B ISP C

Nails, Inc. (AS

routes for ISP B’s }

customers. Because they }

are accepted from ISP B, }

but not the primary ISP,

Nails, Inc. (AS

1. What are three BGP strengths over an IGP?

You might also like