Received the unit yesterday and plugged it in to the CCR1009 this morning without any success.
a. moved vlanbell from eth6temp to SFP+ port with new cage
b. ensured SFP+ interface was added to WAN interface list
c. yes, moved ethernet cable from ont/modem to SFP+ cage vice et6
1 - using auto negotiation defaults - no connectivity
2- turned auto negotiation off
i. tried 1gig no dice
ii. tried 1gig + 1.25 gig no dice
iii tried 100m no dice
What could I be doing wrong or not attempting/missing??
Yes, the cage is recognized and reported by the CCR1009 when plugged in.
If you needed visual representation…
The weird things is (never have used internet detect before) is that IDetect shows Bell_SFP+ as a LAN detection whereas,
no where have I stated any such thing. Although cut-off if you look at the interface list, you will see its identified as a WAN interface ???
Okay instead of /interface print
I entered /interface and then
/print and the result is better
Note that the last entry vlanbell is the same as the first entry BellTemp_eth6 as that is what is currently live at the moment.
It seems I should make sure that when I switch to Bell_sfp+ that its mac address also matches that of VLAN bell.
What I do not know is if that is simply a function of assigning the vlan to the specific interface.
/interface> print
Flags: D - dynamic, X - disabled, R - running, S - slave
NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 R BellTemp_eth6 ether 1500 1580 10222 C4:AD:34:EA:42:F2
1 Bell_sfp+ ether 1500 1580 10222 C4:AD:34:EA:42:EB
2 R Eastlink_eth7 ether 1500 1580 10222 C4:AD:34:EA:42:F3
3 RS ToGarageSw260_eth3 ether 1500 1580 10222 C4:AD:34:EA:42:EF
4 RS ToPatchPanel_eth1 ether 1500 1580 10222 C4:AD:34:EA:42:ED
5 RS ToVOIP-Modem_eth2 ether 1500 1580 10222 C4:AD:34:EA:42:EE
6 RS To_Basement_combo ether 1500 1580 10222 C4:AD:34:EA:42:EC
7 S spare_eth4V69 ether 1500 1580 10222 C4:AD:34:EA:42:F0
8 S spare_eth5V11 ether 1500 1580 10222 C4:AD:34:EA:42:F1
9 R Air_ThingsV36 vlan 1500 1576 C4:AD:34:EA:42:EC
10 R Carm_V86 vlan 1500 1576 C4:AD:34:EA:42:EC
11 R Guests-T&B_TPLink_V100 vlan 1500 1576 C4:AD:34:EA:42:EC
12 R Guests-main_cap2_V200 vlan 1500 1576 C4:AD:34:EA:42:EC
13 R Home-LAN_V11 vlan 1500 1576 C4:AD:34:EA:42:EC
14 R HomeBridge bridge 1500 1580 C4:AD:34:EA:42:EC
15 R MediaStreaming_V40 vlan 1500 1576 C4:AD:34:EA:42:EC
16 R Mstudy vlan 1500 1576 C4:AD:34:EA:42:EC
17 R NAS_V33 vlan 1500 1576 C4:AD:34:EA:42:EC
18 R PS4_V55 vlan 1500 1576 C4:AD:34:EA:42:EC
19 R Septic_V02 vlan 1500 1576 C4:AD:34:EA:42:EC
20 R SmartDev_TPLink_V30 vlan 1500 1576 C4:AD:34:EA:42:EC
21 R SmartDev_cap2_V45 vlan 1500 1576 C4:AD:34:EA:42:EC
22 R SolarVlan vlan 1500 1576 C4:AD:34:EA:42:EC
23 R Theo_V666 vlan 1500 1576 C4:AD:34:EA:42:EC
24 R VOIP_V77 vlan 1500 1576 C4:AD:34:EA:42:EC
25 R VidCam_V99 vlan 1500 1576 C4:AD:34:EA:42:EC
26 R spare_V31 vlan 1500 1576 C4:AD:34:EA:42:EC
27 R vlanbell vlan 1500 1576 C4:AD:34:EA:42:F2
[RMadmin@RM-Residence] /interface>
The VLAN interface inherits its MAC address from its underlying interface, no way around that.
A bridge inherits its MAC address from the first member port to come up, unless you manually configure an admin-mac for the bridge.
Some ISPs assign an IP address only to the very first device (identified by its MAC address) to be connected to the user-facing interface of their gear when it gets powered up. So when you want to connect something else, you must power-cycle the ISP-provided box. But I don’t remember whether it is your case.
Well, seeing as the router was first assigned to the eth6 interface you may have a point.
However I did recycle power off and on for the ISP ONT/modem and that didnt seem to make any difference.
Perhaps I will do so but for 5-10 minutes vice just one minute.
Note the ONT/Modem has no issues with being connected to a HEX and an RB450Gx4 etc… so it can connect to various routers without issue.
At this point I may only be left with sending MT two supout reports - successfully attached via eth6 and unsuccessfully attached via sfp+ and maybe they can figure something out???
Yes. You can do some more tests, attaching a static IP address to the SFP+, connecting it to a port of one of your other routers with another static IP address from the same subnet, and try to ping with arp-ping=yes one from the other, but I’m afraid you’ll end up with the same result.
Got very busy … sorry I’m late … but looks like you got lots of help
IMO, the firmware + ROS driving the S+RJ10 is got an Ethernet conversion problem and only MikroTik can fix it.
The OBVIOUS is that since ether6 works just fine but when the S+RJ10 is introduced it and or ROS are not communicating … so stick with ether6 until MikroTik provides a fix.
BTW /interface print
should work to output all the interfaces and their associated Mac Addy’s but for some reason your CCR does not respond properly … perhaps [speculating] something to do with the fact that you for some remarkable reason renamed them and ROS became confused. My suggestion is do not rename anything from default until everything is working properly … lots of bugs in this ROS proprietary shell. I personally do NOT recommend renaming interfaces period
