03-30-2017 10:17 AM - edited 03-05-2019 08:16 AM
I've been researching how to properly implement for a specific BGP scenario. In my research I may vary well have come across the bits a pieces that I need to accomplish this but have yet to simply find it presented in a way that clearly meets my needs.
My small shop has a router with two upstream BGP peers (full tables). We have a handful of routes that we originate and have prefix-lists in place to ensure that we're only advertising our network blocks, not re-advertising other blocks received from other upstream peers, etc...
Example:
ip prefix-list OUT description Prevent from becoming transitory ASN for eBGP neighbors
ip prefix-list OUT seq 5 permit 192.168.1.0/24
ip prefix-list OUT seq 6 permit 192.168.2.0/24
ip prefix-list OUT seq 7 permit 192.168.3.0/24
ip prefix-list OUT seq 8 permit 192.168.4.0/24
ip prefix-list OUT seq 9 permit 192.168.5.0/24
ip prefix-list OUT seq 40 deny 0.0.0.0/0 le 32
Soon we will have a customer that would like to use us as an upstream peer. We will provide them with a full table. This adds a bit more complexity to our simple filtering lists.
I'm attempting to determine best practices on how we would go about allowing our customers advertisements to pass to our upstreams knowing that the customer could be announcing to other providers. As a result we could be receiving that route from our upstream's as well.
In the event our peer with the customer goes down, I'd like our networks to reach that customers network via the alternative paths, but I want to make sure we do not have a situation where we're re-announcing our customers prefixes that are received from our upstreams should our peer with them go down (potentially creating a blackhole).
Would anyone be able to provide on insight or point me in the direction of documentation that reviews the best practices?
03-30-2017 10:39 AM
Hi
Please correct me if I understanding wrong, your router will be used as transit for the client side? I think you could use BGP regular expresions + AS path list to allow just traffic originated from specifics AS otherwise the performance of your device could be affected.
03-30-2017 04:02 PM
Yes, our router would be a transit for the customer.
What your suggesting is what I thought the right answer would be, but often times there are 10 different ways of doing something and 7 of them might not be a "good" way, which is why I was seeking a bit of real world guidance.
Assuming a filter-list was the right path, I then has other scenarios going through my head that I need to account for. For example: the customer prepending their AS for maintenance reasons, etc... What are some of the considerations when building the filter-list? Does anyone have some examples they can share?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide