Services

Home > Services
peeringservices_01

PEERING SERVICES

Members can connect to SGIX using one or more physical connections and reach many other peers on the peering fabric, thus optimizing the cost per peer when exchanging traffic between different networks. Port size available are 1G, 10G and 100G for traffic exchange.

PEERING POLICY

Members can implement OPEN or SELECTIVE peering policy or a combination of both where different sets of prefixes are announced to OPEN and SELECTIVE peering group.

SELECTIVE Peering Policy
Also known as Bi-Lateral Peering (BLP) policy where member negotiate with other members in the Exchange to setup direct BGP peering according to their own requirements.

OPEN Peering Policy
Also known as Multi-Lateral Peering (MLP) policy. Instead of negotiating with individual member in the Exchange for direct BGP peering, member can setup a single BGP session with SGIX Route-Servers (RS1 & RS2) to announce and received prefixes from all other members with similar peering policy. Member can control their prefixes announcement to other members by tagging them with SGIX BGP communities. By default, SGIX Route-Servers will advertise your prefixes to all peers.

ROUTE SERVERS (RS)

SGIX operates two Route Servers (RS) in Singapore. Once peered with the RS, there is no need to maintain multiple BGP sessions with other members in the IX. RS provide AS-path, MED, Communities and Next-hop transparency so that peering at SGIX still appear to be directly connected. As a result, members traffic are exchanged directly within SGIX switching fabric without passing through RS.

Please note the following when peering with RS

  1. Remove any private ASN in the prefix announcement.
  2. Remove any IP v4v6 default route in the prefix announcement.
  3. Prefixes stated in RFC 1918 are not allowed
  4. Disable check on first-ASN. This may be applicable to Huawei (“undo check-first-as”) and Cisco equipment (“no bgp enforce-first-as”).
  5. The default BGP v4v6 max-prefix threshold is set to 100 but member can request for a different value during provisioning.

Conditions

  1. Members are advised to peer with both RS for redundancy.
  2. Members can choose to establish or maintain bi-lateral peering arrangement with other members.
  3. Members agree not to hold SGIX responsible for any impact on traffic flow due to policies request configured at RS by other members.

BGP Announcement Filtering
Besides the well-known community like NO_EXPORT and NO_ADVERTISE, members can control their prefixes announcement to other members by tagging them with BGP standard community or large community. By default, RS will advertised all prefixes to all peers.

The following table shows BGP standard and large communities in top-down evaluation order. These communities are processed by RS and not propagated to any peers.

Standard Community Descriptions
0:55518 Block announcement of prefixes to all ASN
0:$ASN Block announcement of prefixes to this ASN only
55518:$ASN Announce prefixes to this ASN only

 

Large Community Descriptions
55518:0:0 Block announcement of prefixes to all ASN
55518:0:$ASN* Block announcement of prefixes to this ASN only
55518:1:$ASN* Announce prefixes to this ASN only

*For members having 4-byte ASN,  you have to use for the BGP Large Communities.

AS PATH Prepending

The following table contains information about how to prepend your own ASN up to three times selectively to a certain ASN peer.

Standard Community Descriptions
65001:$ASN Prepend once to this ASN only
65002:$ASN Prepend twice to this ASN only
65003:$ASN Prepend thrice to this ASN only

 

Large Community Descriptions
55518:101:$ASN* Prepend once to this ASN only
55518:102:$ASN* Prepend twice to this ASN only
55518:103:$ASN* Prepend thrice to this ASN only

*For members having 4-byte ASN,  you have to use for the BGP Large Communities.

Connecting using a Routed Port

Connecting to SGIX using a routed port is the preferred design and below is the recommended port configuration (Cisco IOS). Member need to adapt this configuration to their respective platform when connecting to SGIX fabric.

GigabitEthernet X/X/X
  description Facing SGIX Port
  ip address <your_allocated_ipv4_address>
  ipv6 address <your_allocated_ipv6_address> 
  no cdp enable
  no mop enable
  no ip mask-reply
  no ip proxy-arp
  no ip redirects
  no ip directed-broadcast
  no ip unreachables
  no keepalive
  no lldp transmit
  no lldp receive
  no udld enable
  ipv6 nd ra suppress all
  ipv6 nd prefix default no-advertise

Connecting via an Intermediate Switch

