BGP route back

Alexander Zubkov green at qrator.net
Mon Jan 21 20:15:55 CET 2019


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 at 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 at 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 at 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 at 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 at 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!



More information about the Bird-users mailing list