Differences

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

--- peering-toolbox:single_upstream_private_peer [2022/05/16 16:39] – [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 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 ====