The intermediate switch connecting both the customer router and SGIX MUST have a dedicated vlan with no other additional devices in that vlan. SGIX only allow two MAC addresses per port. Below is the recommended switch port configuration facing SGIX. If bpdufilter feature is not available in your platform, we recommend that member disable spanning-tree on the dedicated vlan.

vlan XXX
  name SGIX

GigabitEthernet X/X/X
  description Facing SGIX Port
  switchport mode access
  switchport access vlan XXX
  switchport nonegotiate
  spanning-tree bpdufilter enable
  no keepalive
  no cdp enable
  no lldp receive
  no lldp transmit
  no udld enable

Contact us

We here to help in anything you need. Call us on below number.

Download Our 2016
Financial Brochure
from here

Submit Now

blackhole-831x230-warp-2

About Blackholing Service

To mitigate DDoS attack, SGIX provide a blackhole next-hop address for both IPv4 and IPv6 address-families. These next-hop addresses will resolves (via ARP/ND) to a predefined blackhole MAC address (de:ad:be:ef:66:66), which will be dropped by our switch port ingress filter where members are directly connected and thereby preventing DDoS traffic from reaching its destination. SGIX blackholing (BH) service is available on our Route Servers (RS) and members are encouraged to participate.

Below table contain SGIX blackhole next-hop address and BGP BLACKHOLE community information.

IPv4 Address 103.16.102.6
IPv6 Global Address 2001:DE8:12:100::6
IPv6 Link-Local Address FE80::DEAD:BEEF:6666:6666
MAC Address de:ad:be:ef:66:66
BLACKHOLE Community (RFC7999) 65535:666

Blackholing via Route Server (RS)

Below are guideline and restrictions when using blackholing service via RS:

  • To participate in SGIX blackholing service, members MUST allow IP v4v6 prefixes marked with BLACKHOLE community (65535:666) through their inbound filter. This blackholing inbound filter should be place above any existing inbound policies that you have to ensure it will not be bypass.
# Create BLACKHOLE community (RFC7999)
ip community-list standard BLACKHOLE-COMM permit 65535:666

# IPv4 Inbound policy snippet
route-map SGIX-IPv4-IN permit 10  # create new blackhole policy
  match community BLACKHOLE-COMM  # match BLACKHOLE community
route-map SGIX-IPv4-IN permit 20  # existing inbound policy
  <existing inbound policies>     # existing match statement

# IPv6 Inbound policy snippet
route-map SGIX-IPv6-IN permit 10  # create new blackhole policy
  match community BLACKHOLE-COMM  # match BLACKHOLE community
route-map SGIX-IPv6-IN permit 20  # existing inbound policy
  <existing inbound policies>     # existing match statement

# BGP Inbound Policy snippet
router bgp <your_ASN>
....
  address-family ipv4
    neighbor 103.16.102.12 route-map SGIX-IPv4-IN in  # RS1 IPv4 inbound policies
    neighbor 103.16.102.13 route-map SGIX-IPv4-IN in  # RS2 IPv4 inbound policies
  exit-address-family
....
  address-family ipv6
    neighbor 2001:DE8:12:100::12 route-map SGIX-IPv6-IN in  # RS1 IPv6 inbound policies
    neighbor 2001:DE8:12:100::13 route-map SGIX-IPv6-IN in  # RS2 IPv6 inbound policies
  exit-address-family

 

  • To ensure member’s inbound filter are configured correctly, SGIX provide a permanent test IP v4v6 blackhole prefixes. Member will need to verify they can receive this test prefix with correct next-hop address and BGP communities in their routing table.
Test IP v4v6 Blackhole Prefix next-hop address BGP Communities
202.3.78.3/32 103.16.102.6 65535:666 no-export
2001:df0:214::3/128 2001:DE8:12:100::6 (Global)
FE80::DEAD:BEEF:6666:6666 (Link-Local)
65535:666 no-export
  • To signal an IP prefix for blackholing, marked the prefix with BLACKHOLE community (65535:666) before advertising to RS. RS will automatically rewrite this prefix’s next-hop address to SGIX blackhole next-hop address and append the NO_EXPORT community before announcing to the rest of RS clients.
# Create IP v4v6 static route for victim address
ip route X.X.X.X 255.255.255.255 <IPv4-next-hop-to-victim-address>
ipv6 route Y:Y:Y:Y::Y/128 <IPv6-next-hop-to-victim-address>

