peering-toolbox:single_upstream_private_peer
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
peering-toolbox:single_upstream_private_peer [2022/05/16 16:40] – [Deploying IBGP] 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# | - [[single_upstream_private_peer# | ||
+ | A diagram showing the typical physical layout of this scenario is shown below: | ||
+ | |||
+ | {{: | ||
===== Enabling the Peer ===== | ===== Enabling the Peer ===== | ||
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# |
- | 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 |
==== 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/ |
==== BGP Policy Configuration ==== | ==== BGP Policy Configuration ==== |
peering-toolbox/single_upstream_private_peer.1652683239.txt.gz · Last modified: 2022/05/16 16:40 by philip