Connecting India to the World
Connecting India to the World
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 PSSLA 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:
Members' 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.
The bandwidth of the GlobePEER product must be explicitly configured if the agreed bandwidth for GlobePEER differs from the bandwidth of the accessor 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 0x0806 – ARP 0x86dd – IPv6 |
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 policies shall apply to broadcast/multicast traffic
| Protocol | Policy | Enforcement |
|---|---|---|
| Broadcast ARP (excluding proxy ARP), multicast IPv6 Neighbor Discovery (ND) |
Allowed, but rate limited - to 1000kbps | - |
| All other types, i.e.including, but not limited to: - IRDP - ICMP redirects - IEEE802 Spanning Tree - Vendor proprietary discovery protocols (e.g. CDP) - Interior routing protocol broad/multicasts (e.g. OSPF, IS-IS, IGRP, EIGRP) - BOOTP/DHCP - PIM-SM - PIM-DM - DVMRP |
Discard | Discarded, unless specifically allowed |
Interface configuration
| Parameter | Policy | Remarks |
|---|---|---|
| IP addresses (IPv4, IPv6) including subnet mask for your interfaces |
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 auto-configuration | 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 1500 Bytes, unless explicitly agreed in writing. |
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 private use across the entire DE-CIX INTERWIRE network. |
| Multiple ASN | Allow | Members may use more than one ASN for their DE- CIX INTERWIRE peering, provided that each ASN presented shares the same NOC and peering contact details. |
| Route advertising | Maximum aggregation | All routes advertised shall be aggregated as far as possible. |
| Route advertising – target IP | Advertising router only | All routes advertised across the India-IX network must point to the router advertising it unless an agreement has been made in advance in writing by India-IX and the members involved. |
| Route advertising – registration | Public registration required | All routes to be advertised in a peering session across India-IX must be registered in the RIPE database or another public routing registry. |
| IP-address space advertising | With permission only | IP address space assigned to India-IX peering LAN shall not be advertised to other networks without explicit permission of India-IX. |
| India-IX advertised routes | Accept | You can safely accept any routes announced by us, as all incoming advertisements are filtered according to the configured policies. |
The India-IX route server system consists of two servers running BGP. For normal operation, only one is needed
In order for the India-IX 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 | India-IX side is configured as passive |
| bgp enforce-first-as | Not allowed | Enabled by default, must be disabled manually |
| AS-Set | Required | India-IX needs the customer AS-Set to build the filter rules |
| martians/bogons | Will be discarded |
BGP announcement provided by the customer to the India-IX route server is validated for security reasons. For the validation route databases might be used (e.g. RADB).
In addition to the one route server minimum configuration, the Customer may elect to control outgoing routing information directly on the India-IX route server by joining communities. Communities are processed by the India-IX route servers by the following set of filter rules:
| # | action | community | Local Preference |
|---|---|---|---|
| 1 | block announcement of a route to a certain peer |
0:<peer-as> | 50 |
| 2 | announcement of a route to a certain peer | <route-server-as>:<peer-as> | |
| 3 | block announcement of a route to all peers (monitoring the only session) |
0:<route-server-as>, no advertise, no-export | 0 |
| 4 | announcement of a route to all peers | <route-server-as>:<route-server-as> (default if nothing set) | 100 |
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 India-IX. Thus blackholing is an effective way of mitigating the effects of DDoS attacks, etc.
India-IX provides the technical infrastructure to allow Blackholing to be set upped and used by customers. India-IX, however, has no control in cases where a customer is accepting these “Blackholed” prefixes.
BGP announcement provided by the customer to the India-IX route server are validated for security reasons. For the validation route databases might be used (e.g. RADB).
Customers advertise their prefixes with a Next Hop IP address belonging to their AS
Customers advertise their prefixes with a unique India-IX-provided Blackhole next hop IP address (BN)
Further, the standard announcement checks still apply.
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 India-IX) are protected.