# Create IP v4v6 blackhole prefix-list for matching later
ip prefix-list RTBH-IPv4-LIST seq 5 permit X.X.X.X/32
ipv6 prefix-list RTBH-IPv6-LIST seq 5 permit Y:Y:Y:Y::Y/128

# IPv4 outbound policy snippet
route-map SGIX-IPv4-OUT permit 10              # create new blackhole policy
  match ip address prefix-list RTBH-IPv4-LIST  # match blackhole prefix-list
  set community 65535:666                      # set BLACKHOLE community
route-map SGIX-IPv4-OUT permit 20              # existing outbound policy
  <existing outbound policies>                 # existing match statement

# IPv6 outbound policy snippet
route-map SGIX-IPv6-OUT permit 10                # create new blackhole policy
  match ipv6 address prefix-list RTBH-IPv6-LIST  # match blackhole prefix-list
  set community 65535:666                        # set BLACKHOLE community
route-map SGIX-IPv6-OUT permit 20                # existing outbound policy
  <existing outbound policies>                   # existing match statement

# BGP configuration snippet
router bgp <your_ASN>
  address-family ipv4
    network X.X.X.X mask 255.255.255.255                # Advertise IPv4 blackhole prefix
    neighbor 103.16.102.12 route-map SGIX-IPv4-OUT out  # RS1 IPv4 outbound policy
    neighbor 103.16.102.13 route-map SGIX-IPv4-OUT out  # RS2 IPv4 outbound policy
  exit-address-family

  address-family ipv6
    network Y:Y:Y:Y::Y/128                                    # Advertise IPv6 blackhole prefix
    neighbor 2001:DE8:12:100::12 route-map SGIX-IPv6-OUT out  # RS1 IPv6 outbound policy
    neighbor 2001:DE8:12:100::13 route-map SGIX-IPv6-OUT out  # RS2 IPv6 outbound policy
  exit-address-family

 

  • Members MUST enable send-community for both BGP v4v6 address-family.
  • RS only allowed blackhole IP prefixes from below size:

/24 =< IPv4 prefix length =< /32
/64 =< IPv6 prefix length =< /128

  • Members can only advertise blackhole IP prefixes from their own address space.
  • Blackhole IP prefixes should not be advertise outside their local AS.
  • The maximum number of blackhole IP prefixes that can be advertised is limited by:

(blackhole + standard prefix) < max-prefix

  • Members can target blackhole IP prefixes to specific ASN by combining it with SGIX standard community and large community filtering (the default is announced to all ASN).
Standard Community Descriptions
0:55518 Block announcement of prefixes to all ASN
0:$ASN Block announcement of prefixes to this ASN only
55518:$ASN Announce prefixes to this ASN only

 

Large Community Descriptions
55518:0:0 Block announcement of prefixes to all ASN
55518:0:$ASN* Block announcement of prefixes to this ASN only
55518:1:$ASN* Announce prefixes to this ASN only
*Please note that ASN is a four byte AS number you have to use for the BGP Large Communities.


# Example 1
route-map SGIX-IPv4-OUT permit 10
  match ip address prefix-list RTBH-IPv4-LIST  # match IPv4 blackhole prefix-list
  set community 65535:666 0:1234 0:5678        # blackhole to all except ASN 1234 and 5678

# Example 2
route-map SGIX-IPv4-OUT permit 10
  match ip address prefix-list RTBH-IPv4-LIST    # match IPv4 blackhole prefix-list
  set community 65535:666 55518:1234 55518:5678  # blackhole to only ASN 1234 and 5678

Blackholing via Direct Peering

Below are some guideline and restrictions for blackholing via direct peering:

  • Members MUST enable send-community for both BGP v4v6 address-family.
  • Use of RFC7999 BLACKHOLE community for prefix marking and matching is optional but recommended.
  • Members must allow IP prefixes marked with blackhole community (either RFC7999 or custom community) through their inbound filter.
  • Blackhole IP prefix should include NO_EXPORT community to prevent it from leaking outside the local AS.
  • To signal an IP prefix for blackholing, manually set the respective address-family next-hop to SGIX blackhole next-hop address together with NO_EXPORT community before advertising to direct peer. For IPv6 address-family, both Global + Link-Local addresses MUST be included in the next-hop information.
# Create IP v4v6 static route for victim address
ip route X.X.X.X 255.255.255.255 <IPv4-next-hop-to-victim-address>
ipv6 route Y:Y:Y:Y::Y/128 <IPv6-next-hop-to-victim-address>

