© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.25-1 Customer-to-Provider Connectivity with BGP Understanding Customer-to-Provider Connectivity.

Презентация:



Advertisements
Похожие презентации
© 2005 Cisco Systems, Inc. All rights reserved. BGP v Customer-to-Provider Connectivity with BGP Connecting a Multihomed Customer to Multiple Service.
Advertisements

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Route Selection Using Policy Controls Using Multihomed BGP Networks.
© 2005 Cisco Systems, Inc. All rights reserved. BGP v Module Summary There are a number of connectivity aspects that must be considered in planning.
© 2005 Cisco Systems, Inc. All rights reserved. BGP v Customer-to-Provider Connectivity with BGP Connecting a Multihomed Customer to a Single Service.
© 2005 Cisco Systems, Inc. All rights reserved. BGP v Customer-to-Provider Connectivity with BGP Implementing Customer Connectivity Using Static.
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v Integrating Internet Access with MPLS VPNs Introducing Internet Access Models with MPLS VPNs.
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v Integrating Internet Access with MPLS VPNs Implementing Internet Access as a Separate VPN.
© 2005 Cisco Systems, Inc. All rights reserved. BGP v Scaling Service Provider Networks Scaling IGP and BGP in Service Provider Networks.
© 2006 Cisco Systems, Inc. All rights reserved. BSCI v Implementing BGP Explaining BGP Concepts and Terminology.
© 2005 Cisco Systems, Inc. All rights reserved. BGP v BGP Overview Understanding BGP Path Attributes.
Designing Enterprise Edge Connectivity © 2004 Cisco Systems, Inc. All rights reserved. Designing the Internet Connectivity Module ARCH v
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v MPLS VPN Technology Introducing the MPLS VPN Routing Model.
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v Complex MPLS VPNs Introducing Central Services VPNs.
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v Integrating Internet Access with MPLS VPNs Implementing Separate Internet Access and VPN Services.
© 2005 Cisco Systems, Inc. All rights reserved. BGP v BGP Transit Autonomous Systems Configuring a Transit AS.
© 2005 Cisco Systems, Inc. All rights reserved. BGP v Scaling Service Provider Networks Designing Networks with Route Reflectors.
© 2005 Cisco Systems, Inc. All rights reserved. BGP v Module Summary The multihomed customer network must exchange BGP information with both ISP.
© 2006 Cisco Systems, Inc. All rights reserved. BSCI v Implementing BGP Using Route Maps to Manipulate Basic BGP Paths.
© 2005 Cisco Systems, Inc. All rights reserved. BGP v BGP Transit Autonomous Systems Forwarding Packets in a Transit AS.
© 2005 Cisco Systems, Inc. All rights reserved. BGP v Route Selection Using Policy Controls Applying Route-Maps as BGP Filters.
Транксрипт:

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Customer-to-Provider Connectivity with BGP Understanding Customer-to-Provider Connectivity Requirements

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Outline Overview Customer Connectivity Types Redundancy in Customer Connections Customer-to-Provider Routing Schemes Customer Routing Addressing Requirements AS Number Allocation Summary

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Customer Connectivity Types Internet customers have a wide range of connectivity and redundancy requirements: Single permanent connection to the Internet Multiple permanent connections to a single provider in primary and backup configuration Multiple permanent connections to a single provider used for load sharing of traffic Connections to multiple service providers for maximum redundancy

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Single Permanent Connection to the Internet The simplest setup: a single link between the customer network and the Internet No redundancy for link or equipment failure

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Multiple Permanent Connections Providing Redundancy Customers wanting increased redundancy install several physical links to the Internet. Redundant links are used in primary and backup setup or for load sharing. Redundancy is for link or equipment failure. There is no redundancy for service provider failure.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Multiple Permanent Connections Providing Load Sharing Customers wanting to increase their access speed can install several physical links between a pair of routers. There is redundancy for link failure. There is no redundancy for equipment failure. Load sharing in this setup is optimal.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Connections to Multiple Service Providers Customers with maximum redundancy requirements install physical links to multiple ISPs. There is redundancy for link, equipment, or service provider failure. Primary and backup setup is complex without service provider assistance. Good load sharing is impossible to achieve.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Static or dynamic routing can be used between an Internet customer and an ISP. BGP is the only acceptable dynamic routing protocol. Because of its lower complexity, static routing is preferred. Customer-to-Provider Routing Schemes

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Customer RoutingSingle Permanent Connection Static routing is usually adequate. BGP should not be used in this setup.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Static routing is preferred if physical link failure can be detected. Traffic will enter a black hole if the physical link failure is not detected. Customer RoutingMultiple Connections

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Customer RoutingMultiple Connections (Cont.) You can still use static routing if link and remote equipment failure can be detected reliably. BGP between the customer and the service provider is usually used in this setup.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v BGP must be used in this setup. Static routing is not possible. Customer RoutingMultihomed Customers

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Addressing RequirementsSingle-Homed Customers Customers connected to a single service provider usually get their address space from the provider. Provider-assigned (PA) address space. This is the most common customer setup. Customer has to renumber if service provider changes. Customers gets only a small address block from the service provider. Private addresses are used inside customer network. NAT must be used

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Addressing RequirementsMultihomed Customers Customers connected to multiple service providers should get their own address space. Provider-independent (PI) address space. No renumbering is required for a service provider change. Some service providers might not guarantee routing for small block (for example, /24) of PI space. Multihomed customers can sometimes use PA address space. The customer must have a separate public AS number. The provider must agree to having another ISP advertise its address space.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Addressing RequirementsPublic and Private

© 2005 Cisco Systems, Inc. All rights reserved. BGP v AS Number AllocationSingle-Homed Customers Customers running BGP with the service provider need their own BGP AS number. Private AS numbers (64512–65535) can be used for customers connected to a single service provider.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v AS Number AllocationMultihomed Customers Multihomed customers must run BGP with their service providers. Multihomed customers must use public AS numbers for their autonomous systems.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Summary Different customers have different requirements for their Internet connections. These connectivity options include a single connection to a single ISP, multiple connections to the same ISP, and multiple connections to different ISPs. The least redundant, and most common, connection is a single permanent connection to a single ISP. Multiple permanent connections provide redundancy for links or equipment only; multiple permanent connections with load sharing provide redundancy only for link failure; and connections to multiple service providers offer redundancy for link, equipment, or provider failure. Depending upon the networking requirements of the customer, static (preferable) or dynamic routing may be used to connect a customer to an ISP.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v Summary (Cont.) For a single permanent connection to the Internet, for multiple permanent connections between a single router on the customer network and a single router on the ISP network, and for two different routers on the customer network connected to two different routers on the ISP network, static routing is usually adequate. Multiple permanent connections to more than one ISP always require the use of dynamic routing with BGP, however. Customers that are connected to a single ISP usually get their PA address space assigned by the ISP, while customers that are connected to more than one ISP should, if possible, assign their own PI address space and not have addresses that are delegated from any of their ISPs. Whenever BGP is in use, an AS number is required. The customer does not need a public AS number if it is connected to a single ISP. A multihomed customer, however, requires a public AS number.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v