Best Practice: Configuring BGP Route Reflection

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Best Practice: Configuring BGP Route Reflection"

Transcription

1 community.brocade.com Best Practice: Configuring BGP Route Reflection BRCD-ENTERPRISE 2477 Introduction This best practice document is focused on the configuration aspects of deploying redundant BGP route reflectors (RRs) in service provider networks using NetIron OS. It will cover the following topics: Overview of Route Reflection (RR) Full-mesh BGP topologies Description of RR Why RRs are commonly deployed (scale and full-mesh configuration) How routing loops are avoided with RRs Best Practice for deploying and configuring redundant route reflection CLUSTER_ID configuration This best practice document is Service Provider focused, as most enterprises do not need to use BGP inside their enterprise network. The focus is on the NetIron series of products; such as the MLX and CER service provider products. The CES product may be applicable, but due to its limited scale in IP (as compared to CER), it s less applicable and most likely would not be deployed as a BGP RR. The CER-RT product will be very applicable due to its increased scale in IP routing. The CER-RT will be very well positioned to function as a BGP RR. Before You Begin Prerequisites It is assumed that the reader has an understanding of IP routing and BGP operation and configuration. Topic of Discussion BGP Route Reflection (RFC 4456) Generated by Brocade Communities on :00 Page 1/14

2 Overview of BGP Full-Mesh Topologies Border Gateway Protocol (BGP) v4 is massively deployed in the Internet and has been so for many, many years. All IP service provider and carrier networks deploy BGP inside and outside their networks. When BGP is used outside an SP network, it is external-bgp (ebgp), and when it is used inside an SP network, it is internal-bgp (ibgp). This BCP is focused on ibgp topologies; and more specifically, when an ibgp topology utilizes route reflection (RR). An ibgp full-mesh is the standard BGP design and topology. A full-mesh is required to ensure all externally received routes are propagated to all the internal BGP speakers inside an Autonomous System (AS). The common best practice for ibgp peering is to use the routers primary loopback IP address as the BGP peering endpoint. This provides additional resiliency for ibgp peering in case of an interface or link failure. For ebgp, the common best practice is to use the external interface IP address as the BGP peering endpoint. If that interface or link fails, the ebgp peering session will go down, which is the expected result. There are alternatives to this, but they are beyond the scope of this document. Figure 1: ibgp Full-Mesh Topology To avoid BGP routing loops, a BGP router will not re-advertise an internally learned route to another internal BGP router. For instance, if an ibgp router receives a route from an ibgp peer, it cannot re-advertise that route to other ibgp peers. Doing so would create a BGP routing loop. Since re-advertisement of these routes is prohibited, a BGP router that receives external routing information (Network Layer Reachability Information, or NLRI) must directly advertise the NLRI to every other ibgp router in the AS. This is shown in Figure 2 below. Figure 2: ibgp Advertisements Generated by Brocade Communities on :00 Page 2/14

3 For example, if R2 were to re-advertise 10.1/16 to R4, and R4 were to re-advertise to R3, then R3 would also re-advertise 10.1/16 back to R1. The standard BGP loop prevention mechanism of AS_PATH is not applicable in ibgp topologies, as all the routers are in the same AS (Autonomous System). So, the result of doing this would create a routing loop. For proper loop prevention, the rules of BGP results in a full-mesh topology being required. If there is not a full-mesh, then not every ibgp router will receive all the NLRI. This will result in black-hole forwarding. Description of BGP Route Reflection The result of the required full-mesh topology can be a serious scaling concern in large IP networks. The full-mesh topology results in the common N-squared problem. Every ibgp router needs to be configured to peer and exchange routes with every other ibgp router in the AS. This is not only configuration intensive, but the large numbers of BGP peerings (BGP establishes TCP sessions, using TCP Port 179) also results in large numbers of TCP sessions in the network. This adds additional control plane load on each router, and further increases network Generated by Brocade Communities on :00 Page 3/14

4 operational complexity in maintaining and troubleshooting the large numbers of BGP peerings. Imagine a network with 100 ibgp routers; this would result in each router having 99 BGP peering sessions for a total of 4950 BGP sessions (N*(N-1)/2) in the AS! BGP Route Reflection (RFC 4456) basically relaxes the rule, described above, that prevents routing loops in BGP topologies. In other words, an ibgp router can re-advertise NLRI that it receives from another ibgp router. This ibgp router is called a route reflector (RR); which is an excellent description of its operation. A RR reflects NLRI learned from one ibgp router to other ibgp routers. This is shown in the diagram below. Figure 3: Basic Route Reflection As shown above, one or more RRs is deployed in the AS (RR1 is the route reflector in this Figure). R5 in this topology is called a RR client. R5, the RR Generated by Brocade Communities on :00 Page 4/14

5 client, ibgp peers only with the RR(s); it does not peer to other ibgp routers. [Note: There is a slight variation to these design criteria; where RR clients may peer to each other, but it s not commonly done and outside the scope of this document.] R5 receives external routing information from R10, its ebgp peer, and advertises this to its RR1. RR1 receives this routing information, performs its standard BGP loop detection and best-path decision process, and re-advertises its best paths to all of its ibgp neighbors and to all of its other clients (if it has other RR clients). The resulting ibgp full-mesh is now drastically reduced; while still maintain proper routing information in all of the ibgp routers in the AS. Otherwise, R5 would need to be part of the ibgp full-mesh topology. The resulting BGP topology is now more manageable from an operations, configuration and routing state (number of peers and advertised routes) perspective. Full mesh ibgp peering is no longer required and the routing table (RIB) in the client router is reduced, often significantly. This is because the RR only reflects the best path that it has selected due to its BGP best-path decision process. There may be additional backup paths available to the RR but the client only receives the best path. [Note: While this is beneficial from a RIB size perspective on the client router, recent Internet Drafts are being written to allow the RR to reflect all the paths it has available. However, pros and cons for doing so are outside the scope of this document.] Another key advantage of using route reflection is when a new or additional ibgp router is added to the network, the new ibgp router can easily become a RR client of one or more RRs with a few simple additional configurations. The new ibgp router no longer needs to be configured to peer with every other ibgp router in the AS; and additionally, only the RR(s) needs to have its BGP configuration updated to include this new ibgp peer. The remaining ibgp routers in the AS do not need to have their configurations modified. It should be noted that a RR client router is not aware, nor does it need any special configuration, that it is functioning as a client. Only the RR needs additional configuration beyond the basic BGP configurations. Loop Prevention BGP Attributes While BGP topologies benefit from route reflection in terms of operational simplicity and scale, there still must be a proper loop prevention or detection capability. Inside an AS, BGP routing loops are prevented by the full-mesh topology and the rule of an ibgp router cannot re-advertise routes learnt from Generated by Brocade Communities on :00 Page 5/14

