For my part I have 4x48P units at a customer site that have not exhibited this problem that we know which have been up well over 1y at this point, but also 3 of the 4 are really sparsely populated, so if there was a block of 8 stopped ports on a switch it is not impossible it is simply a block of 8 ...
I still haven't got around to this, but it's on the cards again. Before I resign myself to just using l2tpns on linux... Terry: Are you still using Mikrotik for this (have any of your bugs been squashed yet?) or have you moved elsewhere too? Are you doing any of this authenticated and accounted agai...
You're going to need to do something like change the weight on the announcement from whichever router presently is VRRP master to attract the traffic (or make the VRRP slave withdraw it's announcement), if you need traffic to flow in both directions across the same firewall. I should imagine this is...
Sorry, when I said reconfigure the vswitch - I did mean the port group. Shorthand thinking became shorthand writing - we don't use VMWare without port groups (does anyone?)
Pretty sure VMWare by default won't let guests transmit traffic for unknown (eg: not assigned by VMWare) MACs. You'll need to change the port security options on your dvswitch.
I remain astonished that Mikrotik are *still* pumping out more and more hardware revisions instead of making the kit they have work properly, but I guess otherwise they would have hardware guys sat around with nothing to do. The SFP+ unit would definitely be interesting and disruptive.. if you could...
I think perhaps I've been spending too long around switch vendors who count the packet on the way in and on the way out as part of the system total PPS.
rmichael , macgaiver is right: 24mil 64byte pps = =24mil*8*(64+ 14 (Ethernet header) + 4 (Ethernet trailer))/1000/1000 = 15,744Gbps this is full speed full duplex - the limit is the port speed basically. Eh? 16Gbps (or ~24mpps) throughput is only full bidirectional throughput for 8 ports (1gbps tra...
I suppose it's fortunate that because I started from a more complex environment to begin with - dual stack full table access routing - that I uncovered the flaws before we got too involved with MT. If I had spent time getting a certification, and had a pile of their kit, I would definitely be in the...
OSPFv3 just doesn't work, BGP has stale routes... They've been too busy devoting all their time to building the CCR which is great and all, but the adage "learn to walk before you try to run" springs to mind. It makes absolutely no difference to me how many packets I can push over a device...
When I've raised this with MT support they've just said that it'll be fixed in a 'future version' 'maybe in october' or similar. Not exactly the kind of response you'd hope for with a showstopper bug like this.
Pretty dire, but you get what you pay for I guess. I just wish they wouldn't advertise features that simply don't work - even when just setting up peering between two routerboards.
OOI, did you get anywhere with this? I've been trying to get them to fix ospfv3 for months (will not reliably maintain adjacency) and so far it's just not been a priority for them at all :/