Good day.
I use Mikrotik RB2011UiAS, in ether1 link ISP1 (IPoE), in ether2 link ISP2 (IPoE). In ether3 must be ISP3 (IPoE). I register settings (ip, subnet, route, DNS) and connect - it does not work. I look at the statistics (Overall Stats) of the ether3 interface and see that the data goes only in one direction: Tx Bytes is always 0, Rx Bytes is constantly growing (screenshot attached).
I called the provider, explain the situation, to which I get the answer that they do not see the MAC from me. They offered to check the cable and change the crimping scheme (T568A/T568B)… Naturally, none of this helped: the cable is whole, the crimping scheme did not solve the situation. I called the provider again, provider offered to remove the autonegotiation mode on the interface and force the installation of “100Mbps Full Duplex” (although it is the “100Mbps Full Duplex” that is installed in the autonegotiation mode), it did not work.
As a test, I decided to test IPoE on a regular desktop PC. I registered the settings and connected it - it worked. I called the provider, provider see the MAC address of the desktop PC.
Next, I try the following: instead of ether3, I switch to the ether2 interface that is obviously working (I’m temporarily disconnecting the ISP2 Megaphone IPoE), but the situation repeats, the provider still doesn’t see the MAC ether2 of my Mikrotik RB2011UiAS. How so?
Immediately after successfully connecting an desktop PC via IPoE, I prescribe the MAC address of this desktop PC on the Mikrotik interface (using command interface ethernet set ether2 mac-address=MY_MAC) — the Internet works. I understand that this is a temporary solution, and as soon as the provider restarts its switch, the connection will be lost. It turns out that the problem is in the initial initiation of the connection between Mikrotik (and only, because it works on a regular PC) and the provider equipment …
How can I solve the problem?
Could be it’s a chicken & egg problem: interface only properly gets up after your ISP sees some packet from router (to fetch MAC of the interface) and router refuses to send anything down the cable until interface gets properly up. No idea how to force RB to transmit anything down the half-configured interface though.
@mkx: I don’t have personal experience with anyone asking me to configure “IPoE”, but from everything I heard and read about IPoE, it is nothing else than normal IP communication which runs on almost every ethernet link around… You don’t have any special “IPoE” interface - its literary the Ethernet interface itself, which goes up by negotiating L1 speed (which already proves that all wires are fine, otherwise it wouldn’t be able to negotiate the speed). Once it is up, it can acquire IP, usually via DHCP, right?
few points:
- if there is RX packet count, it means the speed was negotiated which means the cable is right. (if ISP didn’t realize it, he has probably no idea what he talks about).
- bad cable CAN’T affect TX counter because if there is bad cable your device will desperately try to TX, counter will go up, but those frames will never reach destination.
- empty TX in IP environment can be, by my knowledge, caused only if your router does not even try to send something through the interface. This is usually result of missing IP configuration (either manual or DHCP client), missing route or firewall setting. (It could be also bridge filter setting but I assume you don’t have your WAN Ethernet interface on bridge)
@netmai2000: If you don’t want to share any info about your config (I guess it is secret because you carefully avoided every single piece of your configuration), I can only suggest to start with basics - stuff like ARP pings: since you specify interface, it gets practically pushed through it, no matter whats going on with rest of the config, as long as the interface is running. This will guarantee you a TX packets. Obviously, it does not guarantee, there will be any response, but if your ISP sniffs data, they must see it coming in.
Thx. I used option “Check Gateway” - “arp” for default route. It works!