Bell Aliant
Business Internet
Border Gateway Protocol Policy and Features
Guidelines
1
Bell Aliant BGP Features
Bell Aliant offers Border Gateway Protocol version 4 (BGPv4) customers configuration options, features, and route tags to enable enhanced Internet routing. Bell Aliant Customer Solutions Engineer (CSE) or IP Network Operations Center (INOC) representatives are available to assist with understanding and implementing these features.
1.1 BGP Neighbor Security
Bell Aliant requires the use of MD5 authentication on all BGP peering connections between the Bell Aliant Internet access router (POP) and the customer gateway router. Bell Aliant provides a shared-secret key at the time of service activation. Bell Aliant BGP will not be enabled unless both peering neighbors are configured with the proper shared-secret key supplied by Bell Aliant.
To minimize any risks associated with external connection attempts and man-in-the-middle attacks Bell Aliant does not support the configuration of the eBGP multi-hop based peering sessions.
1.2 BGP Graceful Restart
Bell Aliant has enabled Border Gateway Protocol Graceful Restart for each customer BGP peering neighbor. BGP graceful restart provides non-stop forwarding functionality as described RFC 4724 (Graceful Restart Mechanism for BGP). This ensures the highest level of service availability to customers who enable the feature set. The customer gateway router may be configured to participate in BGP graceful restart and allow negotiation of the feature upon establishment of the BGP session with Bell Aliant. Vendor implementation and configuration may vary, please consult your documentation for implementation and support details.
1.3 Bell Aliant BGP Community Values
Bell Aliant offers customers additional BGPv4 feature options to enhance their ability to control IP traffic flow. Customers access these features through the use of special community marking on network prefixes that are announced to Bell Aliant. Depending on the topology and routing policy requirements, Bell Aliant customers may select from the following enhanced feature community markings for their Bell Aliant peering configuration:
COMMUNITY TAG
ATTRIBUTE BELL ALIANT ACTION
855:1 AS Path Prepend AS 855 one (1) time, 855 855 855:2 AS Path Prepend AS 855 two (2) times, 855 855 855 855:3 AS Path Prepend AS 855 three (3) times, 855 855 855 855 855:120 Local Preference Set LP=120, Customer Default Preference 855:110 Local Preference Set LP=110, Bell Aliant Peer Default Preference 855:100 Local Preference Set LP=100, Bell Aliant Transit Default Preference 855:90 Local Preference Set LP=90, Less Preferred
855:80 Local Preference Set LP=80, Least Preferred
855:500 Prefixes will only be advertised to Bell Aliant eBGP
customers. Prefixes will not be announced to Private Peers or Transit Providers. Similar to well known community no-export.
855:550 Announce to Bell Aliant eBGP customers and Private Peers. Do not announce to Bell Aliant Transit providers. 855:666 Black-hole customer destined traffic. Accepted only for /32
prefixes from customer supplied prefix range. AS Path Prepend communities, 855:500 and 855:550 cannot be used concurrently. Prefixes not tagged with any communities to indicate LP will get the default LP value of 120.
1.4 Bell Aliant BGP Prefix Propagation
Customers may not always require complete Internet prefix tables. Customers may request one of the following Bell Aliant prefix advertisement options:
Full Internet prefixes – Provides a full table of approximately 515,000+ Internet prefixes;
including Bell Aliant Customer, Bell Aliant Peer, and Bell Aliant Transit prefixes.
Bell Aliant partial prefixes – Provides a partial table of Bell Aliant Customers, Bell Aliant
Peers and Bell Aliant originated default prefix (209.128.0.1/32 and 0.0.0.0/0). This is ~130K+ prefixes.
Bell Aliant Default Next-hop Prefix
To accommodate users requiring a default next-hop Bell Aliant originates a default-prefix of 209.128.0.1/32. This prefix is provided for customers for use as the next-hop IP address for static default routing or gateway of last resort.
Recursive forwarding table lookup will provide valid forwarding information. On successive lookups interface based switching methods in modern devices (Cisco CEF et al) will provide the necessary forwarding lookup. Should forwarding information for prefix 209.128.0.1/32 be removed due to loss of neighbor (BGP peer), the customer statically configured default will not maintain a valid next-hop entry and as such will be withdrawn from the forwarding table.
1.5 Customer BGP Prefix Propagation
Bell Aliant’s policy is to notify Bell Aliant upstream peers of customer announced prefixes. Customers are required to provide written notification with a complete list of aggregated prefixes that will be announced to Bell Aliant. This includes prefixes representing networks assigned to the customer, prefixes that will be originated by the customer on behalf of another organization or party, as well as all prefixes that will be transiting the customer connection.
Bell Aliant BGP accepts prefixes from the customer and applies Best Common Practice filtering to:
Accept Customer provided prefixes only.
Accept in scope Black-hole prefixes (i.e. /32 Member of Customer Prefix Block).
Reject RFC-1918 prefixes.
Reject 0.0.0.0/0 default routes.
Reject small prefixes (length /26 - /32).
Transit carriers only accept prefixes that are /24 or shorter. Bell Aliant will accept /25 prefixes from its BGP customers to allow load balancing between multiple links to Bell Aliant. To have full Internet reachability, BGP customers must advertise an aggregate of a least /24 in length. Only prefixes of /24 or shorted will be forwarded onto Transit Internet and other Bell Aliant BGP Peers.
1.6 Private AS Peering
Bell Aliant supports customer BGP peering using a Private AS Number. This is useful for customers that wish to have redundant Internet connections to Bell Aliant and use BGP for failover or load balancing purposes without requiring their own Public AS Number.
Bell Aliant customers will use the Private AS number 64855. Bell Aliant will strip this AS number from the AS Path when prefixes are forwarded to all other Bell Aliant BGP Peers. Customers are not permitted to perform AS Path prepending using private AS numbers. For inbound traffic manipulation, customers should use the BGP Communities list in section 1.3
Bell Aliant BGP Community Values.
Bell Aliant will apply the same Best Common Practice BGP filtering on Private AS peers as Public AS peers (see section 1.5 Customer BGP Prefix Propagation) with one exception. Bell Aliant will only reject small prefixes with a length of /30 - /32. This exception only applies when customers use Bell Aliant assigned IP Prefixes from an existing Bell Aliant aggregate. Bell Aliant will only advertise aggregate prefixes (/24 or smaller) to transit and other Bell Aliant BGP Peers.
Customers using 2 BGPs to Bell Aliant using a Private AS need to use extra caution in the BGP prefixes they accept from Bell Aliant. Bell Aliant will strip the Private AS from the AS Path when sending prefixes to eBGP peers. Because of this, Customers advertising prefixes out one peer will receive those same prefixes on the other. Since the Private AS was removed from the AS Path, BGP loop prevention will not automatically drop the prefixes. Customers should setup inbound filters to deny their own prefixes to ensure a loop free topology.
1.7 BGP Dampening
Bell Aliant does not dampen flapping BGP prefixes automatically. Bell Aliant does have tools implemented that will detect flapping BGP Peers and flapping prefixes. Should a peer or prefix flap excessively in a short period, Bell Aliant reserves to right to shutdown the BGP Peer or block the flapping prefix until the problem can be resolved. Customers will be contacted if this type of action is required.
Even though Bell Aliant will not automatically Dampen flapping BGP prefixes, many Transit Internet Carriers have this feature implemented. Flapping prefixes may therefore be Dampened automatically by any carrier on the Internet. During the dampening period, reachability to AS behind these transit carriers would be loss.
Customers are asked to ensure their BGP Peers and BGP prefix announcements remain stable in order to avoid being dampened.
1.8 BGP Peer Activation Procedure
Bell Aliant will only activate customer BGP peer configurations on its routers while both parties are on the phone. INOC representatives will coordinate a time to activate the peer. Should the peer not come up, it will be manually shutdown until the next attempt. Peer configs will not be left active and waiting to establish. Only stable BGP peer configs will remain activated.
