- Created by Graham Beneke, last modified by Nishal Goburdhan on 04 Aug, 2018
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 51 Next »
Bi-lateral peering is considered best practice !
While the BGP 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 quick/easy/additional peers only, and not as a replacement for your discrete peering policy!
In particular there are many peers that advertise only a subset of their prefixes to the BGP Route Server. Always aim for a bilateral session !
There are two BGP separate 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. The Route Servers do not peer with each other, so peering with only one server is an unnecessary risk.
BGP next-as
Ensure that if you do plan on peering with the BGP Route Servers, you understand that the BGP-RS does not attach its ASN to outbound BGP messages.
Please implement the IOS "no bgp enforce-next-as" (or IOS-XR "enforce-first-as disable"), or appropriate equivalent, for your platform.
| INX | ASN | Hostname | Type | IPv4 | IPv6 |
|---|---|---|---|---|---|
| JINX | 37700 | routeserver1.jinx.net.za | BIRD | 196.223.14.1 | 2001:43f8:1f0::1 |
| routeserver2.jinx.net.za | BIRD | 196.223.14.2 | 2001:43f8:1f0::2 | ||
| CINX | 37701 | routeserver1.cinx.net.za | BIRD | 196.223.22.1 | 2001:43f8:1f1::1 |
| routeserver2.cinx.net.za | BIRD | 196.223.22.2 | 2001:43f8:1f1::2 | ||
| DINX | 37699 | routeserver1.dinx.net.za | BIRD | 196.223.30.1 | 2001:43f8:1f2::1 |
| routeserver2.dinx.net.za | BIRD | 196.223.30.2 | 2001:43f8:1f2::2 |
Max-prefix
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.
Remember to use the correct ASN
| Community | Action | Explanation |
|---|---|---|
| 0:peer-asn | deny to peer-asn | block announcement of prefix to peer-as |
| 0:37700 | block all | block announcement of prefix to all peers |
| 37700:peer-asn | allow to peer-asn | announce prefix to specific peer-as (in conjunction with block all) |
| 37700:37700 | allow all | announce prefix to all peers (implicit default) |
We honour the well-known no-export and no-advertise communities as if they were sent to us as a regular peer. If you would specifically like us to propagate these, then please tag as below:
| 37700:65281 | add no-export | adds the well known no-export community to all routes sent to peers |
| 37700:65282 | add no-advertise | adds the well known no-advertise community to all routes sent to peers |
BGP Large Community Support for policy control
| Community | Action | Explanation |
|---|---|---|
| 37700:0:peer-asn | deny to peer-asn | block announcement of prefix to peer-asn |
| 37700:1:0 | block all | announce prefix to specific peer-as (in conjunction with block all) |
| 37700:0:peer-asn | allow to peer-as | block announcement of prefix to all peers |
| 37700:1:0 | allow all | announce prefix to all peers (implicit default) |
Individual network filtering
AS-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!
INX has always believed in filtering and we filter all client sessions to the BGP-RS service. We use a combination of IRR filters, more specifics. We encourage peers to keep their IRR objects accurate to help us to autogenerate these filters.
Prefixes auto-filtered by the Route Servers
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.
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}
];
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]
];
- No labels