Multihoming to one ISP

From CT3

Jump to: navigation, search

A customer network connected with redundant (two or more) links to the same Internet Service Provider is the simplest form of multi-homing. This design provides resilience against link and device failures, but does not provide protection against major outages within the Service Provider network.

Image:MH_1ISP_Scenario.gif

Contents

Addressing

The customer multi-homed to a single ISP could use provider-independent (PI) addresses and advertise its IP prefix to the Internet. It’s best, however, to use provider-aggregatable (PA) addresses to help reduce the overall size of the Internet routing tables.

The PI-addresses should be used only if the customer wants to have the options of switching service providers or connecting to multiple ISPs in the future.

Routing

Static routing could be used between the customer and the ISP, but it’s highly recommended to use BGP on the PE-CE links, as it reliably detects link and adjacent router failure. Full Internet routing could be sent to the customer’s routers, but this is usually unnecessary. Default route propagated from the ISP via BGP is sufficient to establish correct upstream routing; BGP prefixes of the ISP and its other customers could be advertised to optimize local routing. The IP prefixes assigned to the customer (PI or PA prefixes) should always be advertised from the customer’s (CE) routers via BGP to ensure link/device failure detection.

If the customer already owns an Autonomous System (AS) number, it should be used from the start. Otherwise, a private AS number could be configured on the customer site.

BGP routing with PA addresses

The provider-aggregatable prefix assigned to a customer shall never be propagated beyond the provider’s AS. It’s therefore irrelevant whether the customer uses private or registered AS number, as the paths originated by the customer are never propagated into the Internet. The filtering of the customer’s IP prefixes is the ISP’s responsibility.

The ISP could use a variety of mechanisms to filter customer’s PA prefixes, for example:

  • If the ISP propagates BGP communities within its AS, it could mark all PA prefixes received from the customers with the no-export community, which will ensure that they are never propagated beyond the ISP’s AS.
  • The ISP could filter outbound updates sent toward its peering partners removing all small PA prefixes (for example, all prefixes smaller than /20).

Image:MH_1ISP_NoExport.gif

The following printout shows a typical PE-router configuration. The PE-router advertises the default route and the local prefixes to the customer’s router and marks all inbound routes with the no-export community. Inbound prefix-list filter ensures that the customer cannot insert unauthorized prefixes into the provider’s AS.

router bgp 123
 template peer-policy Private_MH
  filter-list 100 out
  default-originate
 exit-peer-policy
 !
 template peer-policy Private_MH_PA
  route-map Private_MH_PA in
  inherit peer-policy Private_MH 1
 exit-peer-policy
 !
 neighbor 192.168.1.2 remote-as 65000
 neighbor 192.168.1.2 prefix-list Customer_A in
 neighbor 192.168.1.2 inherit peer-policy Private_MH_PA 
!
ip prefix-list Customer_A seq 5 permit 10.0.1.0/24
!
ip as-path access-list 100 permit ^$
!
route-map Private_MH_PA permit 10
 set community no-export additive

BGP routing with PI addresses and private AS number

If a customer already owns provider-independent addresses but does not have a registered AS number, it can use a private AS number to establish BGP peering with the ISP to which it’s multi-homed. The ISP should remove the private AS number of the customer on all other EBGP sessions with the neighbor remove-private-as option, making the customer’s PI prefix appear as if it’s originated from within the ISP’s AS.

Image:MH_1ISP_RemovePrivateAS.gif

The configuration of the customer-facing PE-router is very similar to the one described in the BGP routing with PA addresses section (the inbound route-map is removed as the PI prefixes should not be marked with the no-export community).

router bgp 123
 template peer-policy Private_MH
  filter-list 100 out
  default-originate
 exit-peer-policy
 !
 neighbor 192.168.1.2 remote-as 65000
 neighbor 192.168.1.2 prefix-list Customer_A in
 neighbor 192.168.1.2 inherit peer-policy Private_MH
!
ip prefix-list Customer_A seq 5 permit 10.0.1.0/24
!
ip as-path access-list 100 permit ^$

If an ISP allows its customers to use private AS numbers for BGP peering, the remove-private-as option has to be configured on all EBGP peers throughout the ISP’s network (or, at the very minimum, on the EBGP sessions with other ISPs). A sample router configuration from an IXP router is included in the following printout:

router bgp 123
 neighbor 192.168.2.2 remote-as 456
 neighbor 192.168.2.2 remove-private-as

Using this setup, an IP prefix with a private AS number advertised from the customer …

E1#show ip bgp neighbor 192.168.2.2 advertised-routes | begin Network
Network Next Hop MetricLocPrf Weight Path
*>i10.0.1.0/24 192.168.1.2 0 100 0 65000i

… appears as originating from the provider’s AS (AS 123) on the EBGP peer:

X1#show ip bgp regexp 123
Network Next Hop MetricLocPrf Weight Path
*> 10.0.1.0/24 192.168.2.1 0 123i

BGP routing with PI addresses and registered AS number

This is a classic multi-homed scenario and will not be described any further.

Related information

Additional Resources  

Configuring BGP on Cisco Routers (BGP) course
Other links
Personal tools

CT3

Main menu