Odd010004 BGP Protocol Design Issue 1 - 0

Internal
ODD010004 BGP Protocol Design

ISSUE 1.0
www.huawei.com
HUAWEI TECHNOLOGIES CO., LTD.
All rights reserved
PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com
The border gateway protocol (BGP) has been developed from BGP1 (initial version in 1989) to BGP4. As the Internet expands, BGP functions are increased and strengthened from the basic routing among autonomous systems to community, reflection, confederation, and multi-protocol extension. The current number of BGP routes on the Internet has exceeded 100,000 entries. Such a wide deployment proves that BGP has a powerful support for large and complicated networks.
All rights reserved
Page 1
Upon completion this course, you will be able to: [ Understand the advanced applications of BGP [ Optimize the path selection and convergence time of BGP [ Understand the network planning of BGP
All rights reserved
Page 2
Chapter 1 BGP Theories Chapter 2 BGP Network Planning Chapter 3 BGP Performance Optimization
All rights reserved
Page 3
Chapter 1 BGP Theories

Section 1 BGP Principles Section 2 BGP Path Attribute Section 3 Path Selection Procedure
All rights reserved
Page 4
BGP Principle
BGP Overview
l BGP is an external routing protocol for transmission of routing
information among ASs.

l BGP is a path vector protocol, which is a kind of distance vector
protocols. [ Reliable route update mechanism [ Rich metric measurement methods [ Free from loops by protocol design
l Carrying attributes for routes l Supporting classless inter-domain routing (CIDR) l Rich route filter and routing policies
HUAWEI TECHNOLOGIES CO., LTD. All rights reserved Page 5
BGP Principle
BGP Neighbor Relation
AS 100
RTA EBGP
AS 300
RTE
AS 200
IBGP RTB RTC RTD
EBGP
All rights reserved
Page 6
BGP Principle
BGP Route Notification Principles
l When there are several paths, BGP Speaker selects only the optimal one. l BGP Speaker notifies only the routes used by itself to neighbor entities. l Once the connection is established, BGP Speaker notifies its all BGP routes
to new neighbor entities.

l BGP Speaker notifies routes obtained from EBGP to all its neighbor entities
(including EBGP and IBGP).

l BGP Speaker does not notify the routes obtained from IBGP to its IBGP
neighbor entities.
l Whether BGP Speaker notifies the routes obtained from IBGP to its EBGP
neighbor entities depends on the IGP and BGP synchronization.


All rights reserved
Page 8
BGP
!"#
Common BGP Attribute

l Origin l AS-Path l Next Hop l MED (Multi Exit Discriminator) l Local-Preference l Atomic-Aggregate l Aggregator l Community l Originator-ID l Cluster-List l Destination Pref (MCI) l Advertiser (Baynet) l Rcid-Path (Baynet) l MP_Reach_NLRI l MP_Unreach_NLRI l Extended_Communities
All rights reserved
Page 9

All rights reserved
Page 10
BGP Path Selection Procedure

l l l l l
BGP skips a route if its next hop is unreachable. BGP firstly selects the route of highest Local-Preference. BGP selects routes originated by local routers (which have a same priority). BGP evaluates the AS path length and selects firstly the shortest path. BGP compares the attributes of Origin and selects the path of the lowest attribute of Origin. The Origin attribute of IGP is lower than that of EGP, and that of EGP lower than Incomplete. BGP selects the route of smaller MED. BGP selects EBGP prior to than IBGP routes. BGP firstly selects the path with shortest IGP metric to the next BGP hop. BGP compares the Originator_ID (Router ID if Originator_ID is unavailable) and selects the path of smaller Originator_ID. BGP compares the peer IP address and selects the path with smallest value of IP address.
l l l l
All rights reserved
Page 11
All rights reserved
Page 12
Chapter 2 BGP Network Planning

Section 1 IBGP/EBGP Core Design Section 2 Multi-homing Load Balance Section 3 BGP Route Reflector Section 4 BGP Confederation Section 5 BGP Community Attribute
All rights reserved
Page 13
Questions
l When is BGP needed? l Is BGP suitable for the current network? l What are BGP's advantages and disadvantages?
All rights reserved
Page 14
BGP Network Planning

IBGP/EBGP Core Design
IBGP Core Design EBGP Core Design (I/E)BGP Core Design
All rights reserved
Page 15
IBGP Core Design

Path Selection
l BGP selects the path by comparing the IGP metric to the
destination router.
l If the core IGP has several paths to the destination router, BGP
selects the one with the smallest IGP metric and keeps others in BGP route table in form of copies.
l If the core IGP has several equivalent paths to a destination
router, these paths are used as entries and added to the routing table for load sharing.
All rights reserved
Page 16
IBGP Core Design

Fault and Recovery
RT3 RT1 RT2
RT4 RT5 RT7 RT6 RT8
l IBGP path selection depends on the IGP metric. l IBGP path convergence time depends on the IGP working mechanism.
EBGP Core Design

Path Selection
l If there are no policies, EBGP path selection depends on the
two parameters: [ AS-PATH length [ Neighbor router ID
All rights reserved
Page 18
EBGP Core Design

Route Import 192.168.1.0/24 AS65102
AS65101 RT2 10.1.2.1
RT3 10.1.3.1
RT5 10.1.5.1
AS65104
RT6 10.1.0.1 RT4 10.1.4.1 AS65103
All rights reserved
Page 19
EBGP Core Design

Path Selection
Router R2 R4 R5 R6 Destination Address/Mask 192.168.1.0/24 192.168.1.0/24 192.168.1.0/24 192.168.1.0/24 RT3 RT3 Next Hop RT3 RT6
l Because physical topology and link bandwidth are invisible to BGP path
selection, a suboptimum route may be selected.

l The path selection can be changed by such policies as MED, Local_Pref,
and AS-PATH list. (Before changing default BGP attributes, you must completely understand their meanings to avoid side effects.)
All rights reserved
Page 20
EBGP Core Design

Fault and Recovery
l After disconnection of a BGP session, the update procedure
takes place one hop after another, till all BGPs in all affected BGP autonomous systems announce that the all routers are updated.
l The IGP that is unable to respond quickly to network changes
is a little slower in re-convergence. The re-convergence time is accumulative.
All rights reserved
Page 21
(I/E)BGP Core Design

Path Selection
RT3
192.168.2.0/24
AS65102 RT6
RT1 RT4 AS65101 RT3 RT2

192.168.1.0/24
192.168.4.0/24
RT5 RT7 RT9 AS65103
AS65100 RT10 RT8
RT11 AS65104
192.168.4.0/24
All rights reserved
Page 22

Path Selection
RT3 AS65102 RT6
RT1 RT4 AS65101 RT3 RT2 AS65100 RT10 RT8 RT5 RT7 RT9 AS65103
RT11 AS65104

Fault and Recovery
RT3 AS65102 RT6
RT1 RT4 AS65101 RT3 RT2 AS65100 RT10 RT8 RT5 RT7 RT9 AS65103
RT11 AS65104

All rights reserved
Page 25

Multi-Homing
Single Homing End Network
Multi-Homing End Network
Standard Multi-Homing Network
All rights reserved
Page 26
Single Homing End Network

Advantages
Cost-effective BGP replaced by static routing or default routing
Disadvantages
Several connections are terminated on a same device. Several static routes are needed. Only link failure can be avoided. Device failure cannot be avoided.
AS65101
AS65102
All rights reserved
Page 27
Multi-Homing End Network ! Single Border Router

Advantages
Private AS can be used. Outgoing traffic can be better controlled for load balance by link capacity.
AS65101
Disadvantages
Several connections are terminated on a same device. Only link failure can be avoided. Device failure cannot be avoided.
AS65102
All rights reserved
Page 28
Multi-Homing End Network ! Several Border Routers
Advantages
Private AS can be used. Outgoing traffic can be better controlled for load balance by link capacity.
AS65101
Disadvantages
Core router must run IBGP session and core IGP session.
AS65102
All rights reserved
Page 29
Standard Multi-Homing Main Network ! Single Border Router

Single Border Router
AS65101
AS65103
AS65102
All rights reserved
Page 30
Standard Multi-Homing Main Network ! Several Border Routers

Several Border Routers
AS65101
AS65103
AS65102
All rights reserved
Page 31

Load Balance
Incoming Load Balance
Outgoing Load Balance
Multiple Sessions of A Peer
All rights reserved
Page 32

l Multi-homing to a same upstream autonomous system
[ When the upstream system provides two link, the address space can be reasonably designed.
l Multi-homing to two different upstream autonomous system
[ Monitor link and occupancy [ Achieve load balance by adding AS-PATH attribute length (an AS number added in one time)
All rights reserved
Page 33

l Multi-homing to a same upstream autonomous system
[ Achieve load balance by default routing

l Multi-homing to two different upstream autonomous systems
[ Achieve load balance by requesting some available routes that are completely reachable
l If load balance still cannot be achieved, complete Internet
routes are requested and incoming filtering policies are implemented to generate the partial routing table of the router itself.
All rights reserved
Page 34

EBGP Multi-Path Solution
AS65101
AS65102
Loopback
Loopback
l Loopback addresses are used to set up EBGP sessions. The
equivalent routes to the peer loopback addresses are iterated for load balance.
l Because the default TTL of EBGP is 1, both sides need change
the TTL value by the command ebgp-max-hop.


EBGP Multi-Path Solution
AS65101
AS65102
l Every link in the autonomous system sets up the EBGP session. l Because BGP supports only one equivalent path by default, both
sides need set the number of maximum equivalent paths by the command maximum load-balancing .

All rights reserved
Page 37

Router Reflection Reflector Notification Principle Reflector Cluster
Loop Prevention Mechanism
Reflector Design Principle
All rights reserved
Page 38
Reflector Notification Principle

l Only the known optimal path is notified or reflected. l Notification is always made to EBGP peer. l Clients observe the conventional IBGP loop prevention rules when
notifying the routes.

l Other rules are observed if the notifications are made to IBGP peer, client,
or non-clients. When the notification is made to IBGP peer, these rules depend on where these routes are learned from.
l If the reflector learns the routes from EBGP peer, it notifies to all its clients
and non-clients.
l If a route reaches the reflector through a non-client IBGP peer, the
reflector reflects this route to all its clients.

l If a route reaches the reflector through a client, the reflector reflects this
route to all other clients and non-clients.

Reflector Cluster
l Several reflectors serve one or several clients to provide redundancy. l A 4-byte CLUSTER_ID identifies a cluster. l The reflector receiving the information will ignore the route notification
that carries the same CLUSTER_ID.

l A cluster may include one or several reflectors. l A client may belong to several clusters.
Reflector RT3 Client RT1 Cluster 10.1.1.1 Client RT2 Reflector RT4
Reflector RT5
Cluster 10.1.1.2 Client RT7 Cluster 10.1.1.3
Reflector RT6
Page 40
All rights reserved
Loop Prevention Mechanism

l To prevent loop caused by reflector during route update, two BGP path attributes are
introduced: [ Originator_ID " Originator_ID is created by the first reflector and will not be changed by subsequent reflectors. " It is a 32-bit value, and should be received from only IBGP. " It is the Router ID of: # The BGP announcer of local AS originated routes. # The border router of a same AS if the route is learned from EBGP. [ Cluster_List " Cluster_List records all Cluster_ID passed by and puts the latest Cluster_ID on the top of the Cluster_List. " The reflector identifies loops by Cluster_List.

Layered Router Reflection
Layer 2 Reflector
Layer 1 Reflector/Client
Client
All rights reserved
Page 42

l Keep logical and physical topologies match to ensure redundancy,
optimize path, and prevent loops of route selection.

l Use comparable metric for route selection to avoid route oscillation
during convergence.
l Set proper intra- and inter-cluster IGP metrics to prevent route
oscillation during convergence.

l Apply cluster division techniques correctly to enforce the reflector
redundancy.
l Modify the path carefully if putting the reflector to the forwarding path. l Use peer group to reduce convergence time if there are reflectors.
All rights reserved
Page 43

All rights reserved
Page 44

Confederation Confederation Principle
AS-PATH Special Treatment Confederation Design Principles Comparison Between Confederation and Reflector
All rights reserved
Page 45
Confederation Principles
l Confederation Concepts
[ A large AS is divided into several small ASs for the IBGP full mesh.
AS 65100
AS 65200 AS 200
RT1
RT2
AS 65300 RT3 AS 100 RT5

RT4
AS-PATH Special Treatment

l Two new AS-PATH subtypes are introduced in confederation:
[ AS-CONFED-SEQUENCE [ AS-CONFED-SET AS 65100 AS 65200 AS 200 RT1 RT2
AS 65300 RT3 AS 100 RT5

RT4
Confederation Design Principles

l Hub-and-Spoke Architecture
AS 65200 AS 65100 RT5 RT4
AS 100
RT2 RT1 AS 65000
AS 65300
RT6 RT3
All rights reserved
Page 48

l Improper setting of IGP metric in confederation will cause route
oscillation. AS 65100
10 MED:10 10 15
AS 102 Route Import 192.168.1.0/24 AS 101 RT1 RT2
RT3
20
RT5
11
AS 200
10 MED:5
RT4 AS 65200
MED:6 10
RT6
AS 103 RT3

RT5 Routing Table
Path 1 2 3
BGP Next Hop RT3 RT4 RT6
AS-PATH 102 101 103 101 (65200) 103 101
MED 10 5 6
IGP Metric 15 20 11
l Solution: Proper setting of IGP metric in confederation
[ Enable compare-different-as-med. [ Reset MED to 0. [ Set IGP metric properly.

Comparison Between Confederation and Reflector

Reference Factor
Multilevel Policy Control Complexity of conventional IBGP transfer Support capability
Comparison
Both support multilevel to further enhance the expandability. Multilevel route reflection structure is supported. Confederation allows route reflection used in member ASs. Both provide control of route selection policies, but confederation has more flexibility. The transfer of route reflection is of low complexity, because the overall network configuration seldom changes. However, transfer from IBGP to confederation needs great changes on configuration and network architecture. All routers in confederation must support confederation configuration capability, because all routers need understand the AS-PATH attribute of the confederation. In the architecture of route reflection, the reflector need support only route reflection capability. In new design of cluster division, however, the client is also required to understand the reflector attributes. Route reflection within AS needs a stand-alone IGP, while confederation supports a stand-alone or separated IGP, which may be the biggest advantage of confederation over route reflection. If the IGP meets its limit of expandability, or it is too large to process the management tasks, confederation can be used to reduce the size of IGP routing table. More experiences are drawn from route reflection because more ISPs have deployed route reflection rather than confederation. In face, AS combination is irrelevant with IBGP expandability. It is mentioned here because it is one of confederation advantages. An AS can be combined with an existing confederation by taking AS as a sub-AS of confederation.
IGP expandability Deployment experience AS combination
All rights reserved
Page 51

All rights reserved
Page 52

BGP Community Attribute
Concept of BGP Community Attribute Design of BGP Community Attribute
All rights reserved
Page 53
Concept of BGP Community Attribute

l A group of routes sharing the same features define a BGP
community attribute. Several communities can be applied to a route. Each community is of 4-byte long. There are two types of community attribute: [ Well-known communities " NO_EXPORT " LOCAL_AS " NO_ADVERTISE [ Private communities " As:number
All rights reserved
Page 54
Design of BGP Community Attribute

Route Origin Tracing
l Local AS differentiates routes.
[ Cross-over route [ Peer route [ User route
Example:
Route Type
Cross-over route Peer route User route
Community attribute ID
[ISP ASN]:1000 [ISP ASN]:2000 [ISP ASN]:3000
All rights reserved
Page 55

Dynamic user policy
l Operation on local priority attribute l Control by route policies
Example:
Local Preference Attribute
60 80 100 120 140
Community attribute ID
[ISP ASN]:60 [ISP ASN]:80 [ISP ASN]:100 [ISP ASN]:120 [ISP ASN]:140
Page 56
All rights reserved

Control of upstream route notification
l Community attributes can be flexibly used to make the AS
notify user routes to upstream peer.

l In general, two levels are defined:
[ Level 1 differentiates all routes of local AS. [ Level 2 allows the lower-level AS to set AS-PATH attributes accordingly or suppresses route notifications completely.
All rights reserved
Page 57
All rights reserved
Page 58
Chapter 3 BGP Performance Optimization

Section 1 Mitigation of Network Fault Affects Section 2 Optimization of Route Update Section 3 Policy Control
All rights reserved
Page 59
BGP performance optimization

Mitigation of Network Fault Affects
EBGP Port Sensitivity
IGP/BGP Convergence Time Increment
BGP Graceful Restart (GR)
All rights reserved
Page 60

l Fast disconnect EBGP sessions before timer timeout. l It is applicable to only EBGP peer. IBGP peer may bypass the invalid link
if it is faulty.
l It is globally enabled and, by default, activated. l Advantages:
[ When the upstream EBGP peer has several EBGP sessions, EBGP port sensitivity is very useful.
l Disadvantages:
[ Owing to jitter links, BGP session is hard to enter convergence status. [ It is unworkable in case of EBGP multi-hop. The peer address must be the same as its physical address.

Traffic Loss
AS 100
AS 300
RTA
RTE
RTD
AS 200
RTB
RTC
All rights reserved Page 62

Solution
l The router that restarted just now need notify a message in
IGP that is should not be used as a cross-over router. This means the restarted router must be the leaf node of the shortest path tree. Only direct traffic to the router should be sent to this router. [ IS-IS Overload Bit [ OSPF Maximum Metric
All rights reserved
Page 63

IS-IS Overload Bit
l The IS-IS protocol provides a feature named overload bit.
Being an LSP value, the overload bit is firstly used as a signal of notification in case of router fault. It ensures that this router should not be included in the network topology as one with cross-over capability.
l Routers with overload bit are still allowed for setup of BGP
sessions and BGP re-convergence. However, they cannot be used as cross-over routers.
l After convergence of BGP sessions, the router sends an LSP
notifying that the overload bit is removed.
All rights reserved
Page 64

OSPF Maximum Metric
l OSPF sets metric in LSA to ensure the router will not be used
as a cross-over path.
l Routers with metric are still allowed for setup of BGP sessions
and BGP re-convergence. However, they cannot be used as cross-over routers.

l After convergence of BGP session, the LSA for the new router
and the whole network are re-sent.
All rights reserved
Page 65
BGP-GR (Graceful Restard)

BGP-GR Functions
l Preventing route oscillation caused by active/standby board
switchover
l Ensuring no message loss when new board re-collects route
information from BGP peer
All rights reserved
Page 66

All rights reserved
Page 67
Route Update and Optimization

Purpose of Route Update and Optimization
l How to deal with the instability during route notification? l How to keep the affect of applying new policies to the minimum? l Available methods for route optimization:
[ Route jitter attenuation [ BGP route Keep-All-Routes and Route Refresh [ Loop detection at transmission side [ Outgoing route filtering (ORF)
All rights reserved
Page 68
Route jitter attenuation

Purpose of Route Jitter Attenuation
l Route jitter attenuation provides a mechanism to reduce the
router load caused by instable routes.

l It prevents continuous route jitter. l It enhances route stability, but not sacrifices the convergence
time of routes with good performance.
All rights reserved
Page 69
BGP Keep-All-Routes
BGP Keep-All-Routes
l When BGP policies are changed, the BGP sessions need be
reset to make the new policies effective. Resetting BGP sessions will cause route disturbance and route jitter. Resetting a large number of BGP peers may even trigger route jitter attenuation.
l Save the BGP route update information from all peers (groups)
since the setup of BGP connection, even if the routes do not meet the entry policies requirements.
l Trigger update of route information by proper inbound and
outbound policies.
All rights reserved
Page 70
Route Refresh
Route Refresh
l Route refresh is the negotiation ability of BGP at the initial
session stage.
l It allows BGP routers to request remote peers to resend the
outbound information library of BGP neighbor routes.

l Route refresh is the replacement of BGP Keep-All-Routes.
All rights reserved
Page 71
Loopback detection at transmission side

Loopback Detection
l Concept: A route will be rejected if the loop detection mechanism
of the peer detects its own AS number in AS-PATH.

l Optimization idea: These routes are blocked from notification at
the earliest time to reduce the size of BGP update packets.

l Applicable range: It is applicable to only EBGP peers. l Implementation: It is optimized by matching AS-PATH list with the
remote AS in AS-PATH attributes in the notified route information.

l Note: In special case, the loop detection at transmission side is
not expected, such as MPLS VPN Hub-And-Spoke.

Outbound Route Filtering (ORF)

ORF Concept and Advantages
l ORF Concept:
[ ORF is a BGP feature that reduces the number of BGP updates sent between peer routes to the minimum with the routes transmitting and receiving capability of BGP. [ Local routers initially send inbound routing policies to remote peer routers, which use them as outbound policies.
l ORF Advantages:
[ Reducing the number of BGP updates sent between peer routes to the minimum. [ Sparing bandwidth and speeding convergence

All rights reserved
Page 74
Policy Control
Policy Control Methods
l ip prefix-list l as-path-list l community-list l route-policy l filter-policy
All rights reserved
Page 75
Policy Control
Pseudo-AS Number
l What is pseudo-AS number?
[ When receiving/sending AS-PATH from/to the neighbor of local AS, BGP places pseudo-AS number before the real AS number.
l When is pseudo-AS number needed?
[ Change of AS number [ Device transfer or BGP session transfer
All rights reserved
Page 76
Policy Control
Advantages and Disadvantages of Pseudo-AS Number
l Advantages of Pseudo-AS Number:
[ Preventing network destruction caused by AS number change. [ Providing continuous communication for AS during AS transfer.
l Disadvantages of Pseudo-AS Number:
[ Making AS-PATH longer. [ Causing packet loss due to loop detection
All rights reserved
Page 77
Summary
l Same policy tool of BGP at first and at
last
l Affecting BGP performance most
seriously
l Multi-homing and load balance
All rights reserved
Page 78
Thank You
www.huawei.com

Odd010004 BGP Protocol Design Issue 1 - 0

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

Odd010004 BGP Protocol Design Issue 1 - 0

Hochgeladen von

Copyright:

Verfügbare Formate

Internal

ODD010004 BGP Protocol Design

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

Chapter 1 BGP Theories

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

information among ASs.

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

to new neighbor entities.

(including EBGP and IBGP).

neighbor entities depends on the IGP and BGP synchronization.

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

Chapter 1 BGP Theories

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

Common BGP Attribute

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

Chapter 1 BGP Theories

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

BGP Path Selection Procedure

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

Chapter 2 BGP Network Planning

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

BGP Network Planning

IBGP Core Design EBGP Core Design (I/E)BGP Core Design

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

IBGP Core Design

HUAWEI TECHNOLOGIES CO., LTD.

All rights reserved

PDF created with FinePrint pdfFactory Pro trial version www.pdffactory.com

IBGP Core Design