BGP Basics & Technical Requirements
BGP Basics
BGP Basics
A router receives prefix announcements through eBGP, with your network either being multi-homed or peering to receive announcements for the same prefix from multiple sources. Among these, the router selects the optimal prefix announcement, which is then utilized for routing decisions.
The following criteria helps in the selection of the best prefix announcement:
- Each prefix needs (wants) only one single path
- Always the same decision, with the same parameters, making it deterministic
- Based on the attributes of the BGP announcement
The following example, based on the BGP routing algorithm as outlined in RFC 4271, illustrates how your network selects the appropriate prefix for routing decisions:
- Your router will check if next hop is reachable
- Your router chooses the route with the highest local preference
- Your router prefers the route with shortest AS path
- Your router prefers the route with the lowest origin attribute
- Your router prefers the route with the lowest MED Value
- Your router prefers the routes received from eBGP
- Your router prefers the routes learned from the router with lower router ID
- Your router prefers the routes learned from the router with lower IP address
- In terms of your internal routing protocol, your router prefers the nearest exit from the network
- Dependent on implementation : prefers more stable,(= older) routes
*Important rules are in bold while implementations are more vendor-specific
The router determines the next hop only after selecting the best path. The DE-CIX Academy Knowledge Card on BGP Routing is provided below. You can also download it here
Technical Requirement
DE-CIX India's Internet Exchange Routing Policy
I. General Provisions
This document contains the Technical Service Description (TSD) for the GlobePEER product. This TSD is part of the DE-CIX INTERWIRE contractual framework for domestic internet access.
This TSD shall apply only to the GlobePEER product. The GlobePEER product may, however, be a prerequisite for other DE-CIX INTERWIRE services. This document contains only technical specifications and documentation. Please consult the GlobePEER SLA for service levels.
This document may be revised and amended at any time pursuant to the provisions of the DE-CIX INTERWIRE INTERNET SERVICES PVT LTD (in the following called the DE-CIX INTERWIRE) Agreement.
The GlobePEER Product requires the following DE-CIX INTERWIRE products for its normal operation:
DE-CIX INTERWIRE Access (see Master SLA and DE-CIX INTERWIRE Technical Access Description (TAD) at any data center location that allows a local connection to the DE-CIX INTERWIRE GlobePEER region.
Member's use of the DE-CIX INTERWIRE network shall at all times conform to the relevant standards as laid out in STD0001 and associated Internet STD documents.
II. Data Link-layer configuration
The bandwidth of the GlobePEER product must be explicitly configured if the agreed bandwidth for GlobePEER differs from the bandwidth of the access or bundle of aggregated accesses, on which the GlobePEER product is used.
The following general policies shall apply:
Frame type (ether types) | Policy | Enforcement |
0x0800 – IPv4 | Allow | - |
All other types | Allow | Strict – all frames other than allowed types are dropped |
All frames forwarded to the GlobePEER service shall have the same source MAC address.
The following general policies shall apply:
Protocol | Policy | Enforcement | ||
Broadcast ARP (excluding proxy ARP), | Allowed, but rate limited - to 1000kbps | - | ||
All other types, i.e.including, but not limited to: | Discard | Discarded, unless specifically allowed |
III. IP Layer Configuration
Interface configuration
Parameter | Policy | Remarks | ||
IP addresses (IPv4, IPv6) including subnet mask for | IPv4 required | At least the IPv4 address has to be configured | ||
All other types | Allow | Strict – all frames other than allowed types are dropped | ||
IPv6 addresses (link-local & global scope) | No | All IPv6 addresses must be explicitly configured | ||
IPv6 address (site-local) | Not allowed | IPv6 site-local addresses must not be used | ||
Standard MTU | Fixed size | Standard IP MTU size must be explicitly set to |
The customer system’s routing configuration shall include the following policies/settings:
Parameter | Policy | Remarks | ||
BGP Version | v. 4 only | - | ||
AS numbers | Public only | No AS numbers allowed from ranges reserved for | ||
Multiple ASN | Allow | Members may use more than one ASN for their DE- | ||
Route advertising | Maximum aggregation | All routes advertised shall be aggregated as far as | ||
Route advertising – target IP | Advertising router only | All routes advertised across the DE-CIX India exchanges network | ||
Route advertising – registration | Public registration required | All routes to be advertised in a peering session across | ||
IP-address space advertising | With permission only | IP address space assigned to DE-CIX India peering | ||
DE-CIX India advertised routes | Accept | You can safely accept any routes announced by us, |
The DE-CIX India exchanges route server system consists of two servers running BGP. For normal operation, only one is needed
- 3.1 Minimum configuration
In order for the DE-CIX India measurements of the route server feature to function, at least one connection to one route server must be set up with the following parameters:
Parameter
Policy
Remarks
connection mode
Active
DE-CIX India side is configured as passive
BGP enforce-first-as
Not allowed
Enabled by default, must be disabled manually
AS-Set
Required
DE-CIX India needs the customer AS-Set to build
the filter rulesmartians/bogons
Will be discarded
- 3.2 BGP announcement validation
BGP announcement provided by the customer to the DE-CIX India route server is validated for security reasons. For the validation, route databases might be used (e.g. RADB).
- 3.3 Optional: communities
In addition to the one route server minimum configuration, the Customer may elect to control outgoing routing information directly on the DE-CIX India Internet Exchange's route server by joining communities. Communities are processed by the DE-CIX India Internet Exchange's route servers by the following set of filter rules:
- 0:peer-as - Prevent announcement of a prefix to a specific peer
- 59200:peer-as - Announce a prefix to a specific peer
- 0:59200 - Prevent announcement of a prefix to all peers
- 59200:59200 - Announce a prefix to all peers
BGP large communities are also supported (http://largebgpcommunities.net)
- 59200:0:peer-as - Prevent announcement of a prefix to a specific peer
- 59200:1:peer-as - Announce a prefix to a specific peer
- 59200:0:0 - Prevent announcement of a prefix to all peers
- 59200:1:0 - Announce a prefix to all peers
Customers are kindly asked to consult the location-specific documentation of existing communities, made available upon request.
Blackholing means diverting the flow of data to a different next hop (the “Blackhole”) where the traffic is discarded. The result is that no traffic reaches the original destination and hence hosts located within the "blackholed" prefix are protected from massive distributed denial of service (DDoS) attacks congesting the connection from the customer to DE-CIX India. Thus blackholing is an effective way of mitigating the effects of DDoS attacks, etc.
DE-CIX India provides the technical infrastructure to allow Blackholing to be set upped and used by customers. DE-CIX India, however, has no control in cases where a customer is accepting these “Blackholed” prefixes.
- 4.1 Basic principle
BGP announcement provided by the customer to the DE-CIX India route server is validated for security reasons. For the validation, route databases might be used (e.g. RADB).
- 4.4.1 In standard conditions
- Customers advertise their prefixes with a Next Hop IP address belonging to their AS
IPv4: /8 <= and <= /24
IPv6: /19 <= and <= /48
- 4.4.2 In case of DDoS
Customers advertise their prefixes with a unique DE-CIX India provided Blackhole next hop IP address (BN)
IPv4: /8 <= up to = /32 (if and only if the BN is set)
IPv6: /19 <= up to = /128 (if and only if the BN is set)
Further, the standard announcement checks still apply.
- 4.2 L2 filtering
Blackhole next hop (BN) has a unique MAC address (determined by ARP for the BN IP address) e.g. de:ad:be:ef:66:95
ARP resolving for the Blackhole IP next hop is currently served by a host operated DE-CIX India
All edge nodes have a static entry for the unique MAC address
Attack traffic is forwarded from the customer to the service with the static MAC address, traffic is denied.
- 4.3 Result
As a result, all traffic to the attacked and "blackholed" IP prefix is discarded already on the incoming switch, and hence victim's resources (e.g. connection form customer to DE-CIX India ) are protected.
Send us message
Peer with us today!
