Not sure, but all you see in Winbox/SSH can be sent to a log server using Syslog.
See my post here: http://forum.mikrotik.com/t/bgp-logging-to-splunk/160088/1
After upgrading from 7.1.5 to 7.4.1, routing through the second provider stopped working.
providers:
- pppoe (distance 1)
2.dhcp (distance 2)
for the second route created with routing-table=MARK-ISP2
The detailed part of the configuration is attached.
All rules recreated the result is negative.
Replacing the distance in the interfaces of providers normally routes the second provider.
/interface ethernet
set [ find default-name=ether1 ] name=ETH1-ISP1
set [ find default-name=ether2 ] name=ETH2-ISP2
/interface pppoe-client
add add-default-route=yes allow=mschap1,mschap2 disabled=no interface=\
ETH1-ISP1 name=PPPoE-ISP1 user={login-isp1} password={password-isp1}
/interface list
add name=WAN
/interface list member
add interface=PPPoE-ISP1 list=WAN
add interface=ETH2-ISP2 list=WAN
/routing table
add fib name=MARK-ISP1
/ip route
add disabled=no distance=2 dst-address=0.0.0.0/0 gateway={ip-gateway-isp2} \
routing-table=MARK-ISP2
/ip dhcp-client
add default-route-distance=4 interface=ETH2-ISP2 script="/ip route set gat\
eway=\$\"gateway-address\" [/ip route find where routing-mark=\"MARK-ISP2\"\
]\r\
\n" use-peer-dns=no use-peer-ntp=no
/ip firewall address-list
add address=10.90.25.8 list=LAN-ISP1
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=!{static-ip-isp1} \
new-routing-mark=MARK-ISP2 passthrough=no src-address-list=LAN-ISP1
/ip firewall nat
add action=masquerade chain=srcnat src-address=10.90.25.0/24
Does anyone know how to remove dynamic Simple Queues? This used to be possible in RouterOS 6. I see someone else noted the issue in 7.4 already.
When trying to remove a dynamic simple queue you get the error: “Couldn’t remove Simple Queue <<pppoe-…>> - not permitted (9)”
Would really like a solution or workaround for this please?
I think you can not. However you can create a non-dynamic queue with higher priority (placed above). Queues are handled from top to bottom.
various 10g sfp’s still don’t work with ccr2004 & ccr2116
I don’t think MT will ever put much energy into making “various 10g sfp’s” work with all of their SFP+ devices. It’s simple: some work and some don’t, it’s by pure chance.
What you can do is to require full functionality when using MT’s own SFP+ modules. And you can carefully select 3rd party modules that work and hope no ROS upgrade breaks it. And if it does, complain hoping MT will fix the problem.
Or you can report (to MT support that is, forum members can’t help much) the modules you’d like to see working with much detail. Throw in knowledge and willingness to debug things if they ever try to get modules working.
Sometimes its possible to deduce/find the actual vendor of the module and that is usually a safer bet than anything else, other than an MT branded one.
( I only posted this because I dont like seeing MKXs name when I scan the Forum index 
)
till 7.23 all common sfp+ worked well.
even mikrotik’s own sfp+ DAC cable doesn’t work in ccr2116 & ccr2004 since ros 7.3 anymore. so that’s a serious issue.
I’m using 2x XS+DA0001 with my CCR2116 and both work flawless, no matter of the ROS version. No link-downs, 10G, no problems at all.
the original mikrotik cable Q+BC0003-S+ (40gb dac cable = 4 x 10g) doesn't work in ccr2116 & ccr2004 - just continous link flap on the switch side. on the mikrotik side the port always stays down.
sometimes one port comes randomly up and stays up, but this is not stable reproducable and broken by next reboot.
https://mikrotik.com/product/q_bc0003_s
also same for 10g sfp+ from fs.com, which is one of the leading suppliers for datacenter sfp's...
ask Mikrotik a test release about the fix.
They found the cause and testing the fix.
regards
Ros
Hi,
Some things.
/routing table
add fib name=MARK-ISP2
/ip dhcp-client
add default-route-distance=4 interface=ETH2-ISP2 script=“/ip route set gat
eway=$"gateway-address" [/ip route find where routing-mark="MARK-ISP2"
]\r
\n” use-peer-dns=no use-peer-ntp=no
routing-mark (in script=) → routing-table
Also, in 7.2.2 there was a significant (good, but largely un-noted) routing change.
If you apply a routing-mark to a packet, and there is a matching rule (routing-table/dst-address) in the route table.
It will unconditionally follow the rule.
You may need to
-Add additional routes to the MARK-ISP2 routing table.
-Or mark your packets more strictly
-Or go via routing rules.
Possible changes for Routing Rule version (Not tested):
/routing table
add fib name=RULE-ISP2
/ip firewall mangle
;** Change existing mangle for this one **
add action=mark-routing chain=prerouting dst-address=!{static-ip-isp1} \
new-routing-mark=RULE-ISP2 passthrough=no src-address-list=LAN-ISP1
/routing rule
add action=lookup disabled=no dst-address=10.90.25.0/24 table=main
add action=lookup disabled=no dst-address=0.0.0.0/0 routing-mark=RULE-ISP2 table=MARK-ISP2
another SNMP
have a running 7.4.1 → OK
tried to get LLDP data from switch attached to MT → OK
renamed interface on MT facing to switch
tried to get LLDP data from switch attached to MT → NOK
MT send old interface name on LLDP
after MT reboot, LLDP is OK with new lldpNeighborPortIdDescr
hAP ac2 upgraded from 7.2 to 7.4.1 without issue.
same in v7.5b
dear god, imagine production system where you need to reboot network equipment to change LLDP info
Imagine how often (if ever) admins change interface names in production systems.
ok, you are right
MT knows better
and you known better
rest of us who want to occasionally change ifName … well, we are all amateurs
after this comment, mr Znevna, i will (again) resign and left to You and other old forum members to find bugs for free
hope you and MT will make better world, and in next release you & MT will polish everything out
good luck & bye
It was just a reply to your “dear god” reply above that was a reply to your own previous post, take it with a little bit of salt.
I forgot to say about how often admins use ROS7 in production, I’m sorry.
If you found a serious bug, report it.
But please don’t go “oh dear god imagine this bug in production!!!111 muh interface name didn’t change in LLDP without a reboot!! oh lordy this is nasty” without expecting a salty comment.
PS: the bugs are reported here https://help.mikrotik.com/servicedesk/servicedesk/customer/user/login?destination=portals
mr Znevna.
it is my right to be salty
constant messing with dhcp, then ssh keys, lldp, missing sfp info and similar basic functionality …
it could be called v7 inhouse, or v7 lets-get-fun, or pre v7 or … anything but not “stable”
but one could expect that five (5) jumps from initial v7 release, we still have lack of basic things
and v7 is only option for new devices
from this point of view, i think it is minimum to be “salty”
and another problem
as i saw here to many times, forum veterans often try to explain others that feature which is missing is perfectly acceptabel
why ?
because one need BGP and he will make 106276272 post about BGP
other need wifi roaming and will make 5636523 post about it
and if someone pop in, and start to bark on basic thing, like “please i want to see what v6 address i got from SLAAC” …
well, this will delay beloved BGP requests or whatever else
we should to stay steady on ground and all of us to shout for same basics, first
but no, instead, everyone is individual, and think he is smarter
so, really, there is no much joy anymore in this forum
br. Peca
Is this LLDP bug something new in 7.4.1 or it was there in older versions too? or even in ROS6?
Or is it a SNMP bug? because you mentioned “SNMP”.