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*

thats weird according to the specification of these chips the IP175D is better than the IP175C, I also see a variant IP175E, its seems the same as C

but did u check with 3.30 version ? maybe is a soft bug, to discard it, the driver of the switch chip

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.

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

As I said, IP175C is working great. Ive found this occasionally implementing MPLS VPLS... guess I will need at least 1526 L2MTU.

As I said, IP175C is working great. Ive found this occasionally implementing MPLS VPLS... guess I will need at least 1526 L2MTU.

ok, I got it, did u contact to mikrotik? sending email to support to confirm that?

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.

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...

No one can confirm it? Ive sent supouts... Ive said... Guess nobody even notice this bug! *sigh*

No one can confirm it? Ive sent supouts... Ive said... Guess nobody even notice this bug! *sigh*

if you can change it to IP175C/E u can confirm for sure that is a a bug,

now im going to test it with my rb433, on of it has a IP175E that I took it from Dlink DIR300 because a lighthing burned it.

no problem with RB433 with IP175E

this is the chip what I soldered

nice solder job!

nice solder job!

thanks

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!

edit: No lucky for me... RB493AH have IP178C

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?

Ive said to MT support that would be convenient (pretty useful in some cases) if this feature could be enabled/disabled as you wish via console. i.e.:

/system hardware set this-crazy-feature-enabled=no

Lets hope they think the same.
Ozelo

As stated above, today we concluded that UBNT devices are rendered useless when connecting to these IP175D chipset routerboards. It works, but DO NOT achieve more than 8mb when you connect an Rocket AP to it. Changed the UBNT device from ether2 to ether1 (not a IP175D port) and it fully works up to 20mb. Unfortunately, seems MT did nothing up to ROS 5.7 as solution about it yet.