雷竞技网站

Hi All,

I am trying to bring up a second BGP session on a new circuit to an existing
provider (with an existing BGP session). So, for example I have an established
session from my AS to Provider-1 over a 200 Mbps Metro-E circuit. I'm trying
to establish a second session from my AS to Provider-1 over a new 1 Gbps
Metro-E circuit. Both circuits have dedicated IP addresses for my end and theirs.

What is happening is that the second session will establish, then drop atfer 90 seconds
because the Hold Timer expired (that's the message in my log file). If I disable the first
session (/routing/bgp/peer set 0 disabled=yes) then the second session will come up,
and stay up.

How do I get both to stay up at the same time?

TIA, Reiney

Multiple peers to the same remote ASN shouldn't give any problems like this.
Did you configure this as a second BGP instance? If so, then you shouldn't do it that way, it should just be two peers for the same local BGP instance.

Another thing it could be....

Are your sessions using eBGP multihop, or are you peering with the remote IP on each directly-connected WAN link? If multihop, then make sure that the new peer's IP address is static-routed via link 2, and that link 1's peer is static routed via link 1.

I am having a similar issue.

CCR1072 rOS 6.37.4

昨天我试图打开第二个会话智慧h Zayo for IPv6. Full routes from them and one advertisement from me. Within 3 minutes my routing table is empty and the network is completely down. My OSPF instance is also affected. I get BGP Hold Timer Expired messages for all peering sessions. I get Full to Down messages for my OSPF neighbors.

I peer with 59 other endpoints, both IPv4 and IPv6 with no issue. I am taking FULL ROUTES for IPv4 and IPv6 from Hurricane Electric. I take FULL ROUTES for IPv4 from Zayo. As stated above, trying to get FULL ROUTES for IPv6 from Zayo too. I am advertising a single /48 IPv6 block.

My gut feeling is that this is either a bug or some sort of limitation in RouterOS. First thing that comes to mind is that there is a problem with populating the IPv6 routing table with full routes from more than two peers.

I wouldn't be surprised. Mikrotik has been working on a complete overhaul of the routing engine for ROSv7 (a mythical creature oft spoken of, yet never seen outside the land of Latvia) and the IPv6 features have been pretty stagnant for quite a while, except for certain bug fixes and a few enhancements. Does your IPv6 peering use link-local addressing or globally-unique (public) addressing?
I've seen some issues with link-local next hop in ROS's IPv6 BGP.

It could be something to do with CCR & 1 CPU Core for BGP .... I can tell you that is not an issue on the X86 or CHR platform...
We have multiple X86 based routers doing all kinds of BGP sessions v4 & v6 (multiple full tables etc etc) without any issues... different versions of ROS 6.32 to 6.37.4

Does your IPv6 peering use link-local addressing or globally-unique (public) addressing?
I've seen some issues with link-local next hop in ROS's IPv6 BGP.

Thanks for the reply. Both my interface to the exchange and interface to Zayo have global IPv6 addresses. I'm in a /64 at the exchange and /126 with Zayo.

It could be something to do with CCR & 1 CPU Core for BGP

I agree 100%

I'm going to be doing some early morning troubleshooting with Zayo to try and get the session up. I'm also hoping that there is just some sort of configuration issue upstream of me that is causing grief to the routing table when the session comes up.

If I can sort anything out I will update this.

Check with Zayo about their hold/keepalive timers.

When the timers are not the same on both ends, Mikrotik behaves unpredictably sometimes.

I actually had an issue like this with IPv4. Multiple peers within a router, one of them went down then up. Got a message about hold timer expired and the next thing I know is that even the OSPF adyacencies went down on this particular router, as if the routing process went down. Happened 3 times, with 6.37.4 I believe every single time was the same, then it just stopped happening.

As far I know the routing process is the same for both BGP and OSPF, and it's using a single core, if something makes it hang (be it due to an issue within BGP or OSPF) then all the routing goes down until it resets or "fix" itself.

Enviado desde mi SAMSUNG-SM-G920A mediante Tapatalk

Multiple peers to the same remote ASN shouldn't give any problems like this.
Did you configure this as a second BGP instance? If so, then you shouldn't do it that way, it should just be two peers for the same local BGP instance.

Another thing it could be....

Are your sessions using eBGP multihop, or are you peering with the remote IP on each directly-connected WAN link? If multihop, then make sure that the new peer's IP address is static-routed via link 2, and that link 1's peer is static routed via link 1.

Hi ZeroByte,

如果你可以,有什么问题与ha相关ving two seperate BGP instances one for IPv4 and one for IPv6? I ask because i am in the process of deploying IPv6.. yes i am late to the party.. for example i am already peering with transit provider X for IPv4 and the instance is Y. My iBGP for IPv4 all runs on instance Y... What are the risks in creating a new BGP instance B solely for IPv6 BGP. i have seen people argue that with some vendor equipment you cannot establish a second BGP peer due to the Router ID which can only be changed by another Instance. Sorry for cross-posting if i am, i do apologize, its just this discussion really fits in well with what i am currently working on...

I don't think it would be that much of a problem to run IPv4 in an instance and IPv6 in a different instance, since the two routing tables have nothing to do with each other anyway.
The problem with using different instances for different eBGP peers in the same protocol is that BGP won't be able to properly compare the paths with each other prior to choosing the best BGP route. Each instance would have one and only one route, all of which would be attempting to activate themselves in the RIB, and then you could only choose between them by setting different admin distances for each instance.

That's bad, mm-kay?

But since IPv6 routes don't have anything to do with IPv4 routes, it shouldn't be an issue (at least no issues come to my mind right now).

I don't think it would be that much of a problem to run IPv4 in an instance and IPv6 in a different instance, since the two routing tables have nothing to do with each other anyway.
The problem with using different instances for different eBGP peers in the same protocol is that BGP won't be able to properly compare the paths with each other prior to choosing the best BGP route. Each instance would have one and only one route, all of which would be attempting to activate themselves in the RIB, and then you could only choose between them by setting different admin distances for each instance.

That's bad, mm-kay?

But since IPv6 routes don't have anything to do with IPv4 routes, it shouldn't be an issue (at least no issues come to my mind right now).

Thanks, i get what you mean in the response above.. priceless info. I will start a new post with some of the challenges i have faced deploying IPv6 hopefully you may have some input as well as the other individuals that have successfully deployed IPv6 on this forum. Africa is obviously lagging behind in IPv6 deployment at the moment but with the help of you all should be a breeze hehe... thanks again ZeroByte.