Hello Bird users, Does anyone know if there is a way to announce a BGP route back to the router it was received from. I need to do this for the following scenario. Lets say there are two routers with 2 transit links on each with full view tables and Bird server as a route-reflector. There is a need to force traffic to a specific destination via one of the ISPs, so I match the route in the import filter and set a local pref on it. But that will only make the route server announce the route with a high local pref to a second router, where the desired transit isn't directly connected. So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path. Here is the import filter snippet (x.y.z.0/24 is a dest route, as-path 1234 is a directly connected ISP on router-1: if source = RTS_BGP && net = x.y.z.0/24 && bgp_path.first = 1234 then { bgp_local_pref = 150; accept; } I think that bird doesn't do that because the protocol matches on the peer and on the route. Thanks!
Hi, I do not completely understand your setup. You better show route tables from all the routers and what is announced in which direction.
So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
How this could happen? If you got this route on the route reflector from the first router, than it should have this route in the required direction. If it had this route to another transit link, it would announce this to the route reflector. There is no reason to propagate the routes back to the peer, because they are already there.I think you can do some tricks, but first we need to understand what do you want to achieve. On Fri, Jan 18, 2019 at 7:23 PM Roman Romanyak <roman.romanyak@gmail.com> wrote:
Hello Bird users,
Does anyone know if there is a way to announce a BGP route back to the router it was received from. I need to do this for the following scenario. Lets say there are two routers with 2 transit links on each with full view tables and Bird server as a route-reflector. There is a need to force traffic to a specific destination via one of the ISPs, so I match the route in the import filter and set a local pref on it. But that will only make the route server announce the route with a high local pref to a second router, where the desired transit isn't directly connected. So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
Here is the import filter snippet (x.y.z.0/24 is a dest route, as-path 1234 is a directly connected ISP on router-1:
if source = RTS_BGP && net = x.y.z.0/24 && bgp_path.first = 1234 then { bgp_local_pref = 150; accept; }
I think that bird doesn't do that because the protocol matches on the peer and on the route.
Thanks!
Alexander, thank you for your feedback. Here is a diagram: [ ISP1 ] [ ISP2 ] [ ISP3 ] [ ISP4 ] | | | | | | | | [ Router 1 ] [ Router 2 ] | | | | [ Layer 2 Switch ] | | [ Bird Route Server ] Router 1 and 2 do not peer directly. There is OSPF running, so all nodes learn a route to other nodes connected interfaces. Both routers peer to route-server and are route reflection clients. There is a route x.y.z.0/24 coming from from each ISP. Router 1 chooses ISP2 (because of as-path), what path Router 2 is choosing doesn't matter. I need to force traffic to x.y.z.0/24 via ISP1. In order to do that, I'm matching the route x.y.z.0/24 in the import filter on the route-server (maching a route itself and also ISP1 ASN in the path) and setting the local preference to 150. Then this route is re-advertised to Router 2, which will select it as best, because of iBGP and high local-preference. The route is not announced back to Router 1, because it came from there. An alternative way, to do that is to mach a route on Router 1, increase a local-pref there and that route will be leared by router 2 through the route-server. But I'd like to do that on route-server to use a centralized place for these kinds of things. Here is a show route output from a route server: bird> show route for x.y.z.0/24 all x.y.z.0/24 via 10.1.1.65 on em2 [edge_r1 18:25:09] * (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 111 888 333 999 BGP.next_hop: 1.1.1.1 BGP.med: 0 BGP.local_pref: 150 via 10.1.1.65 on em2 [edge_r1 2019-01-17] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 222 777 999 BGP.next_hop: 2.2.2.2 BGP.med: 0 BGP.local_pref: 100 via 10.1.1.66 on em2 [edge_r2 2019-01-16] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 333 666 999 BGP.next_hop: 3.3.3.3 BGP.med: 0 BGP.local_pref: 100 via 10.1.1.67 on em2 [edge_r2 2019-01-17] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 444 555 999 BGP.next_hop: 4.4.4.4 BGP.med: 0 BGP.local_pref: 100 bird> On Fri, Jan 18, 2019 at 2:17 PM Alexander Zubkov <green@qrator.net> wrote:
Hi,
I do not completely understand your setup. You better show route tables from all the routers and what is announced in which direction.
So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
How this could happen? If you got this route on the route reflector from the first router, than it should have this route in the required direction. If it had this route to another transit link, it would announce this to the route reflector. There is no reason to propagate the routes back to the peer, because they are already there.I think you can do some tricks, but first we need to understand what do you want to achieve.
On Fri, Jan 18, 2019 at 7:23 PM Roman Romanyak <roman.romanyak@gmail.com> wrote:
Hello Bird users,
Does anyone know if there is a way to announce a BGP route back to the
router it was received from.
I need to do this for the following scenario. Lets say there are two routers with 2 transit links on each with full view tables and Bird server as a route-reflector. There is a need to force traffic to a specific destination via one of the ISPs, so I match the route in the import filter and set a local pref on it. But that will only make the route server announce the route with a high local pref to a second router, where the desired transit isn't directly connected. So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
Here is the import filter snippet (x.y.z.0/24 is a dest route, as-path 1234 is a directly connected ISP on router-1:
if source = RTS_BGP && net = x.y.z.0/24 && bgp_path.first = 1234 then { bgp_local_pref = 150; accept; }
I think that bird doesn't do that because the protocol matches on the peer and on the route.
Thanks!
Hi, Thank you for a good description. But what's your problem there now? You receive x.y.z.0/24 from Router1 and send it to Router2. What do you want to achive and are missing? On Fri, Jan 18, 2019 at 9:13 PM Roman Romanyak <roman.romanyak@gmail.com> wrote:
Alexander, thank you for your feedback.
Here is a diagram:
[ ISP1 ] [ ISP2 ] [ ISP3 ] [ ISP4 ] | | | | | | | | [ Router 1 ] [ Router 2 ] | | | | [ Layer 2 Switch ] | | [ Bird Route Server ]
Router 1 and 2 do not peer directly. There is OSPF running, so all nodes learn a route to other nodes connected interfaces. Both routers peer to route-server and are route reflection clients.
There is a route x.y.z.0/24 coming from from each ISP. Router 1 chooses ISP2 (because of as-path), what path Router 2 is choosing doesn't matter.
I need to force traffic to x.y.z.0/24 via ISP1. In order to do that, I'm matching the route x.y.z.0/24 in the import filter on the route-server (maching a route itself and also ISP1 ASN in the path) and setting the local preference to 150. Then this route is re-advertised to Router 2, which will select it as best, because of iBGP and high local-preference. The route is not announced back to Router 1, because it came from there.
An alternative way, to do that is to mach a route on Router 1, increase a local-pref there and that route will be leared by router 2 through the route-server. But I'd like to do that on route-server to use a centralized place for these kinds of things.
Here is a show route output from a route server:
bird> show route for x.y.z.0/24 all x.y.z.0/24 via 10.1.1.65 on em2 [edge_r1 18:25:09] * (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 111 888 333 999 BGP.next_hop: 1.1.1.1 BGP.med: 0 BGP.local_pref: 150 via 10.1.1.65 on em2 [edge_r1 2019-01-17] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 222 777 999 BGP.next_hop: 2.2.2.2 BGP.med: 0 BGP.local_pref: 100 via 10.1.1.66 on em2 [edge_r2 2019-01-16] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 333 666 999 BGP.next_hop: 3.3.3.3 BGP.med: 0 BGP.local_pref: 100 via 10.1.1.67 on em2 [edge_r2 2019-01-17] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 444 555 999 BGP.next_hop: 4.4.4.4 BGP.med: 0 BGP.local_pref: 100
bird>
On Fri, Jan 18, 2019 at 2:17 PM Alexander Zubkov <green@qrator.net> wrote:
Hi,
I do not completely understand your setup. You better show route tables from all the routers and what is announced in which direction.
So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
How this could happen? If you got this route on the route reflector from the first router, than it should have this route in the required direction. If it had this route to another transit link, it would announce this to the route reflector. There is no reason to propagate the routes back to the peer, because they are already there.I think you can do some tricks, but first we need to understand what do you want to achieve.
On Fri, Jan 18, 2019 at 7:23 PM Roman Romanyak <roman.romanyak@gmail.com> wrote:
Hello Bird users,
Does anyone know if there is a way to announce a BGP route back to the router it was received from. I need to do this for the following scenario. Lets say there are two routers with 2 transit links on each with full view tables and Bird server as a route-reflector. There is a need to force traffic to a specific destination via one of the ISPs, so I match the route in the import filter and set a local pref on it. But that will only make the route server announce the route with a high local pref to a second router, where the desired transit isn't directly connected. So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
Here is the import filter snippet (x.y.z.0/24 is a dest route, as-path 1234 is a directly connected ISP on router-1:
if source = RTS_BGP && net = x.y.z.0/24 && bgp_path.first = 1234 then { bgp_local_pref = 150; accept; }
I think that bird doesn't do that because the protocol matches on the peer and on the route.
Thanks!
I'd like to do a route manipulation on the route server and send a route back also to router1 with a local pref via ISP1. On Sat, Jan 19, 2019 at 2:43 AM Alexander Zubkov <green@qrator.net> wrote:
Hi,
Thank you for a good description. But what's your problem there now? You receive x.y.z.0/24 from Router1 and send it to Router2. What do you want to achive and are missing?
On Fri, Jan 18, 2019 at 9:13 PM Roman Romanyak <roman.romanyak@gmail.com> wrote:
Alexander, thank you for your feedback.
Here is a diagram:
[ ISP1 ] [ ISP2 ] [ ISP3 ] [ ISP4
]
| | |
|
| | |
|
[ Router 1 ] [ Router 2 ] | | | | [ Layer 2 Switch ] | | [ Bird Route Server ]
Router 1 and 2 do not peer directly. There is OSPF running, so all nodes learn a route to other nodes connected interfaces. Both routers peer to route-server and are route reflection clients.
There is a route x.y.z.0/24 coming from from each ISP. Router 1 chooses ISP2 (because of as-path), what path Router 2 is choosing doesn't matter.
I need to force traffic to x.y.z.0/24 via ISP1. In order to do that, I'm matching the route x.y.z.0/24 in the import filter on the route-server (maching a route itself and also ISP1 ASN in the path) and setting the local preference to 150. Then this route is re-advertised to Router 2, which will select it as best, because of iBGP and high local-preference. The route is not announced back to Router 1, because it came from there.
An alternative way, to do that is to mach a route on Router 1, increase a local-pref there and that route will be leared by router 2 through the route-server. But I'd like to do that on route-server to use a centralized place for these kinds of things.
Here is a show route output from a route server:
bird> show route for x.y.z.0/24 all x.y.z.0/24 via 10.1.1.65 on em2 [edge_r1 18:25:09] * (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 111 888 333 999 BGP.next_hop: 1.1.1.1 BGP.med: 0 BGP.local_pref: 150 via 10.1.1.65 on em2 [edge_r1 2019-01-17] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 222 777 999 BGP.next_hop: 2.2.2.2 BGP.med: 0 BGP.local_pref: 100 via 10.1.1.66 on em2 [edge_r2 2019-01-16] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 333 666 999 BGP.next_hop: 3.3.3.3 BGP.med: 0 BGP.local_pref: 100 via 10.1.1.67 on em2 [edge_r2 2019-01-17] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 444 555 999 BGP.next_hop: 4.4.4.4 BGP.med: 0 BGP.local_pref: 100
bird>
On Fri, Jan 18, 2019 at 2:17 PM Alexander Zubkov <green@qrator.net> wrote:
Hi,
I do not completely understand your setup. You better show route tables from all the routers and what is announced in which direction.
So I get the desired effect on the second router, it will learn and
install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
How this could happen? If you got this route on the route reflector from the first router, than it should have this route in the required direction. If it had this route to another transit link, it would announce this to the route reflector. There is no reason to propagate the routes back to the peer, because they are already there.I think you can do some tricks, but first we need to understand what do you want to achieve.
On Fri, Jan 18, 2019 at 7:23 PM Roman Romanyak <
roman.romanyak@gmail.com> wrote:
Hello Bird users,
Does anyone know if there is a way to announce a BGP route back to
the router it was received from.
I need to do this for the following scenario. Lets say there are two routers with 2 transit links on each with full view tables and Bird server as a route-reflector. There is a need to force traffic to a specific destination via one of the ISPs, so I match the route in the import filter and set a local pref on it. But that will only make the route server announce the route with a high local pref to a second router, where the desired transit isn't directly connected. So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
Here is the import filter snippet (x.y.z.0/24 is a dest route, as-path 1234 is a directly connected ISP on router-1:
if source = RTS_BGP && net = x.y.z.0/24 && bgp_path.first = 1234 then { bgp_local_pref = 150; accept; }
I think that bird doesn't do that because the protocol matches on the peer and on the route.
Thanks!
But than it'll be replaced on the router1 and it will withdraw the announce, and so on... On Mon, Jan 21, 2019 at 7:38 PM Roman Romanyak <roman.romanyak@gmail.com> wrote:
I'd like to do a route manipulation on the route server and send a route back also to router1 with a local pref via ISP1.
On Sat, Jan 19, 2019 at 2:43 AM Alexander Zubkov <green@qrator.net> wrote:
Hi,
Thank you for a good description. But what's your problem there now? You receive x.y.z.0/24 from Router1 and send it to Router2. What do you want to achive and are missing?
On Fri, Jan 18, 2019 at 9:13 PM Roman Romanyak <roman.romanyak@gmail.com> wrote:
Alexander, thank you for your feedback.
Here is a diagram:
[ ISP1 ] [ ISP2 ] [ ISP3 ] [ ISP4 ] | | | | | | | | [ Router 1 ] [ Router 2 ] | | | | [ Layer 2 Switch ] | | [ Bird Route Server ]
Router 1 and 2 do not peer directly. There is OSPF running, so all nodes learn a route to other nodes connected interfaces. Both routers peer to route-server and are route reflection clients.
There is a route x.y.z.0/24 coming from from each ISP. Router 1 chooses ISP2 (because of as-path), what path Router 2 is choosing doesn't matter.
I need to force traffic to x.y.z.0/24 via ISP1. In order to do that, I'm matching the route x.y.z.0/24 in the import filter on the route-server (maching a route itself and also ISP1 ASN in the path) and setting the local preference to 150. Then this route is re-advertised to Router 2, which will select it as best, because of iBGP and high local-preference. The route is not announced back to Router 1, because it came from there.
An alternative way, to do that is to mach a route on Router 1, increase a local-pref there and that route will be leared by router 2 through the route-server. But I'd like to do that on route-server to use a centralized place for these kinds of things.
Here is a show route output from a route server:
bird> show route for x.y.z.0/24 all x.y.z.0/24 via 10.1.1.65 on em2 [edge_r1 18:25:09] * (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 111 888 333 999 BGP.next_hop: 1.1.1.1 BGP.med: 0 BGP.local_pref: 150 via 10.1.1.65 on em2 [edge_r1 2019-01-17] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 222 777 999 BGP.next_hop: 2.2.2.2 BGP.med: 0 BGP.local_pref: 100 via 10.1.1.66 on em2 [edge_r2 2019-01-16] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 333 666 999 BGP.next_hop: 3.3.3.3 BGP.med: 0 BGP.local_pref: 100 via 10.1.1.67 on em2 [edge_r2 2019-01-17] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 444 555 999 BGP.next_hop: 4.4.4.4 BGP.med: 0 BGP.local_pref: 100
bird>
On Fri, Jan 18, 2019 at 2:17 PM Alexander Zubkov <green@qrator.net> wrote:
Hi,
I do not completely understand your setup. You better show route tables from all the routers and what is announced in which direction.
So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
How this could happen? If you got this route on the route reflector from the first router, than it should have this route in the required direction. If it had this route to another transit link, it would announce this to the route reflector. There is no reason to propagate the routes back to the peer, because they are already there.I think you can do some tricks, but first we need to understand what do you want to achieve.
On Fri, Jan 18, 2019 at 7:23 PM Roman Romanyak <roman.romanyak@gmail.com> wrote:
Hello Bird users,
Does anyone know if there is a way to announce a BGP route back to the router it was received from. I need to do this for the following scenario. Lets say there are two routers with 2 transit links on each with full view tables and Bird server as a route-reflector. There is a need to force traffic to a specific destination via one of the ISPs, so I match the route in the import filter and set a local pref on it. But that will only make the route server announce the route with a high local pref to a second router, where the desired transit isn't directly connected. So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
Here is the import filter snippet (x.y.z.0/24 is a dest route, as-path 1234 is a directly connected ISP on router-1:
if source = RTS_BGP && net = x.y.z.0/24 && bgp_path.first = 1234 then { bgp_local_pref = 150; accept; }
I think that bird doesn't do that because the protocol matches on the peer and on the route.
Thanks!
Yep, you're right, Alexander. Thanks a lot for your feedback! - Roman. On Mon, Jan 21, 2019 at 2:16 PM Alexander Zubkov <green@qrator.net> wrote:
But than it'll be replaced on the router1 and it will withdraw the announce, and so on...
On Mon, Jan 21, 2019 at 7:38 PM Roman Romanyak <roman.romanyak@gmail.com> wrote:
I'd like to do a route manipulation on the route server and send a route
back also to router1 with a local pref via ISP1.
On Sat, Jan 19, 2019 at 2:43 AM Alexander Zubkov <green@qrator.net>
wrote:
Hi,
Thank you for a good description. But what's your problem there now? You receive x.y.z.0/24 from Router1 and send it to Router2. What do you want to achive and are missing?
On Fri, Jan 18, 2019 at 9:13 PM Roman Romanyak <
roman.romanyak@gmail.com> wrote:
Alexander, thank you for your feedback.
Here is a diagram:
[ ISP1 ] [ ISP2 ] [ ISP3 ] [
ISP4 ]
| | |
|
| | |
|
[ Router 1 ] [ Router 2 ] | | | | [ Layer 2 Switch ] | | [ Bird Route Server ]
Router 1 and 2 do not peer directly. There is OSPF running, so all nodes learn a route to other nodes connected interfaces. Both routers peer to route-server and are route reflection clients.
There is a route x.y.z.0/24 coming from from each ISP. Router 1 chooses ISP2 (because of as-path), what path Router 2 is choosing doesn't matter.
I need to force traffic to x.y.z.0/24 via ISP1. In order to do that, I'm matching the route x.y.z.0/24 in the import filter on the route-server (maching a route itself and also ISP1 ASN in the path) and setting the local preference to 150. Then this route is re-advertised to Router 2, which will select it as best, because of iBGP and high local-preference. The route is not announced back to Router 1, because it came from there.
An alternative way, to do that is to mach a route on Router 1, increase a local-pref there and that route will be leared by router 2 through the route-server. But I'd like to do that on route-server to use a centralized place for these kinds of things.
Here is a show route output from a route server:
bird> show route for x.y.z.0/24 all x.y.z.0/24 via 10.1.1.65 on em2 [edge_r1 18:25:09] * (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 111 888 333 999 BGP.next_hop: 1.1.1.1 BGP.med: 0 BGP.local_pref: 150 via 10.1.1.65 on em2 [edge_r1 2019-01-17] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 222 777 999 BGP.next_hop: 2.2.2.2 BGP.med: 0 BGP.local_pref: 100 via 10.1.1.66 on em2 [edge_r2 2019-01-16] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 333 666 999 BGP.next_hop: 3.3.3.3 BGP.med: 0 BGP.local_pref: 100 via 10.1.1.67 on em2 [edge_r2 2019-01-17] (100/11) [AS123i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 444 555 999 BGP.next_hop: 4.4.4.4 BGP.med: 0 BGP.local_pref: 100
bird>
On Fri, Jan 18, 2019 at 2:17 PM Alexander Zubkov <green@qrator.net> wrote:
Hi,
I do not completely understand your setup. You better show route tables from all the routers and what is announced in which direction.
So I get the desired effect on the second router, it will learn
and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
How this could happen? If you got this route on the route reflector from the first router, than it should have this route in the required direction. If it had this route to another transit link, it would announce this to the route reflector. There is no reason to propagate the routes back to the peer, because they are already there.I think you can do some tricks, but first we need to understand what do you want to achieve.
On Fri, Jan 18, 2019 at 7:23 PM Roman Romanyak <
roman.romanyak@gmail.com> wrote:
Hello Bird users,
Does anyone know if there is a way to announce a BGP route back to
the router it was received from.
I need to do this for the following scenario. Lets say there are two routers with 2 transit links on each with full view tables and Bird server as a route-reflector. There is a need to force traffic to a specific destination via one of the ISPs, so I match the route in the import filter and set a local pref on it. But that will only make the route server announce the route with a high local pref to a second router, where the desired transit isn't directly connected. So I get the desired effect on the second router, it will learn and install a route with high local pref. The first router where the desired transit link is connected by default selects another transit link because of the shorter as-path.
Here is the import filter snippet (x.y.z.0/24 is a dest route, as-path 1234 is a directly connected ISP on router-1:
if source = RTS_BGP && net = x.y.z.0/24 && bgp_path.first = 1234 then { bgp_local_pref = 150; accept; }
I think that bird doesn't do that because the protocol matches on the peer and on the route.
Thanks!
On Fri, Jan 18, 2019 at 01:14:47PM -0500, Roman Romanyak wrote:
Hello Bird users,
Does anyone know if there is a way to announce a BGP route back to the router it was received from. I need to do this for the following scenario.
Hi I recently thought about a setup where a route-reflector modifies routes and propagates modified routes to its clients. To avoid issue with announcing route back and with (like you noticed) and with withdrawing original route (like Alexander Zubkov noticed) there is a simple solution: Use two RIB routing tables on clients and two single-directional BGP sessions - first RIB table collects routes from EBGP peers and uses first BGP session to propagate that to route-reflector, then second BGP session is used to propagate all routes back from route-reflector to second table in clients, while second table is connected to kernel/FIB. Such setup could be done in BIRD, i am just wondering whether client part of such setup could be done with common L3 switches with BGP support. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Thank you for the advise, Ondrej. I've heard that some l3 switches do not support add-path feature in VRFs, but in this case I'm using routers, so this should work fine. - Roman. On Tue, Jan 22, 2019 at 9:38 AM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Jan 18, 2019 at 01:14:47PM -0500, Roman Romanyak wrote:
Hello Bird users,
Does anyone know if there is a way to announce a BGP route back to the router it was received from. I need to do this for the following scenario.
Hi
I recently thought about a setup where a route-reflector modifies routes and propagates modified routes to its clients. To avoid issue with announcing route back and with (like you noticed) and with withdrawing original route (like Alexander Zubkov noticed) there is a simple solution:
Use two RIB routing tables on clients and two single-directional BGP sessions - first RIB table collects routes from EBGP peers and uses first BGP session to propagate that to route-reflector, then second BGP session is used to propagate all routes back from route-reflector to second table in clients, while second table is connected to kernel/FIB.
Such setup could be done in BIRD, i am just wondering whether client part of such setup could be done with common L3 switches with BGP support.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (3)
-
Alexander Zubkov -
Ondrej Zajicek -
Roman Romanyak