Hi Mrz,
Any chance to have support for SNMP BGP4-MIB in 6.x?
Thanks.
+1Hi Mrz,
Any chance to have support for SNMP BGP4-MIB in 6.x?
Thanks.
+1 in this list.....
Hi Mrz,
Any chance to have support for SNMP BGP4-MIB in 6.x?
Thanks.
We have several BGP speaking routers on our network:Anyone who have performance issues with BGP, please describe in details what setup you are running and detailed problem description:
+1 BGP4-MIBHi Mrz,
Any chance to have support for SNMP BGP4-MIB in 6.x?
Thanks.
If traffic flow is being improved, I would also request that fast path support isn't negated with its use.The origin-as keyword specifies that export statistics include the originating autonomous system for the source and destination.
The peer-as keyword specifies that export statistics include the peer autonomous system for the source and destination.
+1 for both of these. I have requested the Netflow v9 origin-as and peer-as features directly to Mikrotik support, they notified me that they will try and bring these to RouterOS v7 as it requires the new-routing engine.+1 BGP4-MIB
Also, adding the BGP AS source to netflow http://forum.mikrotik.com/viewtopic.php ... 3&p=438631
http://www.cisco.com/c/en/us/td/docs/io ... 82ECF20EDA
Cisco offers either peer or origin:
The origin-as keyword specifies that export statistics include the originating autonomous system for the source and destination.
The peer-as keyword specifies that export statistics include the peer autonomous system for the source and destination.
This is already possible:I already checked with support on the ability to use v7 as a pure route reflector and was happy to hear that functionality will be included.
/routing bgp peer print count-only
24
/ip route print count-only
1575550
/system resource> pr
uptime: 2w4d14h38m46s
version: 6.26
build-time: Feb/03/2015 15:18:36
free-memory: 2948.7MiB
total-memory: 3968.9MiB
cpu: tilegx
cpu-count: 36
cpu-frequency: 1200MHz
cpu-load: 4%
free-hdd-space: 903.2MiB
total-hdd-space: 1024.0MiB
architecture-name: tile
board-name: CCR1036-8G-2S+
platform: MikroTik
/routing filter print count-only
20
/routing bgp peer print count-only
27
/ip route print count-only
639431
/ipv6 route print count-only
26376
/routing ospf route print count-only
12530
/system resource print
uptime: 1d3h47m38s
version: 6.27
build-time: Feb/11/2015 13:24:13
free-memory: 2960.6MiB
total-memory: 3968.9MiB
cpu: tilegx
cpu-count: 36
cpu-frequency: 1200MHz
cpu-load: 40%
free-hdd-space: 906.0MiB
total-hdd-space: 1024.0MiB
architecture-name: tile
board-name: CCR1036-12G-4S
platform: MikroTik
/routing filter print count-only
78
I am talking about this: propagate BGP route updates without installing them in IP route tableThis is already possible:I already checked with support on the ability to use v7 as a pure route reflector and was happy to hear that functionality will be included.
- Create ip/vrf
- Create bgp/instance
- Assign bgp/instance to ip/vrf
- Create bgp/vrf
- Connect to peers and see their routes only in the VRF table you created above
- Success!
We have been running this in production for many years now. Or maybe you mean something else ?
OK. That would indeed be useful.I am talking about this: propagate BGP route updates without installing them in IP route table
This has been requested by me multiple times, as well as advertised-routes & routes, and working from instances within a VRF. Mikrotik support have responded that these features will be in RouterOS v7Apart from features already requested, it would be very useful if Mikrotik had a real Cisco-like "neigh x.x.x.x received-routes" command. Currently it is only possible to see routes after filters.
/system resource print
uptime: 5w4d16h26m42s
version: 6.20
build-time: Oct/01/2014 10:06:12
free-memory: 2507.2MiB
total-memory: 3969.2MiB
cpu: tilegx
cpu-count: 36
cpu-frequency: 1200MHz
cpu-load: 14%
free-hdd-space: 895.7MiB
total-hdd-space: 1024.0MiB
architecture-name: tile
board-name: CCR1036-12G-4S
platform: MikroTik
/routing bgp peer print count-only
39
/ip route print count-only
604178
/ipv6 route print count-only
53576
/routing ospf route print count-only
53
/routing filter print count-only
173
If I remember correctly from the presentation about v7, the way routing (at least some parts of it) is implemented in Linux makes it impossible to take advantage of multiple cores without redesigning and reimplementing it from the scratch and that's just too much work.Anyway to Bind more cores to the routing processes?
Currently see only core dealing with this... would like to see more CPU for this.
->Please add RPKI supportBefore v7 is released we would like to optimize v6 routing.
Anyone who have performance issues with BGP, please describe in details what setup you are running and detailed problem description:
* how many peers;
* how many routes in routing table;
* is there also OSPF,MPLS, VPLS, RIP etc running on the router;
* what are the hardware specs;
* are there routing filters;
* average BGP update rate from upstream peers;
* average amount of traffic forwarded over the router;
* are there frequent BGP bgp peer flaps,
* any other info that is relevant to routing and can be useful for optimization.
I talked to MikroTik about this at the USA MUM last week and they replied that although multi-core is off the table for right now, they have been able to significantly increase the performance of loading a single full table as well as using some indexing to accelerate the loading of subsequent tables.If I remember correctly from the presentation about v7, the way routing (at least some parts of it) is implemented in Linux makes it impossible to take advantage of multiple cores without redesigning and reimplementing it from the scratch and that's just too much work.Anyway to Bind more cores to the routing processes?
Currently see only core dealing with this... would like to see more CPU for this.
this topic is about optimization, new features will be in version 7Please add support for
huh... what is full view load time on cisco routers?..full table towards the CCR and 3-5 minute load times
No idea ... we don't use them. Juniper is generally much quickerhuh... what is full view load time on cisco routers?..
100% agree on these two points.Problems today are already well reported ... and MT support have acknowledged them time and again saying "no head room to fix" (basically eluding to all efforts going on ROS7)
OSPF with the random incorrect flag state on sessions causing reloads and drops
Lack of a full BGP community string matching capability (match a community exactly, but you can't filter based on one community in a list) (ie 8282:100,8282:101,8282:1010,3356:1044,3356:1012 and say export anything with 8282:101 - doesn't seem to work / let along saying export to these peers if 8282:1010 and 3356:1012 / etc)
This does not sound like it is related to BGP at all.Clearly, its a BGP problem that will be fixed in ROS v7? How long until we can test?
Also, is the amount of RAM important with running BGP? I was told it wasn't, then I seen in this thread that it is. We are using the CCR1036-12G-4S model, with 16Gb of RAM
It looks like one or two of the cores is being maxed out to 100% while all the rest are barely used at all. WHY isn't it spreading the processing power over all 36, rather than hammering one core for BGP???
Hi Mrz,
Any chance to have support for SNMP BGP4-MIB in 6.x?
Thanks.
Hi Mrz,
Any chance to have support for SNMP BGP4-MIB in 6.x?
Thanks.
You have to be kidding...There will be no new routing feature in ROS v6.
They have to draw a line in the sand somewhere.You have to be kidding...There will be no new routing feature in ROS v6.
This does not sound like it is related to BGP at all.Clearly, its a BGP problem that will be fixed in ROS v7? How long until we can test?
Also, is the amount of RAM important with running BGP? I was told it wasn't, then I seen in this thread that it is. We are using the CCR1036-12G-4S model, with 16Gb of RAM
It looks like one or two of the cores is being maxed out to 100% while all the rest are barely used at all. WHY isn't it spreading the processing power over all 36, rather than hammering one core for BGP???
IP forwarding is already spread across all cores on CCR's, for UDP everything is, for TCP it is spread on a session by session basis. If you have one or two cores maxing out when traffic increases, you must be doing something to the traffic that is no optimised for the Tilera architecture. Typically this is queueing or tunnelling.
What version of RouterOS are you running ?