We found this new hardware, but unfortunately on the 3v1 hardware branch you can’t ping a host on ether2 and ether3 with 65535 bytes packet size. Seems that everything you made using this branch is worse than ever and you only can ping lowering to 44600 bytes packet size. Anyone else can confirm that? Please, its a pain knowing such a hardware bug!
edit
Ah, looks like you people couldn’t correctly implement IP175D chip.. Oh my, all my 433AH UAH suddenly become 411AH since can’t make better use of this chip! Also, note that IP175C is working great… I wonder why it was replaced… sigh Ive tested with most of all ROS versions up to 4.6 edit
Yes, we tested with most of all ROS versions up to 4.6. Im afraid that it is a hardware bug, not really a software implementation error. I think about it cuz that announced IP175D fix on ROS 4.2 However, when you put the chip working as switch, traffic passing through it works perfectly… Only input/output traffic if affected. That instead, suggest a software bug.
or maybe a limitation of the chip, did u try it with IP175C ? i know that the ether1 is connected directly to the RGMII (Reduced Gigabit Media Independent Interface) of the CPU (AR7130 in rb433) and (AR7161 in rb433xxx) and the ogher RGMII to the switch the speed is 100Mbps 'cause the phy is @ that speed
Not yet, Ive posted to see if anyone notice this behavior. But seems that people don’t know or don’t care about it maybe. To me it become a major problem since I couldn’t get my VPLS to work good yet.. Im testing all this on lab atm to qualify such a hardware for that.
Icant find anything about MTU of the IP175D, thats weird in the page www.icplus.com.tw doesnt say anything, I know that the atheros’s switch chip doesnt have that problem, the AR8316, AR8216, but the gigabit chip doenst support jumbo packet as the motorola (freescales chips)
I really don’t know how this problem affects traffic at all. BWTest indicates 36 mbits on both directions, but the fact is that on ICMP you can’t ping with 65535 bytes packet size. Now on routerboards using IP175C there is no problem. Besides, I still unable to implement MPLS VPLS on segments using this chip… things just don’t work and BWTest connects but show zero throughput. MPLS VPLS on IP175C is working fine as expected.
In short, this may or may not represent a problem. Depending on the scenario that routerboard may become unusable where is was not before some implementation. I really hope it can be fixed by software by MT, otherwise its just a waste…
Thats interesting! Well, MT support managed to reproduce the problem with IP175D and they are working on a fix for it. Im looking forward to it… hopefully we will have it solved by software soon enough. What a pain would be re-soldering dozens of devices.
Maybe this is the same problem that happens with RB493AH.
Let’s see where is my DIR-300
Please, Mikrotik Team, we are waiting for a software solution.
ROS 4.7 doesn’t solve the problem!
Latest Routerboard firmware embedded with ROS 4.7 doesn’t solve the problem!
Seems that we have no progress on this problem so far. So, in order to not wait MT to solve this, we may starting using switches on ether1. So, ether2 and ether3 are unusable for BGP based VPLS MPLS, unfortunately.
edit: No lucky for me… RB493AH have IP178C
We just found problems with IP175D, not C. Thats a surprise u have problems with C chip for 493.
I have the same problem. I have two RB433 and two RB433AH here on my table, all of them have IP175D chip. When I connect via winbox (MAC) to ether1, it works fine. But when I connect to ether2 or ether3, I’m not able to change anything in winbox. Windows IP/Addresses and Bridge/Ports does not show anything and Add button (the red cross) is disabled. Sometimes aftew some time (one minute) it appears, but still changing any value in winbox does not affect the board. And winbox window does not close immediately, it stays for a few second (frozen) and then closes.
Ping on ether1 works fine, on ether2 and ether3 the packet size cannot exceed 50k, otherwise it does not return.
Other devices using IP175C chip work absolutely fine.
Testing via Bandwidth test (on two RB433AH):
connected ether1 - ether1: UDP 97Mbit/97Mbit, TCP 56Mbit/56Mbit
connected ether2 - ether2: UDP 40Mbit/40Mbit, TCP 56Mbit/56Mbit
Plus when I assign an IP address to an interface (or bridge all ports and assign it to the bridge) and then I connect via winbox using IP address, it works fine - I mean I can change all values, no problem.
This problem is caused by additional feature of IP175D switch chip that supports up to 200Mbps speed between CPU and switch, while IP175C only up to 100Mbps. Currently we do not see any benefit form ability to forward 65535-Byte IP packets as all packets exceeding MTU of the interface will get fragmented anyway (44 additional IP fragments for 65535-Byte IP packet when MTU=1500). Why do you need support for such large packets?
To kirshteins: I myself do not need such a large packets. But what about the connection to ether2 and ether3 via winbox using MAC? Is that a feature too?
Well, MT support managed to reproduce the problem with IP175D and they are working on a fix for it. Im looking forward to it… hopefully we will have it solved by software soon enough. What a pain would be re-soldering dozens of devices. 
