Philip Smith's Internet Development Site

User Tools

Site Tools

Trace:
peering-toolbox:single_upstream_private_peer

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
peering-toolbox:single_upstream_private_peer [2022/05/13 07:29] – [ROA and Route Object] philippeering-toolbox:single_upstream_private_peer [2022/08/26 09:55] (current) – [ROA and Route Object] philip
Line 3: Line 3:
 ====== Single Upstream & Private Peer ====== ====== Single Upstream & Private Peer ======
  
-Most network operators first encounter with peering is when they have a simple connection to their upstream provider. This connection usually involves the operator having a static default route configured on the link to the upstream, with the upstream pointing a default route to their customer.+Most network operators first encounter with peering is when they have a simple connection to their upstream provider. This connection usually involves the operator having a static default route configured on the link to the upstream, with the upstream pointing a simple route to their customer.
  
 We will now look at how we go about adding a peering with another network. There are two possible cases here: We will now look at how we go about adding a peering with another network. There are two possible cases here:
Line 10: Line 10:
   - [[single_upstream_private_peer#bgp_with_upstream|Adding the peering, introducing BGP with the upstream]]   - [[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 ===== ===== Enabling the Peer =====
  
 ==== Deploying Address Space ==== ==== Deploying Address Space ====
  
-If we are not already using our own address space, then we need to consider first how to go about deploying it across our own network (and any customers we might have).+If the newcomer is not already using their own address space from when they first set up their service, then they need to consider first how to go about deploying it across their own network (and for any customers they might have).
  
-We already have obtained our own address space and ASN for the network. 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: +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 Letter of Authority (LOA) 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)   - Renumber the network (change dynamic pools, and use secondary addressing if needed)
   - Withdraw the old address space   - Withdraw the old address space
Line 29: Line 32:
 ==== Deploying IBGP ==== ==== 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 ==== ==== Deploying EBGP with Peer ====
Line 48: Line 51:
 ===== BGP with Upstream ===== ===== BGP with Upstream =====
  
-Here we go one step further. +Here we go one step further that we did in the previous section, by setting up EBGP with the upstream provider as well. This is preferred as it makes the network truly autonomous and globally visible too. 
  
-The address space still needs to be deployed, IBGP needs to be set up across the backbone, and EBGP needs to be set up with the peer. These three steps were described in the [[next-steps#enabling_the_peer|previous section]].+The address space still needs to be deployed, IBGP needs to be set up across the backbone, and EBGP needs to be set up with the peer. These three steps were described in the [[single_upstream_private_peer#enabling_the_peer|previous section]]. You need to do those first!
  
 Enabling EBGP with the upstream will now make the network operator's ASN visible to the global Internet. There are very distinct steps to enabling this. Enabling EBGP with the upstream will now make the network operator's ASN visible to the global Internet. There are very distinct steps to enabling this.
Line 60: Line 63:
 ==== Letter of Authority ==== ==== 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 ==== ==== 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 ===+==== BGP Policy Configuration ====
  
 Then you need to create two policy statements, one for incoming policy, the other for outgoing policy. The incoming policy statement will likely say that you'll only accept a default route. Most operators will either: Then you need to create two policy statements, one for incoming policy, the other for outgoing policy. The incoming policy statement will likely say that you'll only accept a default route. Most operators will either:
Line 86: Line 89:
  
 And during their maintenance window, they can remove the static route for your address space pointing to you. Note that when they do this, they will stop originating your address space from their AS. Which means that the announcement you make to them from your ASN will become globally visible. This change needs to be done once everyone is sure, and the upstream has confirmed, that all their upstreams and peers have updated BGP filters accordingly. It is best that this latter work is all carried out during a maintenance window, and preferably at least 24 to 48 hours after bringing up the EBGP session, to avoid unexpected outages. And during their maintenance window, they can remove the static route for your address space pointing to you. Note that when they do this, they will stop originating your address space from their AS. Which means that the announcement you make to them from your ASN will become globally visible. This change needs to be done once everyone is sure, and the upstream has confirmed, that all their upstreams and peers have updated BGP filters accordingly. It is best that this latter work is all carried out during a maintenance window, and preferably at least 24 to 48 hours after bringing up the EBGP session, to avoid unexpected outages.
 +
 +==== Clean up ====
 +
 +With EBGP running successfully with the upstream provider, and the address space visible globally (check on [[http://routeviews.org|RouteViews]] where multiple paths should be visible), we can now clean up.
 +
 +The Route Object and ROA created with the upstream provider's ASN can now be deleted, leaving on the ROA and Route Object with your own ASN. This should have no operational impact whatsoever.
 +
  
 [[:peering-toolbox/next-steps| Back to 'Establishing Peering' page]] [[:peering-toolbox/next-steps| Back to 'Establishing Peering' page]]
peering-toolbox/single_upstream_private_peer.1652426986.txt.gz · Last modified: by philip