Differences

This shows you the differences between two versions of the page.

--- peering-toolbox:single_upstream_two_private_peer [2022/05/14 16:44] – created philip
+++ peering-toolbox:single_upstream_two_private_peer [2022/08/26 19:56] (current) – [Route Object & ROAs] philip
@@ Line 5: / Line 5: @@
 This section discusses the next stage which is commonly encountered after a network operator establishes their first ever peering connection: another party is interested in peering as well, because they see the benefits that can be gained.
-To add the second peering, we build on what we learned in the previous section.
+To add the second peering, we build on what we learned in the previous section, noting that we have already deployed our address space, set up IBGP, created Route Objects and ROAs, and created policies for our EBGP sessions.
+A diagram showing the typical physical layout of this scenario is shown below:
+{{:peering-toolbox:2-private-peers.png?400|}}
 ===== Enabling the second Peer =====
@@ Line 23: / Line 26: @@
 ==== Filtering ====
-As the name suggests, the peering is private. Which means only you see your peers prefixes; and they only see your prefixes. Because your prefix filter only allows your prefixes out, and their prefixes in, nothing else connected to your network (upstream or other private peer) will be able to see their prefixes, or access their network through you. This demonstrates the importance of always implementing prefix filters, inbound and outbound on EBGP sessions. [[https://www.rfc-editor.org/rfc/rfc8212.html|RFC8212]] discuss default router behaviour, noting the recommendation that no EBGP session should be established with out filters in place.
+As the name suggests, the peering is private. Which means only you see your peers prefixes; and they only see your prefixes. Because your prefix filter only allows your prefixes out, and their prefixes in, nothing else connected to your network (upstream or other private peer) will be able to see their prefixes, or access their network through you. This demonstrates the importance of always implementing prefix filters, inbound and outbound on EBGP sessions.
+[[https://www.rfc-editor.org/rfc/rfc8212.html|RFC8212]] discuss default router behaviour, noting the recommendation that no EBGP session should be established with out filters in place.
+And [[https://www.manrs.org/isps/|MANRS]] first action is to "Prevent propagation of incorrect routing information", and our inbound and outbound filters applied on the peerings ensure that only the correct prefixes are exchanged over the EBGP sessions.
 ==== Route Object & ROAs ====
-No change is needed in the Route Object in the IRR, or the ROAs created for the address space. Both indicate the ASN originating the prefix and this does not change when a new peering is established.
+No change is needed in the [[[[peering-toolbox/the_internet_routing_registry#route_object|Route Object]] in the IRR, or the [[peering-toolbox/route_origin_authorisation|ROA]]s created for the address space. Both indicate the ASN originating the prefix and this does not change when a new peering is established.
+==== Scaling ====
+Adding further private peerings can be done using the same process. However, when many of these peers are in the same location, it is more efficient to create what is known as an Internet Exchange Point, and this will be examined in the next section of the Peering Toolbox.
 [[:peering-toolbox/next-steps| Back to 'Establishing Peering' page]]