# Create IP v4v6 blackhole prefix-list for matching later
ip prefix-list RTBH-IPv4-LIST seq 5 permit X.X.X.X/32
ipv6 prefix-list RTBH-IPv6-LIST seq 5 permit Y:Y:Y:Y::Y/128

# IPv4 outbound policy snippet
route-map SGIX-IPv4-OUT permit 10               # create new blackhole policy
  match ip address prefix-list RTBH-IPv4-LIST   # match blackhole prefix-list
  set community 65535:666 no-export             # set BLACKHOLE & no-export community
  set ip next-hop 103.16.102.6                  # set SGIX blackhole next-hop address
route-map SGIX-IPv4-OUT permit 20               # existing outbound policy
  <existing outbound policies>                  # existing match statement

# IPv6 outbound policy snippet
route-map SGIX-IPv6-OUT permit 10                # create new blackhole policy
  match ipv6 address prefix-list RTBH-IPv6-LIST  # match blackhole prefix-list
  set community 65535:666 no-export              # set BLACKHOLE & no-export community
  set ipv6 next-hop 2001:DE8:12:100::6 FE80::DEAD:BEEF:6666:6666  # set SGIX blackhole next-hop address
route-map SGIX-IPv6-OUT permit 20                # existing outbound policy
  <existing outbound policies>                   # existing match statement

# BGP configuration snippet
router bgp <your_ASN>
  address-family ipv4
    network X.X.X.X mask 255.255.255.255                   # Advertise IPv4 blackhole prefix
    neighbor <peer_ipv4_addr> route-map SGIX-IPv4-OUT out  # Direct peer outbound policy
  exit-address-family

  address-family ipv6
    network Y:Y:Y:Y::Y/128                                 # Advertise IPv6 blackhole prefix
    neighbor <peer_ipv6_addr> route-map SGIX-IPv6-OUT out  # Direct peer outbound policy
  exit-address-family

INFRASTRUCTURE

SGIX operates a distributed peering network across major data centres in Singapore.

  • 1-Net East
  • BDx SIN1
  • Digital Realty Singapore SIN10 / SIN11 / SIN12
  • Epsilon Global Hubs Singapore
  • Equinix SG1 / SG2 / SG3 / SG5
  • Global Switch (Tai Seng)
  • Keppel Data Centre Singapore 1
  • Racks Central
  • Singtel DC West
  • STT Tai Seng 1
  • Telin-3 Data Centre

As SGIX operates a single VLAN, both IPv4 and IPv6 peering will take place in the same VLAN.

All switch ports are access/untagged port and permit only two MAC addresses per port by default. BPDU packets are being filtered and broadcast storm control implemented.

Only IPv4 (0x0800), IPv6 (0x86dd) and ARP (0x0806) packets are permitted. All vendor proprietary protocols (CDP, EDP, FDP, MNDP, LLDP, VTP, DTP, L2 Keepalive, BOOTP/DHCP), IGP routing protocols (RIP, OSPF, IS-IS, IGRP, EIGRP) and Multicast routing protocols (IGMP, PIM, MLD, DVMRP) are not allowed.

Port Price

 

Port Size NRC/OTC MRC in SGD MRC in USD
(Indicative)
Media Type
1G *Fee applies 120 95 1x 1G-LX over SMF
10G None 500 390 1x 10G-LR over SMF
20G None 900 700 2x 10G-LR over SMF
30G None 1300 1010 3x 10G-LR over SMF
40G None 1700 1325 4x 10G-LR over SMF
100G None 2900 2255 1x 100G-LR4 over SMF
200G None 5400 4195 2x 100G-LR4 over SMF
300G None 7700 5985 3x 100G-LR4 over SMF
400G None 9800 7615 4x 100G-LR4 over SMF
  • Port price exclude cross-connect.
  • Price exclude GST.

* Refer to Port Application Form

 

SERVICE LEVEL

Singapore Internet Exchange offers a monthly service level of 99.9% on peering port availability.

On fault escalation matters, please email SGIX’s 24×7 helpdesk at noc@sgix.sg for immediate assistance.

For more information on Service Level and Fault Escalation procedures, please view the document below:

ServiceLevelAgreementForm_Btn

TRAFFIC STATISTICS

Weekly Graph

Monthly Graph

Yearly Graph