Public
Child pages
  • BGP Route Servers

Versions Compared

Old Version 30

changes.mady.by.user Nishal Goburdhan

Saved on

compared with

New Version 31

changes.mady.by.user Nishal Goburdhan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

There are two BGP route servers on each peering LAN.  It is recommended to always peer with both BGP Route Servers at a location, as sessions to both servers ensure that there is no disruption to your routing should it be necessary to performance maintenance.

Note
titleBi-lateral peering is considered best practice !

While the Route Server service is made available as a convenience, it is strongly recommended that, in addition to any sessions you plan to establish with the BGP Route Servers, you still maintain direct bi-lateral peering sessions with peers that you feel are important to your network! BGP Route Servers should be used to pickup smaller peers only, and not as a replacement for your discrete peering policy!

INXASNHostnameTypeIPv4IPv6
JINX37700routeserver1.jinx.net.zaBIRD196.223.14.12001:43f8:1f0::1
routeserver2.jinx.net.zaBIRD196.223.14.22001:43f8:1f0::2
CINX37701routeserver1.cinx.net.zaBIRD196.223.22.12001:43f8:1f1::1
routeserver2.cinx.net.zaBIRD196.223.22.22001:43f8:1f1::2
DINX37699routeserver1.dinx.net.zaBIRD196.223.30.12001:43f8:1f2::1
routeserver2.dinx.net.zaBIRD196.223.30.22001:43f8:1f2::2

BGP Communities for policy control

A simple set of BGP communities are made available for rudimentary policy control.  These will be expanded on, as the BGP Route Server service is improved. 

 

Tip
titleBGP next-as
Ensure that if you do plan on peering with the BGP Route Servers, that you implement "no bgp enforce-next-as" (or similar) for your platform.

 

BGP Communities for policy control

A simple set of BGP communities are made available for rudimentary policy control.  These will be expanded on, as the BGP Route Server service is improved. 

Tip
titleAS-Path Stripping

The BGP route servers do not add their own ASN in the advertised path, so if you're constructing filtering, do not use the BGP route servers ASN!

CommunityActionExplanation
37700:65281add no-exportadds the well known no-export community to all routes sent to peers
37700:65282add no-advertiseadds the well known no-advertise community to all routes sent to peers
0:peer-asdeny to peer-asblock announcement of route to peer-as
0:37700block allblock announcement of route to all peers
37700:peer-asallow to peer-asannounce prefix to specific peer-as (in conjunction with block all)
37700:37700allow allannounce prefix to all peers (implicit default)
Info
titleRemember to use the correct ASN
Note: The above communities example applies to peers using the JINX route servers. The appropriate ASN for each INX, should be substituted when using the BGP route servers, at other INXes.

Prefixes filtered by the Route Server service

For the overall safety and security of our participants, we actively filter the following prefixes at the Route Servers.  That is, advertisements from peers, containing the following networks, will be stripped, and not onward announced.

IPv4 prefixes filtered by the Route Servers (RFC6890)
martians = [ 
 10.0.0.0/8+,
 100.64.0.0/10+,
 127.0.0.0/8+,
 169.254.0.0/16+, 
 172.16.0.0/12+, 
 192.0.0.0/24,
 192.0.2.0/24,
 192.168.0.0/16+,
 198.18.0.0/24,
 198.51.100.0/24,
 203.0.113.0/24,
 224.0.0.0/4+, 
 240.0.0.0/4+, 
 0.0.0.0/32-, 
 0.0.0.0/0{25,32}, 
 0.0.0.0/0{0,7} 
 ];

 

 

Table of Contents

IPv6 prefixes filtered by the Route Servers
  martians = [ 
    0000::/8{8,128},        # loopback, unspecified, v4-mapped
    0064:ff9b::/96{96,128}, # IPv4-IPv6 Translat. [RFC6052]
    0100::/8{8,128},        # reserved for Discard-Only Address Block [RFC6666]
    0200::/7{7,128},        # Reserved by IETF [RFC4048]
    0400::/6{6,128},        # Reserved by IETF [RFC4291]
    0800::/5{5,128},        # Reserved by IETF [RFC4291]
    1000::/4{4,128},        # Reserved by IETF [RFC4291]
    2001::/32{33,128},      # Teredo prefix [RFC4380]
    2001:0002::/48{48,128}, # Benchmarking [RFC5180]
    2001:0003::/32{32,128}, # Automatic Multicast Tunneling [RFC7450]
    2001:10::/28{28,128},   # Deprecated ORCHID [RFC4843]
    2001:20::/28{28,128},   # ORCHIDv2 [RFC7343]
    2001:db8::/32{32,128},  # documentation purpose [RFC3849]
    2002::/16{17,128},      # 6to4 prefix [RFC3068]
    3ffe::/16{16,128},      # used for the 6bone but was returned [RFC5156]
    4000::/3{3,128},        # Reserved by IETF [RFC4291]
    5f00::/8{8,128},        # used for the 6bone but was returned [RFC5156]
    6000::/3{3,128},        # Reserved by IETF [RFC4291]
    8000::/3{3,128},        # Reserved by IETF [RFC4291]
    a000::/3{3,128},        # Reserved by IETF [RFC4291]
    c000::/3{3,128},        # Reserved by IETF [RFC4291]
    e000::/4{4,128},        # Reserved by IETF [RFC4291]
    f000::/5{5,128},        # Reserved by IETF [RFC4291]
    f800::/6{6,128},        # Reserved by IETF [RFC4291]
    fc00::/7{7,128},        # Unique Local Unicast [RFC4193]
    fe80::/10{10,128},      # Link Local Unicast [RFC4291]
    fec0::/10{10,128},      # Reserved by IETF [RFC3879]
    ff00::/8{8,128}         # Multicast [RFC4291]
  ];