Adding a downstream ebgp connection. How to keep it separate?
Hello. I have two BGP routers with bird 2.4. Each router maintains some eBGP connections to upstreams where I announce my prefixes. These routers have an iBGP connection between themselves to exchange routes learned from those eBGP connections. I do some filtering on the eBGP connections (like setting local preference, as path prepending, setting an internal bgp community so that I know which routes originate from which eBGP connection, etc.) So far this is simple, works great for my own traffic/prefixes and have no trouble maintaining this. But now a need arose that I will be adding a downstream eBGP connection (customer). This means transiting a foreign prefix over my BGP routers and exporting some routes to it. How do I approach this the cleanest and simplest way possible? I suppose I should have two routing tables (currently under Linux/Bird everything is under the default routing/main table): - main table (keep for my own traffic) - customer table But I am unsure what to do with my existing upstream eBGP connections since I do some filtering on them for my own use cases. Should I have a separate Bird table for each upstream eBGP connection? Then use the pipe protocol to put the routes in the main and customer table separately? Then I could place the current filtering of eBGP connections that I use for myself in the pipe protocol that feeds my main table? The customer table will then be piped the raw routes from the eBGP connections. Is my thinking correct? Or this can be done better/differently? Are there perhaps any presentations and/or sample configs of such setups? I am sure this situation comes up quite often. Thanks!
Hi, I think you need to start with explaining why do you want to keep customer and upstream routes in separate tables. Regards, Alexander On Tue, Mar 19, 2024 at 1:39 PM LU <zyash911@gmail.com> wrote:
Hello.
I have two BGP routers with bird 2.4. Each router maintains some eBGP connections to upstreams where I announce my prefixes. These routers have an iBGP connection between themselves to exchange routes learned from those eBGP connections.
I do some filtering on the eBGP connections (like setting local preference, as path prepending, setting an internal bgp community so that I know which routes originate from which eBGP connection, etc.)
So far this is simple, works great for my own traffic/prefixes and have no trouble maintaining this.
But now a need arose that I will be adding a downstream eBGP connection (customer). This means transiting a foreign prefix over my BGP routers and exporting some routes to it.
How do I approach this the cleanest and simplest way possible?
I suppose I should have two routing tables (currently under Linux/Bird everything is under the default routing/main table):
- main table (keep for my own traffic) - customer table
But I am unsure what to do with my existing upstream eBGP connections since I do some filtering on them for my own use cases.
Should I have a separate Bird table for each upstream eBGP connection? Then use the pipe protocol to put the routes in the main and customer table separately?
Then I could place the current filtering of eBGP connections that I use for myself in the pipe protocol that feeds my main table?
The customer table will then be piped the raw routes from the eBGP connections.
Is my thinking correct? Or this can be done better/differently?
Are there perhaps any presentations and/or sample configs of such setups? I am sure this situation comes up quite often.
Thanks!
Hi. So, the Linux BGP routers perform packet forwarding. Up until this point they were handling only my own network/prefixes/traffic. Everything is using the default linux/bird main tables. I want to provide connectivity to the customer. I would announce his prefix to a select few of my upstream eBGP sessions and also export some of the upstream routes to him. So, at the very least I need a separate routing table (on linux) to have a different FIB for my own traffic and the customer's. But since I want to export some routes to the customer (and not just a default route) I need a way to be able to hand off him the raw upstream routes that I receive via eBGP. When I receive upstream routes I process them with filters (some get rejected, some I set a different local preference, etc. in the end they are modified to suit my use cases). So this is what I am asking: does it make sense to have a separate bird table per each upstream eBGP session so that I can keep the raw routes there, and eventually feed them via the pipe protocol to my own routing table for processing, and to the customer's table? Hope this makes sense. Thanks. wt., 19 mar 2024 o 23:34 Alexander Zubkov <green@qrator.net> napisał(a):
Hi,
I think you need to start with explaining why do you want to keep customer and upstream routes in separate tables.
Regards, Alexander
On Tue, Mar 19, 2024 at 1:39 PM LU <zyash911@gmail.com> wrote:
Hello.
I have two BGP routers with bird 2.4. Each router maintains some eBGP
connections to upstreams where I announce my prefixes. These routers have an iBGP connection between themselves to exchange routes learned from those eBGP connections.
I do some filtering on the eBGP connections (like setting local
preference, as path prepending, setting an internal bgp community so that I know which routes originate from which eBGP connection, etc.)
So far this is simple, works great for my own traffic/prefixes and have
no trouble maintaining this.
But now a need arose that I will be adding a downstream eBGP connection
(customer). This means transiting a foreign prefix over my BGP routers and exporting some routes to it.
How do I approach this the cleanest and simplest way possible?
I suppose I should have two routing tables (currently under Linux/Bird
everything is under the default routing/main table):
- main table (keep for my own traffic) - customer table
But I am unsure what to do with my existing upstream eBGP connections
since I do some filtering on them for my own use cases.
Should I have a separate Bird table for each upstream eBGP connection?
Then use the pipe protocol to put the routes in the main and customer table separately?
Then I could place the current filtering of eBGP connections that I use
for myself in the pipe protocol that feeds my main table?
The customer table will then be piped the raw routes from the eBGP
connections.
Is my thinking correct? Or this can be done better/differently?
Are there perhaps any presentations and/or sample configs of such
setups? I am sure this situation comes up quite often.
Thanks!
Or to keep the question short: Best way/practices to add a downstream eBGP session (to transit a prefix/traffic to a customer) so that it doesn't clash with my existing network on the same router(s). Thanks. śr., 20 mar 2024 o 00:10 LU <zyash911@gmail.com> napisał(a):
Hi.
So, the Linux BGP routers perform packet forwarding. Up until this point they were handling only my own network/prefixes/traffic. Everything is using the default linux/bird main tables.
I want to provide connectivity to the customer. I would announce his prefix to a select few of my upstream eBGP sessions and also export some of the upstream routes to him.
So, at the very least I need a separate routing table (on linux) to have a different FIB for my own traffic and the customer's.
But since I want to export some routes to the customer (and not just a default route) I need a way to be able to hand off him the raw upstream routes that I receive via eBGP. When I receive upstream routes I process them with filters (some get rejected, some I set a different local preference, etc. in the end they are modified to suit my use cases).
So this is what I am asking: does it make sense to have a separate bird table per each upstream eBGP session so that I can keep the raw routes there, and eventually feed them via the pipe protocol to my own routing table for processing, and to the customer's table?
Hope this makes sense.
Thanks.
wt., 19 mar 2024 o 23:34 Alexander Zubkov <green@qrator.net> napisał(a):
Hi,
I think you need to start with explaining why do you want to keep customer and upstream routes in separate tables.
Regards, Alexander
On Tue, Mar 19, 2024 at 1:39 PM LU <zyash911@gmail.com> wrote:
Hello.
I have two BGP routers with bird 2.4. Each router maintains some eBGP
connections to upstreams where I announce my prefixes. These routers have an iBGP connection between themselves to exchange routes learned from those eBGP connections.
I do some filtering on the eBGP connections (like setting local
preference, as path prepending, setting an internal bgp community so that I know which routes originate from which eBGP connection, etc.)
So far this is simple, works great for my own traffic/prefixes and have
no trouble maintaining this.
But now a need arose that I will be adding a downstream eBGP connection
(customer). This means transiting a foreign prefix over my BGP routers and exporting some routes to it.
How do I approach this the cleanest and simplest way possible?
I suppose I should have two routing tables (currently under Linux/Bird
everything is under the default routing/main table):
- main table (keep for my own traffic) - customer table
But I am unsure what to do with my existing upstream eBGP connections
since I do some filtering on them for my own use cases.
Should I have a separate Bird table for each upstream eBGP connection?
Then use the pipe protocol to put the routes in the main and customer table separately?
Then I could place the current filtering of eBGP connections that I use
for myself in the pipe protocol that feeds my main table?
The customer table will then be piped the raw routes from the eBGP
connections.
Is my thinking correct? Or this can be done better/differently?
Are there perhaps any presentations and/or sample configs of such
setups? I am sure this situation comes up quite often.
Thanks!
Hi, On Wed, Mar 20, 2024 at 12:22:52AM +0100, LU wrote:
Or to keep the question short: Best way/practices to add a downstream eBGP session (to transit a prefix/traffic to a customer) so that it doesn't clash with my existing network on the same router(s).
AS you stated here transit to customer, the question is, does your routing table (existing) consists of routing which interfere with the upstream? If not, it is simple to filter the routes also to the downstream/customer to reflect what you will give to him. If you rely here on only filtering or use bird tables with pipes to filter is something ... it depends on your requirements. I normally use bird peer tables and pipe from master with filters to had a table holding the customer view and also had the chance to filter directly to/from the customer. If the customer should follow a different routing policy as your own routing, then it is bit more complicate, but this is nothing i read on your messages.
Thanks.
HTH, tim -- Tim Weippert http://weiti.org - weiti@weiti.org GPG Fingerprint - E704 7303 6FF0 8393 ADB1 398E 67F2 94AE 5995 7DD8
participants (3)
-
Alexander Zubkov -
LU -
Tim Weippert