6 one ibgp router to another ibgp router. Outside an AS (ie: In the Internet), BGP routing loops are prevented with the use of the BGP AS_PATH attribute. When a BGP router receives NLRI, it first checks the AS_PATH attribute to determine if its configured ASN (AS Number) is included in the AS_PATH. If it is, the route has looped and the router discards the route. In other words, the route was either initially advertised by the local AS, or the route has been received through the local AS. In either case, the route has looped and must be ignored to prevent forwarding loops. Inside an AS, the AS_PATH attribute is not useful as a loop detection mechanism because all the routers in the local AS have the same ASN configured. This is why an ibgp full-mesh is required inside an AS. However; BGP route reflection relaxes this full-mesh rule which may lead to a routing loop inside the local AS. RFC 4456 introduces new BGP attributes to detect and avoid routing loops inside an AS when BGP route reflection is used. ORIGINATOR_ID This attribute contains the identifier of the router that originates the route into the local AS. The identifier used is the Router-ID (RID) of the originating router. The RR creates the ORIGINATOR_ID attribute and inserts the RID of the originating router; which would typically be one of its configured RR clients. If an RR originates a route into the local AS (RRs are not often deployed in this manner, but it is possible), it will insert its RID into the ORIGINATOR_ID attribute. If an ibgp router receives a routing update with its RID contained in the ORIGINATOR_ID attribute, then the route has looped and it will be discarded. CLUSTER_LIST This attribute contains the identifier of the router that originates the route into the local AS. The identifier used is the Router-ID (RID) of the originating router. The RR creates the ORIGINATOR_ID attribute and inserts the RID of the originating router; which would typically be one of its configured RR clients. If an RR originates a route into the local AS (RRs are not often deployed in this manner, but it is possible), it will insert its RID into the ORIGINATOR_ID attribute. If an ibgp router receives a routing update with its RID contained in the ORIGINATOR_ID attribute, then the route has looped and it will be discarded. Generated by Brocade Communities on :00 Page 6/14

7 BCP on Redundant BGP Route Reflection When a single RR is deployed in a BGP topology, the best practice recommendations in this document do not really apply. However, the best practice recommended here should also be followed even when a single RR is deployed. The primary point of this document focuses on situations where there is more than one RR deployed in a network; and more specifically, when a BGP RR cluster has more than one RR. There are two scenarios to discuss: 1. A BGP topology with many RRs but only a single RR per cluster. 2. A BGP topology with many RRs and more than one RR per cluster (ie. multi-cluster) The 1st scenario was shown in Figure 3. The 2nd scenario is shown below in Figure 4. Figure 4: Redundant Route Reflection Generated by Brocade Communities on :00 Page 7/14

8 Figure 4 shows RR client R5 peered to two RRs, RR1 and RR3. If either RR1 or RR3 were to fail, the 10.1/16 prefix from R10 will still be advertised to R2 and R4 by the other available RR. This is the most common deployment scenario for an ibgp topology using route reflection. So, redundancy is provided and the forwarding performance of the network is minimally affected if a single RR were to fail. All routes advertised from that RR will be withdrawn by the other routers and the IGP will re-route the underlying IP topology around the failed RR. Some BGP implementations will create the CLUSTER_ID automatically, while allowing the option to manually configure the CLUSTER_ID (such as NetIron OS), while other BGP implementation may require a manually configured CLUSTER_ID. In scenario 1, the BCP is to manually configure the CLUSTER_ID of the RR and to make this the same as the Router-ID (RID) of the router. The RID is a unique value and the common practice is to make the RID the same as the configured primary loopback IP address. So, the net result is that the loopback IP address is the same as the RID and the CLUSTER_ID. This makes network operations and troubleshooting simpler and is pretty straight-forward. The 2nd scenario where there is more than one RR per cluster is the more interesting scenario. Assume a cluster with two RRs (for redundancy reasons), as shown in Figure 4. The client, R5, is peered to both RRs. In the event one of the RRs fails, the other RR already has all the routes so routing consistency and forwarding is maintained. As a side note: In the event of a single RR failure, the packet forwarding performance of the network should not be affected, even while there is a routing convergence event. This is because the BGP next-hop of a route is typically not the BGP RR itself, but is a BGP RR client router (R5 in this example). Per RFC 4456, a BGP RR must not modify the BGP next-hop attribute when it reflects route. So, while there is a routing convergence event when one RR fails, the BGP next-hop of a route is not changed so forwarding to that BGP next-hop should not be affected. In Figure 4, R2 receives two routes to 10.1/16, one from each of the RRs. R2 performs its best-path decision process and installs one of those routes into its local FIB; while keeping the secondary, backup route in its local RIB. In Figure 4, it is most likely that R2 will install the route to 10.1/16 that it received from RR1 as its best path since R2 and RR1 are adjacent and the IGP metric is lower than it would be from R2 to RR3. If RR1 fails, R2 should not drop packets when it updates its FIB with the secondary route since the BGP next-hop of that route has not changed. This secondary route is now the primary and preferred route. Referring again to Figure 4, R5 is the BGP next-hop for external destination 10.1/16. R2 can reach R5 via RR1 or via R4-RR3. If RR1 fails, that does not change the BGP next-hop; it is still R5. R2 s FIB should be automatically updated so that R2 sends packets to R3 to reach R5 and no longer sends packets to RR1 to reach R5 (since RR1 has failed). So, while there will be a short control plane routing convergence event in the local AS, data plane packet forwarding should not be (or minimally, at most) affected. When two (or more) RRs are deployed for redundancy reasons, there is a decision of which CLUSTER_ID to configure on the RRs. While following the recommendations described here, each RR will be configured to have its CLUSTER_ID the same value as its primary loopback IP address. This makes the CLUSTER_IDs of each of the RRs unique. The alternate decision is to configure both RRs of a cluster with the same CLUSTER_ID value. This is shown here. Figure 5: Redundant Route-Reflection with same CLUSTER_ID Generated by Brocade Communities on :00 Page 8/14

9 The problem with configuring both RRs to have the same CLUSTER_ID is that the RRs can no longer accept reflected routes from each other. The RR will see its configured CLUSTER_ID in the CLUSTER_LIST attribute of routes that it receives from the other RR, and it will discard the route due to loop prevention rules. Whereas in the first case using unique CLUSTER_IDs on each of the RRs, each RR can now receive each others reflected routes. The CLUSTER_LIST of the reflected route will contain the CLUSTER_ID of the other RR, which is unique in the AS, and the receiving router will not discard the route due to loop prevention rules. While this slight difference in behavior may appear harmless, the case of configuring the same CLUSTER_ID on both RRs can lead to corner cases of blackhole forwarding. Potential Black-Hole Forwarding Scenario Assume the network topology shown below. Generated by Brocade Communities on :00 Page 9/14

10 Figure 6: Redundant RRs and Black-Hole Scenario R5 receives external routing information from R10 via ebgp. It advertises the NLRI to RR1 and RR3. RR1 and RR3 both reflect the NLRI to R2 and R4, and also to each other. Since they are both configured with the same CLUSTER_ID ( ), they will both ignore the reflected NLRI from each other due to loop prevention rules. Their configured CLUSTER_ID is present in the CLUSTER_LIST attribute. Proper routing and forwarding behavior is still maintained under normal operating conditions. R5 is the BGP next-hop for 10.1/16 and R5 is reachable from all other ibgp routers via the IGP. Route recursion provides this reachability: Destination 10.1/16 has a BGP next-hop of ; where is reachable via the IGP. R5 is configured with next-hop-self (which is a standard best practice), so that when it advertises 10.1/16 it sets the BGP next-hop to itself. The address used for this would be its loopback IP address. Generated by Brocade Communities on :00 Page 10/14

11 If RR1 were to fail, as previously described, the network will re-converge with minimal or no impact to packet forwarding. This is because R2 has two paths in its RIB for destination 10.1/16, one from each of the RRs. R2 will select one of those as its best route and install that in its FIB. The BGP nexthop of 10.1/16 is for both paths is reachable via the IGP from R2-RR1-R5 and from R2-R4-RR3-R5. It selects the path R2- RR1-R5 due to that path having a lower (better) IGP metric. So, even during a failure of an RR, routing and forwarding continues to function. However, if the BGP peering session between R5 and RR1 fails, then there is a black-hole problem. In this scenario, RR1 is still active in the network and is still peering to other ibgp routers. Only its ibgp session to R5 is down. When R2 is forwarding packets to destination 10.1/16, the IGP directs those packets through RR1 to ultimately reach R5 and R10. As previously described, this is due to IGP metrics, as the shortest-path to the BGP next-hop of is through R2-RR1-R5 and not through R2-R4-RR3-R5. R2-R4-RR3-R5 is the backup path that is still contained in R2 s RIB. However, now that the BGP peering session between R5 and RR1 is down, RR1 no longer has the external destination 10.1/16 in its routing or forwarding tables. Although RR2 had reflected that route to RR1, due to loop prevention rules, RR1 discards that route. RR1 saw its configured CLUSTER_ID in the CLUSTER_LIST attribute. So, now when RR1 receives packets from R2 that are destined to external destination 10.1/16, it does not find route 10.1/16 in its RIB or FIB. It will drop those packets. This is the black-hole problem, resulting from configuring the same CLUSTER_ID on both RRs. The scenario of the BGP peering session between R5 and RR1 failing, while both routers remain active in the network IGP, can be considered a corner case scenario. However, it is possible either due to mis-configuration or some other circumstance. A network operator could be configuring either R5 or RR1 and due to a mis-configuration, the BGP peering session could be accidentally mis-configured. Another possible scenario is either R5 or RR1 could have its management/control plane CPU at a high level for some reason resulting in dropped BGP keepalives. In such a case, any number of BGP peering sessions could fail or flap. If each RR had its loopback IP address configured as its CLUSTER_ID, the uniqueness of loopback IP addresses ensures there is no similar black-hole problem in such a failure scenario. RR1 would accept the reflected routes from RR2; and even though its peering session to R5 is down, destination routes from R10 are maintained in its RIB and FIB. When RR1 now receives packets for destination 10.1/16 it does a lookup in its FIB and finds that Generated by Brocade Communities on :00 Page 11/14

12 route and its associated BGP next-hop of , which is R5. The IGP informs RR1 how to reach next-hop and the packets are forwarded to R5. It should be noted that the result of this configuration will increase the BGP RIB size on both RRs. This is because each RR will have received routes directly from R5, and the same routes with different path attributes from the other RR. However; in most cases, the benefit of avoiding the black-hole scenario outweighs this increase in RIB size. So, based on the black-hole forwarding problem described here, the recommended best common practice is to configure each RR with a unique CLUSTER_ID. Furthermore, the CLUSTER_ID should be configured as the same value as the primary loopback IP address. The BGP Router-ID should also be configured as the same value as the primary loopback IP address. If RIB size in the RRs is not a large concern, then the best practice recommended here is to configure the CLUSTER_ID of each RR to be unique. If there are memory or RIB constraints, then perhaps it would be acceptable to configure the same CLUSTER_ID on each RR but at the risk of experiencing the black-hole forwarding problem. RR Configuration These examples are for RR1 only. To configure the Router_ID to match the local primary loopback IP address: NetIron(config)# ip router-id To enable BGP, configure the local-as number: NetIron(config)# router bgp BGP4: Please configure 'local-as' parameter in order to enable BGP4. NetIron(config-bgp)# local-as 10 Configure a BGP peer group for the ibgp peers (ibgp peers to RR1 are R2, RR3, R4): NetIron(config-bgp)# neighbor PeerGroup1 peer-group NetIron(config-bgp)# neighbor PeerGroup1 description ibgp Peers Generated by Brocade Communities on :00 Page 12/14

13 Now add the IBGP peers to the peer group: NetIron(config-bgp)# neighbor peer-group PeerGroup1 NetIron(config-bgp)# neighbor peer-group PeerGroup1 Ne To enable route reflection, the router needs to be configured with the peer address of the RR client. Also, it is a best practice to put the RR client in a different BGP peer group from the ibgp peers. To add R5 as an RR client of RR1, enter the following command on RR1: NetIron(config-bgp)# neighbor PeerGroup2 peer-group NetIron(config-bgp)# neighbor PeerGroup2 description RR Clients To configure RR1 with a CLUSTER-ID of , which matches the Router_ID and local primary loopback IP address: NetIron(config-bgp)# cluster-id Summary The best current practice for configuration of the CLUSTER_ID on route reflectors is to make the value the same as the local router s primary loopback IP address. This value should also be the configured BGP Router-ID. This ensures uniqueness of the CLUSTER_ID and Router-ID of each RR in the AS. This makes network operations and troubleshooting simpler. The primary loopback IP address of each router should always be advertised into the IGP of the network, using standard IGP configurations. Configuring unique CLUSTER_IDs on redundant RRs serving the same clients also prevents a corner case black-hole forwarding scenario. The black-hole forwarding scenario that can be avoided is described in detail in this paper. This type of configuration provides the RR client with redundant RR clusters, since each RR is in its own cluster. If memory or RIB size on the RRs is a concern, it may be necessary to configure the same CLUSTER_ID on both RRs. Doing so will reduce the memory / RIB consumption on each of the RRs. However, the network operations staff should be aware of the black-hole forwarding problem of this type of configuration. Most deployed RRs today do not have much of a memory constraint, so it is expected that the best practice of configuring unique CLUSTER_IDs on each of the RRs would be applicable in most cases. Generated by Brocade Communities on :00 Page 13/14

14 Related Information For more information, see the documents below: RFC 4271 A Border Gateway Protocol 4 (BGP4), January 2006 RFC 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (ibgp), April Brocade NetIron OS Configuration Guide, September Some, but not all of the content in this site provided, reviewed, approved or endorsed by Brocade and is provided solely as a convenience of our customers. All postings and use of the content on this site are subject to the BROCADE EXTRANET TERMS AND CONDITIONS OF USE of the site. BROCADE ASSUMES NO LIABIITY WHATSOEVER, MAKES NO REPRESENTATION AND DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO THE CONTENT PROVIDED HEREIN, INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, CORRECTNESS, APPROPRIATENESS OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED EXPECT AS PROVIDED IN BROCADE S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, THIRD PARTIES USE THIS CONTENT AT THEIR OWN RISK. Content on this site may contain or be subject to specific guidelines or limitation on use. Third parties using this content agree to abide by any limitation or guidelines and to comply with the BROCADE EXTRANET TERMS AND CONDITIONS OF USE of this site. Brocade may make changes to this content, to specifications, or product design or descriptions at any time, or may remove content at its sole discretion without notice. Corporate Headquarters San Jose, CA USA T: European Headquarters Geneva, Switzerland T: Asia Pacific Headquarters Singapore T: Notice: Some, but not all of the content in this site provided, reviewed, approved or endorsed by Brocade and is provided solely as a convenience of our customers. All postings and use of the content on this site are subject to the BROCADE EXTRANET TERMS AND CONDITIONS OF USE of the site. BROCADE ASSUMES NO LIABIITY WHATSOEVER, MAKES NO REPRESENTATION AND DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO THE CONTENT PROVIDED HEREIN, INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, CORRECTNESS, APPROPRIATENESS OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED EXPECT AS PROVIDED IN BROCADE S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, THIRD PARTIES USE THIS CONTENT AT THEIR OWN RISK. Content on this site may contain or be subject to specific guidelines or limitation on use. Third parties using this content agree to abide by any limitation or guidelines and to comply with the BROCADE EXTRANET TERMS AND CONDITIONS OF USE of this site. Brocade may make changes to this content, to specifications, or product design or descriptions at any time, or may remove content at its sole discretion without notice. Generated by Brocade Communities on :00 Page 14/14

