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 <[email protected]> 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! > > > >
