We are trying to make our new CCR 1036 with two peers load a full table but after some secounds it stops.. the CPU goes to 100% on one core and after.. a secound or two it goes down to 0% and it loads only 4.000-10.000 prefix.

It has now been online for 17h and has still only got 40.000prefix.

What have we done wrong?

The peers are running quagga.

//Markus

What ros are you using? Its working well in my ccr and 6.4

Assuming this is not another CCR bug, it sounds like you have a slow BGP peer on your hands. This is not unique to RouterOS and can be caused by one of several things:

1. TCP communication issues
2. Missing information in BGP updates that requires resending
3. Intentional due to router policy - usually to keep CPU down.

If you trigger this behavior, it can take several days to get a full table unless you turn down the peering and attempt to reestablish. However, this doesn't always correct the issue and you may have to contact the administrator of the AS.

What ros are you using? Its working well in my ccr and 6.4

we are useing 6.4

Assuming this is not another CCR bug, it sounds like you have a slow BGP peer on your hands. This is not unique to RouterOS and can be caused by one of several things:

1. TCP communication issues
2. Missing information in BGP updates that requires resending
3. Intentional due to router policy - usually to keep CPU down.

If you trigger this behavior, it can take several days to get a full table unless you turn down the peering and attempt to reestablish. However, this doesn't always correct the issue and you may have to contact the administrator of the AS.

Someone who got any experience of quagga software with MT?

Assuming this is not another CCR bug, it sounds like you have a slow BGP peer on your hands. This is not unique to RouterOS and can be caused by one of several things:

1. TCP communication issues
2. Missing information in BGP updates that requires resending
3. Intentional due to router policy - usually to keep CPU down.

If you trigger this behavior, it can take several days to get a full table unless you turn down the peering and attempt to reestablish. However, this doesn't always correct the issue and you may have to contact the administrator of the AS.

Someone who got any experience of quagga software with MT?

Can it be MTU problem?

Hello,

Can it be MTU problem?

Half and half or also called 50% I think but only at the time, because the load of the full BGP table is
a very heavy and intensive act for the CPU! So the memory is in my eyes not really the hard effected
but more the CPU and it should be better to use a multi core CPU, but at this time the CCR series is
not using all cores from the Tile Gx platform and this is the real bottleneck.

So I suggest to wait until the ROS version of the Tilera platform is using them all and ROS is finished.

So at a bigger x_86 machine it is done in minutes to load it really.

@Kreacher:

Lots of other CCRs run several full feeds without a problem, so what we see is here os not a general ROS problem but rather must have something to do with specific configuration parameters or network issues between the involved devices.

@Kreacher:

Lots of other CCRs run several full feeds without a problem, so what we see is here os not a general ROS problem but rather must have something to do with specific configuration parameters or network issues between the involved devices.

If a Cisco router does the job in several minutes and then this router will be changed against a MikroTik CCR-1036-xx
and the BGP full table will not be loaded after several hours, it can be pointed to the following things:
- configuration false
- less RAM or NAND
- or plain that the CCR is not using all of his multicore capabilities
And in my eyes that is more related to the stage of coding from the ROS version for CCR,
I´ll see what is going on if the ROS version for the Tilera platform is ready and done, final without bugs and issues!

We are trying to make our new CCR 1036 with two peers load a full table but after some secounds it stops.. the CPU goes to 100% on one core and after.. a secound or two it goes down to 0% and it loads only 4.000-10.000 prefix.

So I really think it is going very rapidly after the CCR is using something like 16 core at the WNA interfaces and the
rest of 20 cores for the entire ROS system!!! Let us have a look for it.

We are trying to make our new CCR 1036 with two peers load a full table but after some secounds it stops.. the CPU goes to 100% on one core and after.. a secound or two it goes down to 0% and it loads only 4.000-10.000 prefix.

It has now been online for 17h and has still only got 40.000prefix.

What have we done wrong?

The peers are running quagga.

//Markus

Contact support with attached supout file.

I´ll see what is going on if the ROS version for the Tilera platform is ready and done, final without bugs and issues!

As a software developer I can assure you there is no such thing as a bug / issue free software.

We have no issue with 20+ CCR and many full tables, including some peers that are quagga/vyatta based. Full table loads in under 20 seconds.

I'd point to an issue with your peer or some sort of link problem.