BGP Best Path Selection Algorithm

BGP Best Path Selection Algorithm BGP Best Path Selection Algorithm Document ID: 13753 Contents Introduction Prerequisites Requirements Components Used Conventions Why Routers Ignore Paths How the Best Path Algorithm Works Example: BGP

More information

BGP Attributes and Path Selection

BGP Attributes and Path Selection BGP Attributes and Path Selection ISP Workshops Last updated 29 th March 2015 1 BGP Attributes BGP s policy tool kit 2 What Is an Attribute?... Next Hop AS Path MED...... p Part of a BGP Update p Describes

More information

BGP Diverse Path Using a Diverse-Path Route Reflector

BGP Diverse Path Using a Diverse-Path Route Reflector BGP Diverse Path Using a Diverse-Path Route Reflector The feature allows Border Gateway Protocol (BGP) to distribute an alternative path other than the best path between BGP speakers when route reflectors

More information

BGP Scaling Techniques

BGP Scaling Techniques BGP Scaling Techniques Philip Smith E2 Workshop, AfNOG 2006 BGP Scaling Techniques How to scale ibgp mesh beyond a few peers? How to implement new policy without causing flaps and route churning? How to

More information

basic BGP in Huawei CLI

basic BGP in Huawei CLI basic BGP in Huawei CLI BGP stands for Border Gateway Protocol. It is widely used among Internet Service Providers to make core routing decisions on the Internet. The current BGP version is BGP-4 defined

More information

BGP Basics. BGP Uses TCP 179 ibgp - BGP Peers in the same AS ebgp - BGP Peers in different AS's. 64512-65535 Private BGP ASN. BGP Router Processes

BGP Basics. BGP Uses TCP 179 ibgp - BGP Peers in the same AS ebgp - BGP Peers in different AS's. 64512-65535 Private BGP ASN. BGP Router Processes BGP Basics BGPv4 - RFC 4271 - IPv6 support Path vector routing protocol EGP Routing between AS'es Classless Transit Area - Area used to reach other areas. Requires full routing table (no default routes).

More information

BGP Router Startup Message Flow

