Differences

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

--- peering-toolbox:single_upstream_private_peer [2022/05/16 16:37] – [Deploying Address Space] philip
+++ peering-toolbox:single_upstream_private_peer [2022/08/26 19:55] (current) – [ROA and Route Object] philip
@@ Line 10: / Line 10: @@
   - [[single_upstream_private_peer#bgp_with_upstream|Adding the peering, introducing BGP with the upstream]]
+A diagram showing the typical physical layout of this scenario is shown below:
+{{:peering-toolbox:1-private-peer.png?400| }}
 ===== Enabling the Peer =====
@@ Line 17: / Line 20: @@
 The newcomer will already have obtained their own address space and ASN for the network from the RIR. As noted elsewhere, most upstream providers forbid the use of their address space for connecting with any other operator. Renumbering a network is beyond the scope of the Toolbox, but there are many published documents and guides on how to do this. At a high level, the steps are:
-  - Create a Route Object for your address space using your upstream provider's ASN
+  - Create a Route Object for the address space using the upstream provider's ASN
-  - Create another Route Object for your address space using your own ASN
+  - Create another Route Object for the address space using the acquired ASN
-  - Create a ROA for your address space using your upstream provider's ASN
+  - Create a ROA for the address space using the upstream provider's ASN
-  - Create another ROA for your address space using your own ASN
+  - Create another ROA for the address space using the acquired ASN
-  - Provide a [[single_upstream#letter_of_authority|Letter of Authority]] to your upstream provider requesting their peers and transits accept and propagate your address space (some providers request this, so it is good to be prepared)
+  - Provide a [[single_upstream#letter_of_authority|Letter of Authority]] to the upstream provider requesting their peers and transits accept and propagate the address space (some providers request this, so it is good to be prepared)
-  - Organise with the upstream (transit provider) for the address space to be announced globally and routed to you
+  - Organise with the upstream (transit provider) for the address space to be announced globally and routed back
   - Renumber the network (change dynamic pools, and use secondary addressing if needed)
   - Withdraw the old address space
@@ Line 29: / Line 32: @@
 ==== Deploying IBGP ====
-Once our own address space is in use for the network, BGP needs to deployed internally (IBGP) across the network (at least for the devices in the core and border of the network). If the network is just of a single router, no IBGP is needed.
+Once the newcomer's own address space is in use for the network, BGP needs to deployed internally (IBGP) across the network (at least for the devices in the core and border of the network). If the network consists of just a single router, no IBGP is needed.
-There are many online guides on how to deploy IBGP so will not be covered here. The assumption is that an interior routing protocol like OSPF or ISIS is already operating - if it is not, then this will also need to be deployed before IBGP can be deployed. The AS number that BGP requires is the one already obtained from the Regional Internet Registry.
+There are many online guides on how to deploy IBGP so the process will not be covered here. The assumption is that an interior routing protocol like OSPF or ISIS is already operating - if it is not, then this will also need to be deployed before IBGP can be deployed. The AS number that BGP requires is the one already obtained from the Regional Internet Registry.
 ==== Deploying EBGP with Peer ====
@@ Line 60: / Line 63: @@
 ==== Letter of Authority ====
-The next step is to provide them with a Letter of Authority (if required) which requests their upstreams and peers to allow your address space originated by your ASN.
+The next step is to provide them with a [[single_upstream#letter_of_authority|Letter of Authority]] (if required) which requests their upstreams and peers to allow your address space originated by your ASN.
-LOAs are not usually required as a ROA should be enough to prove the holder of the address space and the origin ASN. But some operators insist on the LOA, still.
+LOAs are not usually required as a ROA is enough to prove the holder of the address space and the origin ASN. But some operators still insist on a LOA.
 ==== ROA and Route Object ====
-Confirm that the ROA (and Route Object) with your ASN as the origin of your address space is still present in your RIR's database. Note that if you are migrating from a static set up, do **NOT** delete the existing ROA (or Route Object) that declares their ASN as the origin - you still need it for now.
+Confirm that the [[peering-toolbox/route_origin_authorisation|ROA]] (and [[peering-toolbox/the_internet_routing_registry#route_object|Route Object]]) with your ASN as the origin of your address space is still present in your RIR's database. Note that if you are migrating from a static set up, do **NOT** delete the existing ROA (or Route Object) that declares their ASN as the origin - you still need it for now.
 ==== BGP Policy Configuration ====