Technical Requirements
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
We are here to assist you.
