peering-toolbox:single_upstream_ixp
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
peering-toolbox:single_upstream_ixp [2022/08/17 16:38] – [Looking Glass] philip | peering-toolbox:single_upstream_ixp [2023/04/30 15:54] (current) – [Peering at an IXP] philip | ||
---|---|---|---|
Line 1: | Line 1: | ||
{{peering-toolbox/ | {{peering-toolbox/ | ||
- | ====== | + | ====== |
This section discusses how we scale multiple peerings with our network, using what is known as an Internet Exchange Point. | This section discusses how we scale multiple peerings with our network, using what is known as an Internet Exchange Point. | ||
Line 7: | Line 7: | ||
Internet Exchange Points are open neutral interconnects where network operators (with their own Internet resources) are able to freely interconnect. An IXP is the most efficient and effective way of scaling interconnections between network operators in any one location. | Internet Exchange Points are open neutral interconnects where network operators (with their own Internet resources) are able to freely interconnect. An IXP is the most efficient and effective way of scaling interconnections between network operators in any one location. | ||
- | Lots of information about IXPs is available from many locations, including the [[https:// | + | Lots of information about IXPs is available from many locations, including the [[https:// |
A diagram showing the typical physical layout of this scenario is shown below: | A diagram showing the typical physical layout of this scenario is shown below: | ||
- | {{: | + | {{ : |
- | ===== Participating | + | ===== Participating |
The section describes how to participate at an Internet Exchange Point. The description is high level as each and every IXP will have their own nuances, variations on the general theme. Discussion with the IXP operator is important to understand their requirements. | The section describes how to participate at an Internet Exchange Point. The description is high level as each and every IXP will have their own nuances, variations on the general theme. Discussion with the IXP operator is important to understand their requirements. | ||
- | We won't discuss why joining an IXP is important - the Value of Peering has already covered why peering is essential for a network operator' | + | We won't discuss why joining an IXP is important - the Value of Peering |
Nor will we discuss which IXP to join - there are many factors involved, but common advice is to join the "local IXP" as that will host network operators with similar common interest, content, and customers, and likely will give the best peering opportunities. | Nor will we discuss which IXP to join - there are many factors involved, but common advice is to join the "local IXP" as that will host network operators with similar common interest, content, and customers, and likely will give the best peering opportunities. | ||
Line 74: | Line 74: | ||
==== Bilateral Peering ==== | ==== Bilateral Peering ==== | ||
+ | |||
+ | (UPDATED CONTENT) | ||
The other type of peering at an IXP is known as Bilateral Peering, and is where one member sets up an EBGP session directly with the other member across the IXP fabric. This type of peering is used by network operators who implement a Selective peering policy. | The other type of peering at an IXP is known as Bilateral Peering, and is where one member sets up an EBGP session directly with the other member across the IXP fabric. This type of peering is used by network operators who implement a Selective peering policy. | ||
- | Establishing a peering with such an operator usually requires initiating contact with them first (via the IXP membership portal or via PeeringDB), agreeing on the peering and any other requirements that either operator may have. | + | Establishing a peering with such an operator usually requires initiating contact with them first (via the IXP membership portal or via PeeringDB), agreeing on the peering and any other requirements that either operator may have. Most IXP's membership portal is software developed by [[https:// |
+ | < | ||
+ | Dear [Network] Peering Team, | ||
+ | We are [Company Name & Website] and we are fellow members of [IXP]. | ||
+ | We would like to arrange peering session(s) with you on the following interface(s): | ||
+ | |||
+ | [IXP & Location] | ||
+ | ``` | ||
+ | Our AS Number: | ||
+ | Our IPv4 Address: | ||
+ | Our IPv4 AS Macro: | ||
+ | |||
+ | Our IPv6 Address: | ||
+ | Our IPv6 AS Macro: | ||
+ | |||
+ | We're on PeeringDB: https:// | ||
+ | |||
+ | NOC Details for [Network Name] | ||
+ | The following are our NOC details for your reference: | ||
+ | * NOC Hours: 24x7 | ||
+ | * NOC/ | ||
+ | * NOC/ | ||
+ | |||
+ | Kind regards, | ||
+ | |||
+ | </ | ||
+ | Even if there is no IXP Manager being used at the IX, the above form is still very useful as part of the peering request as it includes all the information needed to establish the peering (and should match the PeeringDB entry for the entity). | ||
Once this is done, establishing the EBGP session is no different from establishing EBGP with a private peer. The outbound policy is already known, and the inbound policy only needs to be a prefix filter allowing the prefixes that the other operator said they'd be announcing. Thereafter any updates to filters are done by exchange of emails or by whatever process the two peering operators have agreed upon. | Once this is done, establishing the EBGP session is no different from establishing EBGP with a private peer. The outbound policy is already known, and the inbound policy only needs to be a prefix filter allowing the prefixes that the other operator said they'd be announcing. Thereafter any updates to filters are done by exchange of emails or by whatever process the two peering operators have agreed upon. | ||
Line 83: | Line 111: | ||
==== Looking Glass ==== | ==== Looking Glass ==== | ||
- | Most IXPs offer a general service to members and the public called a Route Collector. A Route Collector collects routes from peers for use by a Looking Glass. | + | Most IXPs offer a general service |
A Route Collector is functionally identical to a Route Server but with one very important difference: it does **NOT** send any routes to its peers. | A Route Collector is functionally identical to a Route Server but with one very important difference: it does **NOT** send any routes to its peers. | ||
Line 93: | Line 121: | ||
Others IXPs keep the facility separate and will request their members to set up a bi-lateral peering with their IXP's Route Collector - in that sense the configuration is no different from any other bi-lateral peer, but there will be no routes received from the Route Collector itself. | Others IXPs keep the facility separate and will request their members to set up a bi-lateral peering with their IXP's Route Collector - in that sense the configuration is no different from any other bi-lateral peer, but there will be no routes received from the Route Collector itself. | ||
- | All IXP members are encouraged to peer with the Route Collector - it helps with awareness, promoting peerability (showing the available routes), and equally importantly, | + | All IXP members are encouraged to peer with the Route Collector - it helps with awareness, promoting peerability (showing the available routes |
The diagram below shows how a Route Collector may be connected to the IX, and with the Looking Glass website attached behind it. | The diagram below shows how a Route Collector may be connected to the IX, and with the Looking Glass website attached behind it. | ||
- | {{: | + | {{ : |
[[: | [[: |
peering-toolbox/single_upstream_ixp.1660718302.txt.gz · Last modified: 2022/08/17 16:38 by philip