Community discussions

MikroTik App
 
dominicbatty
Member Candidate
Member Candidate
Topic Author
Posts: 100
Joined: Wed Jul 07, 2010 12:26 pm

Next Hop

Tue Jun 28, 2022 6:57 pm

Dear all,

I have a BGP concept type of question. We have two BGP sessions to one of our ISP's through "Interface-X" and we establish these to "BGP-Peer-A" and "BGP-Peer-B". In order to route to these peers before the BGP sessions come up, we have fixed routes in place to specifically route traffic to the IP addresses of these two BGP peer IP addresses through "Interface-X". The BGP peers will not change without our ISP pre-advising us so this is not a problem having a specific route to them.

What then happens is that both these peers provide us with a default BGP route where the next hop is to another router IP. This next hop for the default route is provided to us in the BGP message and BGP adds this default route to the routing table so comes in something like IP=0.0.0.0/0 > gateway=111.111.111.111. However, unless we also add the 1111.111.111.111 as a static route up "Interface-X", the default route will not work as it cannot find the next hop 111.111.111.111.

Is there some way to automatically add the BGP next hop received in the BGP default route message into the routing table as if the ISP ever changes the next hop from 111.111.111.111 to 222.222.222.222, which they are entitled to do, then my default routes will immediately fail as I won't have a static route in for 222.222.222.222.

Thanks in advance.
 
eduplant
Member Candidate
Member Candidate
Posts: 139
Joined: Tue Dec 19, 2017 9:45 am

Re: Next Hop

Thu Jun 30, 2022 10:52 pm

If the static route to the BGP peer address points to a next hop address, I believe you can continue chaining recursive resolution if you manipulate the scope and target-scope values for the static routes. So for example your static route to the BGP peer address can point to the far side of the local interface and then the next-hop on the default route can be statically routed to the BGP peer address. This way if you have any route to the BGP peer address you will also have a route to the BGP default next-hop address. If the default route next hop could change to be literally anything … then you’re essentially defining a static default in order to ensure you route towards them.

That said, all of this is very unusual. Can you not convince your ISP to run eBGP over the point-to-point interfaces between you and then have them do next-hop-self? That way the next hop for the default route points to a specific link out of your network and you don’t have to deal with recursive resolution or any surprises.

For example, if you accept any next-hop address for their routes, they theoretically could announce a next-hop of something you can’t reach, or worse, something you can only reach through another provider/link.
 
dominicbatty
Member Candidate
Member Candidate
Topic Author
Posts: 100
Joined: Wed Jul 07, 2010 12:26 pm

Re: Next Hop

Fri Jul 01, 2022 2:48 pm

Many thanks for the advice, this is very helpful.
 
dominicbatty
Member Candidate
Member Candidate
Topic Author
Posts: 100
Joined: Wed Jul 07, 2010 12:26 pm

Re: Next Hop

Mon Jul 04, 2022 3:42 pm

Just in case anyone else reads this, I thought I'd post an update in relation to my default route issue.

My BGP peers to ISP1 are accessed via a specific PPPoE interface for that ISP hence what I've managed to in the inbound routing filter for those BGP peers is ignore the next hop provided to me from that ISP's BGP peers and instead override the "Gateway" and "Immediate Gateway" in the inbound BGP route to the only known way to access that ISP. The routing then takes care of itself.

IP4 filter ... if (dst == 0.0.0.0/0) {set gw <ISP-1-interface>; set gw-interface <ISP-1-interface>; accept} else {reject}
IP6 filter ... if (dst == ::/0) {set gw <ISP1-interface>; set <ISP-1-interface>; accept} else {reject}

This seems to work a treat.

Cheers, Dominic.

Who is online

Users browsing this forum: No registered users and 19 guests