BGP Router Startup Message Flow LEG: Brief BGP Router Startup Message Flow This sequence diagram was generated with EventStudio System Designer (http://www.eventhelix.com/eventstudio). The Border Gateway Protocol (BGP) is an inter-autonomous

More information

E6998-02: Internet Routing

E6998-02: Internet Routing E6998-02: Internet Routing Lecture 13 Border Gateway Protocol, Part II John Ioannidis AT&T Labs Research ji+ir@cs.columbia.edu Copyright 2002 by John Ioannidis. All Rights Reserved. Announcements Lectures

More information

CS551 External v.s. Internal BGP

CS551 External v.s. Internal BGP CS551 External v.s. Internal BGP Bill Cheng http://merlot.usc.edu/cs551-f12 1 Exterior vs. Interior World vs. me EGP vs. IGP Little control vs. complete administrative control BGP (and GGP, Hello, EGP)

More information

Routing Protocol - BGP

Routing Protocol - BGP Routing Protocol - BGP BGP Enterprise Network BGP ISP AS 3000 AS 2000 BGP is using between Autonomous Systems BGP(cont.) RFC 1771(BGPv4) Support CIDR Transfer the AS information to reach destination Using

More information

Cisco BGP Case Studies

Cisco BGP Case Studies Table of Contents BGP Case Studies...1 BGP4 Case Studies Section 1...3 Contents...3 Introduction...3 How Does BGP Work?...3 ebgp and ibgp...3 Enabling BGP Routing...4 Forming BGP Neighbors...4 BGP and

More information

Understanding Virtual Router and Virtual Systems

Understanding Virtual Router and Virtual Systems Understanding Virtual Router and Virtual Systems PAN- OS 6.0 Humair Ali Professional Services Content Table of Contents VIRTUAL ROUTER... 5 CONNECTED... 8 STATIC ROUTING... 9 OSPF... 11 BGP... 17 IMPORT

More information

Border Gateway Protocol (BGP)

Border Gateway Protocol (BGP) Border Gateway Protocol (BGP) Petr Grygárek rek 1 Role of Autonomous Systems on the Internet 2 Autonomous systems Not possible to maintain complete Internet topology information on all routers big database,

More information

Exterior Gateway Protocols (BGP)

Exterior Gateway Protocols (BGP) Exterior Gateway Protocols (BGP) Internet Structure Large ISP Large ISP Stub Dial-Up ISP Small ISP Stub Stub Stub Autonomous Systems (AS) Internet is not a single network! The Internet is a collection

More information

APNIC elearning: BGP Basics. Contact: training@apnic.net. erou03_v1.0

APNIC elearning: BGP Basics. Contact: training@apnic.net. erou03_v1.0 erou03_v1.0 APNIC elearning: BGP Basics Contact: training@apnic.net Overview What is BGP? BGP Features Path Vector Routing Protocol Peering and Transit BGP General Operation BGP Terminology BGP Attributes

More information

Inter-domain Routing Basics. Border Gateway Protocol. Inter-domain Routing Basics. Inter-domain Routing Basics. Exterior routing protocols created to:

Inter-domain Routing Basics. Border Gateway Protocol. Inter-domain Routing Basics. Inter-domain Routing Basics. Exterior routing protocols created to: Border Gateway Protocol Exterior routing protocols created to: control the expansion of routing tables provide a structured view of the Internet by segregating routing domains into separate administrations

More information

APNIC elearning: BGP Attributes

APNIC elearning: BGP Attributes APNIC elearning: BGP Attributes Contact: training@apnic.net erou04_v1.0 Overview BGP Attributes Well-known and Optional Attributes AS Path AS Loop Detection ibgp and ebgp Next Hop Next Hop Best Practice

More information

Bell Aliant. Business Internet Border Gateway Protocol Policy and Features Guidelines

Bell Aliant. Business Internet Border Gateway Protocol Policy and Features Guidelines Bell Aliant Business Internet Border Gateway Protocol Policy and Features Guidelines Effective 05/30/2006, Updated 1/30/2015 BGP Policy and Features Guidelines 1 Bell Aliant BGP Features Bell Aliant offers

More information

Module 12 Multihoming to the Same ISP

Module 12 Multihoming to the Same ISP Module 12 Multihoming to the Same ISP Objective: To investigate various methods for multihoming onto the same upstream s backbone Prerequisites: Module 11 and Multihoming Presentation The following will

More information

JUNOS Secure BGP Template

JUNOS Secure BGP Template JUNOS Secure BGP Template Version 1.92, 03/30/2005 Stephen Gill E-mail: gillsr@cymru.com Published: 04/25/2001 Contents Credits... 2 Introduction... 2 Template... 4 References... 10 Credits Rob Thomas

More information

Configuring BGP. Cisco s BGP Implementation

Configuring BGP. Cisco s BGP Implementation Configuring BGP This chapter describes how to configure Border Gateway Protocol (BGP). For a complete description of the BGP commands in this chapter, refer to the BGP s chapter of the Network Protocols

More information

Transitioning to BGP. ISP Workshops. Last updated 24 April 2013

Transitioning to BGP. ISP Workshops. Last updated 24 April 2013 Transitioning to BGP ISP Workshops Last updated 24 April 2013 1 Scaling the network How to get out of carrying all prefixes in IGP 2 Why use BGP rather than IGP? p IGP has Limitations: n The more routing

More information

Increasing Path Diversity using Route Reflector

Increasing Path Diversity using Route Reflector International Journal of Engineering Science Invention ISSN (Online): 2319 6734, ISSN (Print): 2319 6726 Volume 2 Issue 5 ǁ May. 2013 ǁ PP.05-09 Increasing Path Diversity using Route Reflector Prasha Dubey

More information

BGP Convergence in much less than a second Clarence Filsfils - cf@cisco.com

BGP Convergence in much less than a second Clarence Filsfils - cf@cisco.com BGP Convergence in much less than a second Clarence Filsfils - cf@cisco.com 1 Down Convergence T1 Down Convergence T2 Default metric = 1 Src R R 20 F Dst Link L Assume a flow from Src to Dest T1: when

More information

BGP overview BGP operations BGP messages BGP decision algorithm BGP states

BGP overview BGP operations BGP messages BGP decision algorithm BGP states BGP overview BGP operations BGP messages BGP decision algorithm BGP states 1 BGP overview Currently in version 4. InterAS (or Interdomain) routing protocol for exchanging network reachability information

More information

-Green line is total enrollment -2008 numbers are projected to be near 20,000 (on-campus) not including distance education numbers.

-Green line is total enrollment -2008 numbers are projected to be near 20,000 (on-campus) not including distance education numbers. 1 2 3 4 -Lower yellow line is graduate student enrollment -Red line is undergradate enrollment -Green line is total enrollment -2008 numbers are projected to be near 20,000 (on-campus) not including distance

More information

GregSowell.com. Mikrotik Routing

GregSowell.com. Mikrotik Routing Mikrotik Routing Static Dynamic Routing To Be Discussed RIP Quick Discussion OSPF BGP What is Routing Wikipedia has a very lengthy explanation http://en.wikipedia.org/wiki/routing In the context of this

More information

Module 7 BGP Route Reflector Lab

Module 7 BGP Route Reflector Lab Module 7 BGP Route Reflector Lab ISP/IXP Networking Workshop Lab Objective: To implement BGP route reflectors as an alternative to fully-meshed ibgp. Prerequisites: Module 1, the Scaling BGP presentation

More information

Securing Networks with Mikrotik Router OS Speaker: Tom Smyth, CTO Wireless Connect Ltd. Location: Dubai Date:

Securing Networks with Mikrotik Router OS Speaker: Tom Smyth, CTO Wireless Connect Ltd. Location: Dubai Date: 1 Securing Networks with Mikrotik Router OS Speaker: Tom Smyth, CTO Wireless Connect Ltd. Location: Dubai Date: 28-08-2012 2 Wireless Connect Ltd. Irish Company Incorporated in 2006 Operate an ISP in the

More information

Internet Exchange Points Workshop

Internet Exchange Points Workshop Sofía Silva Berenguer sofia @ lacnic.net Internet Exchange Points Workshop AGENDA How the Internet Works Intro to BGP IPv4 Exhaustion and IPv6 Deployment Internet Exchange Points How to request Internet

More information

Using the Border Gateway Protocol for Interdomain Routing

Using the Border Gateway Protocol for Interdomain Routing CHAPTER 12 Using the Border Gateway Protocol for Interdomain Routing The Border Gateway Protocol (BGP), defined in RFC 1771, provides loop-free interdomain routing between autonomous systems. (An autonomous

More information

BGP Terminology, Concepts, and Operation. Chapter 6 2007 2010, Cisco Systems, Inc. All rights reserved. Cisco Public

BGP Terminology, Concepts, and Operation. Chapter 6 2007 2010, Cisco Systems, Inc. All rights reserved. Cisco Public BGP Terminology, Concepts, and Operation 1 IGP versus EGP Interior gateway protocol (IGP) A routing protocol operating within an Autonomous System (AS). RIP, OSPF, and EIGRP are IGPs. Exterior gateway

More information

Internet inter-as routing: BGP

Internet inter-as routing: BGP Internet inter-as routing: BGP BGP (Border Gateway Protocol): the de facto standard BGP provides each AS a means to: 1. Obtain subnet reachability information from neighboring ASs. 2. Propagate the reachability

More information

Understanding Route Aggregation in BGP

Understanding Route Aggregation in BGP Understanding Route Aggregation in BGP Document ID: 5441 Contents Introduction Prerequisites Requirements Components Used Conventions Network Diagram Aggregate Without the as set Argument Aggregate with

More information

Fast Re-Route in IP/MPLS networks using Ericsson s IP Operating System

Fast Re-Route in IP/MPLS networks using Ericsson s IP Operating System Fast Re-Route in IP/MPLS networks using s IP Operating System Introduction: Today, Internet routers employ several routing protocols to exchange routes. As a router learns its potential routes, it builds

More information

Multihomed BGP Configurations

Multihomed BGP Configurations Multihomed BGP Configurations lvaro Retana Cisco IOS Deployment and Scalability 1 genda General Considerations Multihomed Networks Best Current Practices 2 The Basics General Considerations 3 General Considerations

More information

Module 7. Routing and Congestion Control. Version 2 CSE IIT, Kharagpur

Module 7. Routing and Congestion Control. Version 2 CSE IIT, Kharagpur Module 7 Routing and Congestion Control Lesson 4 Border Gateway Protocol (BGP) Specific Instructional Objectives On completion of this lesson, the students will be able to: Explain the operation of the

More information

HP Networking BGP and MPLS technology training

HP Networking BGP and MPLS technology training Course overview HP Networking BGP and MPLS technology training (HL046_00429577) The HP Networking BGP and MPLS technology training provides networking professionals the knowledge necessary for designing,

More information

--BGP 4 White Paper Ver.1.0-- BGP-4 in Vanguard Routers

--BGP 4 White Paper Ver.1.0-- BGP-4 in Vanguard Routers BGP-4 in Vanguard Routers 1 Table of Contents Introduction to BGP... 6 BGP terminology... 6 AS (Autonomous system):... 6 AS connection:... 6 BGP Speaker:... 6 BGP Neighbor/Peer:... 7 BGP Session:... 7

More information

Internet Routing Overview

Internet Routing Overview Internet Routing Overview AS, IGP,, BGP Agenda Routing at Large Types of Autonomous Systems -2 Introduction BGP Internet Routing Overview, v4.5 2 Page 45-1 Routing in Small Networks in small networks distance

More information

Interdomain Routing. Outline

Interdomain Routing. Outline Interdomain Routing David Andersen 15-744 Spring 2007 Carnegie Mellon University Outline What does the Internet look like? Relationships between providers Enforced by: Export filters and import ranking

More information

Examination. IP routning på Internet och andra sammansatta nät, DD2491 IP routing in the Internet and other complex networks, DD2491

Examination. IP routning på Internet och andra sammansatta nät, DD2491 IP routing in the Internet and other complex networks, DD2491 Examination IP routning på Internet och andra sammansatta nät, DD2491 IP routing in the Internet and other complex networks, DD2491 Date: December 15 2009 14:00 18:00 1. No help material is allowed - You

More information

Configuring Border Gateway Protocol in AOS for Releases Prior to 18.03.00/R10.1.0

Configuring Border Gateway Protocol in AOS for Releases Prior to 18.03.00/R10.1.0 61200860L1-29.4E March 2012 Configuration Guide Configuring Border Gateway Protocol in AOS for Releases Prior to 18.03.00/R10.1.0 This guide only addresses BGP in AOS data products using AOS firmware prior

More information

Routing in Small Networks. Internet Routing Overview. Agenda. Routing in Large Networks

Routing in Small Networks. Internet Routing Overview. Agenda. Routing in Large Networks Routing in Small Networks Internet Routing Overview AS, IGP,, BGP in small networks distance vector or link state protocols like RIP or OSPF can be used for dynamic routing it is possible that every router

More information

IPv6 BGP Route Reflector Configuration Example

IPv6 BGP Route Reflector Configuration Example IPv6 BGP Route Reflector Configuration Example Document ID: 113419 Contents Introduction Prerequisites Requirements Components Used Conventions Configure Network Diagram Sample Configurations Verify Related

More information

MPLS-based Layer 3 VPNs

MPLS-based Layer 3 VPNs MPLS-based Layer 3 VPNs Overall objective The purpose of this lab is to study Layer 3 Virtual Private Networks (L3VPNs) created using MPLS and BGP. A VPN is an extension of a private network that uses

More information

RFC 2547bis: BGP/MPLS VPN Fundamentals

RFC 2547bis: BGP/MPLS VPN Fundamentals White Paper RFC 2547bis: BGP/MPLS VPN Fundamentals Chuck Semeria Marketing Engineer Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408 745 2001 or 888 JUNIPER www.juniper.net

More information

MPLS VPN. Agenda. MP-BGP VPN Overview MPLS VPN Architecture MPLS VPN Basic VPNs MPLS VPN Complex VPNs MPLS VPN Configuration (Cisco) L86 - MPLS VPN

MPLS VPN. Agenda. MP-BGP VPN Overview MPLS VPN Architecture MPLS VPN Basic VPNs MPLS VPN Complex VPNs MPLS VPN Configuration (Cisco) L86 - MPLS VPN MPLS VPN Peer to Peer VPN s Agenda MP-BGP VPN Overview MPLS VPN Architecture MPLS VPN Basic VPNs MPLS VPN Complex VPNs MPLS VPN Configuration (Cisco) CE-PE OSPF Routing CE-PE Static Routing CE-PE RIP Routing

More information

Border Gateway Protocol (BGP-4)

Border Gateway Protocol (BGP-4) Vanguard Applications Ware IP and LAN Feature Protocols Border Gateway Protocol (BGP-4) Notice 2008 Vanguard Networks 25 Forbes Blvd Foxboro, MA 02035 Phone: (508) 964 6200 Fax: (508) 543 0237 All rights

More information

Troubleshooting BGP BRKRST-3320. 2007, Cisco Systems, Inc. All rights reserved. 13884_05_2007_c1.scr BRKRST-3320

Troubleshooting BGP BRKRST-3320. 2007, Cisco Systems, Inc. All rights reserved. 13884_05_2007_c1.scr BRKRST-3320 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 1 Troubleshooting BGP 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 2 Overview Troubleshooting Peers BGP Convergence High Utilization

More information

WHITEPAPER. Bringing MPLS to Data Center Fabrics with Labeled BGP

WHITEPAPER. Bringing MPLS to Data Center Fabrics with Labeled BGP WHITEPAPER Bringing MPLS to Data Center Fabrics with Labeled BGP Bringing MPLS to Data Center Fabrics with Labeled BGP MPLS is a well-known and mature technology typically used in service provider environment.

More information

IK2205 Inter-domain Routing

IK2205 Inter-domain Routing IK2205 Inter-domain Routing Lecture 5 Voravit Tanyingyong, voravit@kth.se Outline Redundancy, Symmetry, and Load Balancing Redundancy Symmetry Load balancing Scenarios Controlling Routing Inside the AS

More information

Chapter 6: Implementing a Border Gateway Protocol Solution for ISP Connectivity

Chapter 6: Implementing a Border Gateway Protocol Solution for ISP Connectivity : Implementing a Border Gateway Protocol Solution for ISP Connectivity CCNP ROUTE: Implementing IP Routing ROUTE v6 1 Objectives Describe basic BGP terminology and operation, including EBGP and IBGP. Configure

More information

BGP Link Bandwidth. Finding Feature Information. Contents

BGP Link Bandwidth. Finding Feature Information. Contents The BGP (Border Gateway Protocol) Link Bandwidth feature is used to advertise the bandwidth of an autonomous system exit link as an extended community. This feature is configured for links between directly

More information

IPv6 over MPLS VPN. Contents. Prerequisites. Document ID: 112085. Requirements

IPv6 over MPLS VPN. Contents. Prerequisites. Document ID: 112085. Requirements IPv6 over MPLS VPN Document ID: 112085 Contents Introduction Prerequisites Requirements Components Used Conventions Configure Network Diagram VRF Configuration Multiprotocol BGP (MP BGP) Configuration

More information

Based on Computer Networking, 4 th Edition by Kurose and Ross

Based on Computer Networking, 4 th Edition by Kurose and Ross Computer Networks Internet Routing Based on Computer Networking, 4 th Edition by Kurose and Ross Intra-AS Routing Also known as Interior Gateway Protocols (IGP) Most common Intra-AS routing protocols:

More information

IP/MPLS-Based VPNs Layer-3 vs. Layer-2

IP/MPLS-Based VPNs Layer-3 vs. Layer-2 Table of Contents 1. Objective... 3 2. Target Audience... 3 3. Pre-Requisites... 3 4. Introduction...3 5. MPLS Layer-3 VPNs... 4 6. MPLS Layer-2 VPNs... 7 6.1. Point-to-Point Connectivity... 8 6.2. Multi-Point

More information

BGP4 Case Studies/Tutorial

BGP4 Case Studies/Tutorial BGP4 Case Studies/Tutorial Sam Halabi-cisco Systems The purpose of this paper is to introduce the reader to the latest in BGP4 terminology and design issues. It is targeted to the novice as well as the

More information

BFD. (Bidirectional Forwarding Detection) Does it work and is it worth it? Tom Scholl, AT&T Labs NANOG 45

BFD. (Bidirectional Forwarding Detection) Does it work and is it worth it? Tom Scholl, AT&T Labs NANOG 45 BFD (Bidirectional Forwarding Detection) Does it work and is it worth it? Tom Scholl, AT&T Labs NANOG 45 What is BFD? BFD provides a method to validate the operation of the forwarding plane between two

More information

Multi-Chassis Trunking for Resilient and High-Performance Network Architectures

Multi-Chassis Trunking for Resilient and High-Performance Network Architectures WHITE PAPER www.brocade.com IP Network Multi-Chassis Trunking for Resilient and High-Performance Network Architectures Multi-Chassis Trunking is a key Brocade technology in the Brocade One architecture

More information

Internet inter-as routing: BGP

Internet inter-as routing: BGP Internet inter-as routing: BGP BGP (Border Gateway Protocol): the de facto standard BGP provides each AS a means to: 1. Obtain subnet reachability information from neighboring ASs. 2. Propagate the reachability

More information

Gateway of last resort is 192.208.10.5 to network 192.208.10.0

Gateway of last resort is 192.208.10.5 to network 192.208.10.0 RTB#sh ip bgp BGP table version is 14, local router ID is 203.250.15.10 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP,? - incomplete Network

More information

Deploying OSPF for ISPs. OSPF Design. Agenda. Service Providers. SP Architecture. SP Architecture. OSPF Design in SP Networks

Deploying OSPF for ISPs. OSPF Design. Agenda. Service Providers. SP Architecture. SP Architecture. OSPF Design in SP Networks Agenda OSPF Design in SP Networks Deploying OSPF for ISPs Adding Networks in OSPF OSPF in IOS ISP/IXP 1 2 Service Providers OSPF Design As applicable to Service Provider Networks SP networks are divided

More information

Advanced BGP Policy. Advanced Topics

Advanced BGP Policy. Advanced Topics Advanced BGP Policy George Wu TCOM690 Advanced Topics Route redundancy Load balancing Routing Symmetry 1 Route Optimization Issues Redundancy provide multiple alternate paths usually multiple connections

More information

JNCIA Juniper Networks Certified Internet Associate

JNCIA Juniper Networks Certified Internet Associate JNCIA Juniper Networks Certified Internet Associate Study Guide - Chapter 8 by Joseph M. Soricelli with John L. Hammond, Galina Diker Pildush, Thomas E. Van Meter, and Todd M. Warble This book was originally

More information

Basic Configuration Examples for BGP

Basic Configuration Examples for BGP Application Note Basic Configuration Examples for BGP Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408 745 2000 or 888 JUNIPER www.juniper.net Part Number: :350008-001 04/02

More information

IPv6 Routing Protocols

IPv6 Routing Protocols IPv6 Routing Protocols Texas IPv6 Task Force Summit 2012 Faraz Shamim - Technical Leader Cisco Systems Inc Agenda IPv6 Routing Protocols RIPng EIGRPv6 ISISv6 OSPFv3 BGP4+ IPv6 challenges & IGP Selection

More information

Outline. EE 122: Interdomain Routing Protocol (BGP) BGP Routing. Internet is more complicated... Ion Stoica TAs: Junda Liu, DK Moon, David Zats

Outline. EE 122: Interdomain Routing Protocol (BGP) BGP Routing. Internet is more complicated... Ion Stoica TAs: Junda Liu, DK Moon, David Zats Outline EE 22: Interdomain Routing Protocol (BGP) Ion Stoica TAs: Junda Liu, DK Moon, David Zats http://inst.eecs.berkeley.edu/~ee22/fa9 (Materials with thanks to Vern Paxson, Jennifer Rexford, and colleagues

More information

Application Note: Securing BGP on Juniper Routers

Application Note: Securing BGP on Juniper Routers Application Note: Securing BGP on Juniper Routers Version 1.92, 03/30/2005 Stephen Gill E-mail: gillsr@cymru.com Published: 06/16/2002 Contents Introduction Introduction... 2 Assumptions... 3 Topology...

More information

BGP: Frequently Asked Questions

BGP: Frequently Asked Questions BGP: Frequently Asked Questions Document ID: 5816 Contents Introduction How do I configure BGP? How do I configure BGP with the use of a loopback address? What is the order of preference of attributes

More information

Configuring BGP Services

Configuring BGP Services Part No. 314721-C Rev 00 May 2004 4655 Great America Parkway Santa Clara, CA 95054 Passport 8000 Series Software Release 3.7 *314721-C Rev 00* 2 Copyright 2003 Nortel Networks All rights reserved. May

More information

Day in the Life of a BGP Update in Cisco IOS

Day in the Life of a BGP Update in Cisco IOS Day in the Life of a BGP Update in Cisco IOS Routing WG RIPE45 Philip Smith Routing WG,, Barcelona May 2003 1 Background Presentation tracks a BGP update through a router running Cisco IOS 2 Basic BGP

More information

Doing Don ts: Modifying BGP Attributes within an Autonomous System

Doing Don ts: Modifying BGP Attributes within an Autonomous System Doing Don ts: Modifying BGP Attributes within an Autonomous System Luca Cittadini, Stefano Vissicchio, Giuseppe Di Battista Università degli Studi RomaTre IEEE/IFIP Network Operations and Management Symposium

More information

BGP Routing. Course Description. Students Will Learn. Target Audience. Hands-On

BGP Routing. Course Description. Students Will Learn. Target Audience. Hands-On Hands-On Course Description This Hands-On course on (Border Gateway Protocol), from the basics of how it works through to advanced issues such as route reflectors, policy, filtering, route selection and

More information

6.263 Data Communication Networks

6.263 Data Communication Networks 6.6 Data Communication Networks Lecture : Internet Routing (some slides are taken from I. Stoica and N. Mckewon & T. Griffin) Dina Katabi dk@mit.edu www.nms.csail.mit.edu/~dina Books Text Book Data Communication

More information

Today s Agenda. Note: it takes years to really master BGP Many slides stolen from Prof. Zhi-Li Zhang at Minnesota and from Avi Freedman s slides

Today s Agenda. Note: it takes years to really master BGP Many slides stolen from Prof. Zhi-Li Zhang at Minnesota and from Avi Freedman s slides Today s Agenda BGP Overview Note: it takes years to really master BGP Many slides stolen from Prof. Zhi-Li Zhang at Minnesota and from Avi Freedman s slides AS Relationship Inference There ll be some openresearch

More information

Understanding and Optimizing BGP Peering Relationships with Advanced Route and Traffic Analytics

Understanding and Optimizing BGP Peering Relationships with Advanced Route and Traffic Analytics Understanding and Optimizing BGP Peering Relationships with Advanced Route and Traffic Analytics WHITE PAPER Table of Contents Introduction 3 Route-Flow Fusion 4 BGP Policy Visibility 5 Traffic Visibility

More information

Introduction to MPLS-based VPNs

Introduction to MPLS-based VPNs Introduction to MPLS-based VPNs Ferit Yegenoglu, Ph.D. ISOCORE ferit@isocore.com Outline Introduction BGP/MPLS VPNs Network Architecture Overview Main Features of BGP/MPLS VPNs Required Protocol Extensions

More information

Introduction to BGP. Cisco ISP Workshops. 2003, Cisco Systems, Inc. All rights reserved.

Introduction to BGP. Cisco ISP Workshops. 2003, Cisco Systems, Inc. All rights reserved. Introduction to BGP Cisco ISP Workshops 1 Border Gateway Protocol Routing Protocol used to exchange routing information between networks exterior gateway protocol RFC1771 work in progress to update draft-ietf-idr-bgp4-18.txt

More information

BGP Advanced Routing in SonicOS

BGP Advanced Routing in SonicOS BGP Advanced Routing in SonicOS Document Scope This document provides an overview of SonicWALL s implmenetation of Border Gateway protocol (BGP), how BGP operates, and how to configure BGP for your network.

More information

Advanced Routing. FortiOS Handbook v3 for FortiOS 4.0 MR3

Advanced Routing. FortiOS Handbook v3 for FortiOS 4.0 MR3 Advanced Routing FortiOS Handbook v3 for FortiOS 4.0 MR3 FortiOS Handbook Advanced Routing v3 4 January 2013 01-433-98043-20120116 Copyright 2012 Fortinet, Inc. All rights reserved. Fortinet, FortiGate,

More information

BGP Multipath Load Sharing for Both ebgp and ibgp in an MPLS-VPN

BGP Multipath Load Sharing for Both ebgp and ibgp in an MPLS-VPN BGP Multipath Load Sharing for Both ebgp and ibgp in an MPLS-VPN The BGP Multipath Load Sharing for ebgp and ibgp feature allows you to configure multipath load balancing with both external BGP (ebgp)

More information

BGP Troubleshooting Guide

BGP Troubleshooting Guide BGP Troubleshooting Guide Abstract The main purpose of this guide is to illustrate various issues encountered while configuring BGP on HP routers. This troubleshooting guide discusses ways of analyzing

More information

Lecture 18: Border Gateway Protocol"

Lecture 18: Border Gateway Protocol Lecture 18: Border Gateway Protocol" CSE 123: Computer Networks Alex C. Snoeren HW 3 due Wednesday! Some figures courtesy Mike Freedman Lecture 18 Overview" Path-vector Routing Allows scalable, informed

More information

s@lm@n Juniper Exam JN0-343 Juniper Networks Certified Internet Specialist (JNCIS-ENT) Version: 10.1 [ Total Questions: 498 ]

s@lm@n Juniper Exam JN0-343 Juniper Networks Certified Internet Specialist (JNCIS-ENT) Version: 10.1 [ Total Questions: 498 ] s@lm@n Juniper Exam JN0-343 Juniper Networks Certified Internet Specialist (JNCIS-ENT) Version: 10.1 [ Total Questions: 498 ] Topic 1, Volume A Question No : 1 - (Topic 1) How much overhead does the GRE

More information

Date Submitted: 2-1-2014. Course Number: 9110

Date Submitted: 2-1-2014. Course Number: 9110 Date Submitted: 2-1-2014 Course Title: Advanced IPv6 Migration Course Number: 9110 Pricing & Length Classroom: 4 days, (onsite and public offering) Course Description: This advanced, hands-on course covers

More information

Introduction to Routing

Introduction to Routing Introduction to Routing How traffic flows on the Internet Philip Smith pfs@cisco.com RIPE NCC Regional Meeting, Moscow, 16-18 18 June 2004 1 Abstract Presentation introduces some of the terminologies used,

More information

How to Configure BGP Tech Note

How to Configure BGP Tech Note How to Configure BGP Tech Note This document gives step by step instructions for configuring and testing full-mesh multi-homed ebgp using Palo Alto Networks devices in both an Active/Passive and Active/Active

More information

netkit lab bgp: prefix-filtering Università degli Studi Roma Tre Dipartimento di Informatica e Automazione Computer Networks Research Group

netkit lab bgp: prefix-filtering Università degli Studi Roma Tre Dipartimento di Informatica e Automazione Computer Networks Research Group Università degli Studi Roma Tre Dipartimento di Informatica e Automazione Computer Networks Research Group netkit lab bgp: prefix-filtering Version Author(s) E-mail Web Description 2.1 G. Di Battista,

More information

ETHEL THE AARDVARK GOES BGP ROUTING

ETHEL THE AARDVARK GOES BGP ROUTING Fable Of Contents ISP TECH TALK by Avi Freedman ETHEL THE AARDVARK GOES BGP ROUTING In this exciting column we'll actually walk through configuring a Cisco router for BGP. It's very important, however,

More information

MPLS WAN Explorer. Enterprise Network Management Visibility through the MPLS VPN Cloud

MPLS WAN Explorer. Enterprise Network Management Visibility through the MPLS VPN Cloud MPLS WAN Explorer Enterprise Network Management Visibility through the MPLS VPN Cloud Executive Summary Increasing numbers of enterprises are outsourcing their backbone WAN routing to MPLS VPN service

More information

Troubleshooting BGP. Philip Smith NANOG 33 Las Vegas 30 January 1 February 2005

Troubleshooting BGP. Philip Smith NANOG 33 Las Vegas 30 January 1 February 2005 Troubleshooting BGP Philip Smith Las Vegas 30 January 1 February 2005 1 Presentation Slides Available on ftp://ftp-eng.cisco.com /pfs/seminars/nanog33-bgp-troubleshooting.pdf 2 Assumptions

More information

DD2491 p1 2008. Inter-domain routing and BGP part I Olof Hagsand KTH/CSC

DD2491 p1 2008. Inter-domain routing and BGP part I Olof Hagsand KTH/CSC DD2491 p1 2008 Inter-domain routing and BGP part I Olof Hagsand KTH/CSC Inter-domain routing The objective of inter-domain routing is to bind together all the thousands of independent IP networks that

More information

MPLS VPN Route Target Rewrite

MPLS VPN Route Target Rewrite The feature allows the replacement of route targets on incoming and outgoing Border Gateway Protocol (BGP) updates Typically, Autonomous System Border Routers (ASBRs) perform the replacement of route targets

More information

MPLS Layer 2 VPNs Functional and Performance Testing Sample Test Plans

MPLS Layer 2 VPNs Functional and Performance Testing Sample Test Plans MPLS Layer 2 VPNs Functional and Performance Testing Sample Test Plans Contents Overview 1 1. L2 VPN Padding Verification Test 1 1.1 Objective 1 1.2 Setup 1 1.3 Input Parameters 2 1.4 Methodology 2 1.5

More information

> Border Gateway Protocol (BGP-4) Technical Configuration Guide. Ethernet Routing Switch. Engineering

> Border Gateway Protocol (BGP-4) Technical Configuration Guide. Ethernet Routing Switch. Engineering Ethernet Routing Switch 8600 Engineering > Border Gateway Protocol (BGP-4) Technical Configuration Guide Enterprise Solution Engineering Document Date: November, 2007 Document Number: NN48500-538 Document

More information

Understanding Route Redistribution & Filtering

Understanding Route Redistribution & Filtering Understanding Route Redistribution & Filtering When to Redistribute and Filter PAN-OS 5.0 Revision B 2013, Palo Alto Networks, Inc. www.paloaltonetworks.com Contents Overview... 3 Route Redistribution......

More information

Exam Name: BGP + MPLS Exam Exam Type Cisco Case Studies: 3 Exam Code: 642-691 Total Questions: 401

Exam Name: BGP + MPLS Exam Exam Type Cisco Case Studies: 3 Exam Code: 642-691 Total Questions: 401 Question: 1 Every time a flap occurs on a route, the route receives A. 750 per-flap penalty points which are user configurable B. 1500 per-flap penalty points which are user configurable C. 200 per-flap

More information

July 13, Copyright 2015 Thread Group, Inc. All rights reserved.

July 13, Copyright 2015 Thread Group, Inc. All rights reserved. July 13, 2015 This Thread Technical white paper is provided for reference purposes only. The full technical specification is available to Thread Group Members. To join and gain access, please follow this

More information

Network Level Multihoming and BGP Challenges

Network Level Multihoming and BGP Challenges Network Level Multihoming and BGP Challenges Li Jia Helsinki University of Technology jili@cc.hut.fi Abstract Multihoming has been traditionally employed by enterprises and ISPs to improve network connectivity.

More information