Mitel Forums - The Unofficial Source
Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started by: elfordty on January 08, 2013, 01:00:47 AM
-
HI there,
I am currently in the process of reconfiguring all our network devices. We used to have a flat network with no VLANs and now we have VLANs. Im at the stage of putting out Mitel phone system on it's own VLAN.
I changed to IP address of the Mitel 3300 MXe III and it now boots up fine, but after about 5 minutes of being booting up it drops its IP address. During the boot up I can ping the device and once booted the phones even get the proper (new) VLANs and DHCP addresses, however after about 5 minutes I loss connection to the 3300 and all the phones go offline.
Does anyone have any suggestions about this at all?
-
I just wanted to add that it also sometimes drops the IP half way or part way through boot up.
I don't know if this is any help but here is a few outputs from the box
hostShow
hostname inet address aliases
-------- ------------ -------
localhost 127.0.0.1
vxTarget 172.16.18.1
Mitel3300Cont 172.16.18.3
R_Ch_0 169.254.10.1
routeShow
ROUTE NET TABLE
Destination Gateway Flags Refcnt Use Interface
--------------------------------------------------------------------
0.0.0.0 172.16.18.254 0x103 4 0 qefcc0
169.254.10.0 169.254.10.1 0x101 1 0 MccDev0
172.16.18.0 172.16.18.1 0x101 5 0 qefcc0
--------------------------------------------------------------------
ROUTE HOST TABLE
Destination Gateway Flags Refcnt Use Interface
--------------------------------------------------------------------
127.0.0.1 127.0.0.1 0x5 22 4141 lo0
192.168.0.66 172.16.18.254 0xc007 0 4 qefcc0
192.168.0.69 172.16.18.254 0xc007 0 6 qefcc0
192.168.0.93 172.16.18.254 0xc007 0 18 qefcc0
192.168.1.18 172.16.18.254 0xc007 0 127 qefcc0
--------------------------------------------------------------------
value = 69 = 0x45 = 'E'
ifShow
qefcc (unit number 0):
Flags: (0x63) UP BROADCAST ARP RUNNING
Type: ETHERNET_CSMACD
Internet address: 172.16.18.1
Broadcast address: 172.16.18.255
Netmask 0xffff0000 Subnetmask 0xffffff00
Ethernet address is 08:00:0f:63:99:c8
Metric is 0
Maximum Transfer Unit size is 1500
259374 octets received
2098308 octets sent
4188 packets received
4175 packets sent
65 non-unicast packets received
5 non-unicast packets sent
4123 unicast packets received
4170 unicast packets sent
0 input discards
0 input unknown protocols
0 input errors
0 output errors
0 collisions; 0 dropped
lo (unit number 0):
Flags: (0x8069) UP LOOPBACK MULTICAST ARP RUNNING
Type: SOFTWARE_LOOPBACK
Internet address: 127.0.0.1
Netmask 0xff000000 Subnetmask 0xff000000
Metric is 0
Maximum Transfer Unit size is 32768
4877 packets received; 4877 packets sent
0 multicast packets received
0 multicast packets sent
0 input errors; 0 output errors
0 collisions; 0 dropped
MccDev (unit number 0):
Flags: (0x61) UP ARP RUNNING
Type: ETHERNET_CSMACD
Internet address: 169.254.10.1
Netmask 0xffff0000 Subnetmask 0xfffffff0
Ethernet address is 08:00:0f:63:01:01
Metric is 0
Maximum Transfer Unit size is 1500
9758 octets received
21776 octets sent
162 packets received
202 packets sent
3 non-unicast packets received
1 non-unicast packets sent
159 unicast packets received
201 unicast packets sent
0 input discards
0 input unknown protocols
0 input errors
0 output errors
0 collisions; 0 dropped
value = 29 = 0x1d
Thank you
-
I have also setup DHCP with my Windows server. I have a Windows 2012 server and the DHCP for this server doesn't have a lot of the older options. I was advised to use option 43 for the Mitel phones.
It contains option 43 for both the default vlan and the vlan the phones are going to be on.
Below is my connection string for option 43
id:ipphone.mitel.com;sw_tftp=172.16.18.1;call_srv=172.16.18.1;vlan=18;mode=minet
-
Can you show us your boot config from the 3300?
From the RTC enter 'bootChange', step through the options and post it here.
Ralph
-
Hi Ralph,
Thanks for the quick reply, here is the bootChange
-> bootChange
'.' = clear field; '-' = go to previous field; ^D = quit
boot device : ata=00
processor number : 0
host name : Mitel3300Cont
file name : /partition1/RTC8260
inet on ethernet (e) : 172.16.18.1:ffffff00
inet on backplane (b): 172.16.18.2:ffffff00
host inet (h) : 172.16.18.3
gateway inet (g) : 172.16.18.254
user (u) : Mitelftp
ftp password (pw) (blank = use rsh): Surfing55
flags (f) : 0x0
target name (tn) :
startup script (s) :
other (o) : qefcc
value = 0 = 0x0
Tyson
-
Ok I got it working!!
What I found out. Using the "definitive shell command guide" from this site (legendary!!) I ran the command vlan_off. As soon as I did that the IP came back online. Running vlan_on dropped the IP again.
I have an HP switch and I had untagged the port for the 3300 on the voice VLAN and tagged the other VLANs that were allowed. What I needed to do was tag the voice port and other vlans and it came back up straight away.
Doesn't fully make sense to me that the port for the 3300 has to be tagged and not untagged but that fixed it for me so woohoo
Tyson
-
I actually waited for your bootChange to see if you used the 0x0 flag :P
The vlan_off makes sense. It all has to do with your switch config.
If you set the tagging to the port being untagged in VLAN 18 and set the other VLAN's to FORBID or NO, you need to default the VLAN in IP configuration in the Mitel to 1. In other words with an untagged setting you let the switches define the VLAN which is imo recommended and if you set it to tagged you can define it through the Mitel 3300 in the IP configuration menu.
I never use tagged for data or others on the port where the Mitel 3300 is connected, since IP routing wether set by the switch or, if you use a static route to your firewall, your firewall defines if you can reach the voice parts from the data network. Out of my head, No if they dont need access and I think LACP, if used in your network, requires a forbid setting.
I hope this info clearifies.
-
The 3300 can either be setup to tag its packets with the voice VLAN or not ( its in network settings ). Its your choice. Some people want the 3300 to use tagging so all the HP ports can be setup exactly the same. When you do that however you need to shut off the tagging if you were to connect a laptop directly to the switch for troubleshooting.
The other option is to "statically" set the port the 3300 is connected to as part of the voice VLAN. In this case the 3300 will use untagged packets and the HP port needs to be set for untagged belonging to the voice VLAN. Again its up to you.
-
Don't tell me this issue is showing up on MXE III's ! LORD !. So the 3300 is on an untagged access port of your voice VLAN?. After a few minutes you lose connection to the phones and can't ping unless you enter 'VLAN_OFF' from the console?
This is a MAJOR issue with the L2 switch on MXeII's. From what I have found. It is a manufacturing defect of the L2 switch itself. This issue will not raise it's ugly head unless the network is setup as described here. The controller has to be replaced. There is a command that can be entered in console to reset the MIPS service every so often: “period 900,mips_reset” if you Putty to the console and leave out the quotes if doing via RS232. If this is still an issue, I can also give you a way to test future controllers to ensure this will not happen.
-
Don't tell me this issue is showing up on MXE III's ! LORD !. So the 3300 is on an untagged access port of your voice VLAN?. After a few minutes you lose connection to the phones and can't ping unless you enter 'VLAN_OFF' from the console?
This is a MAJOR issue with the L2 switch on MXeII's. From what I have found. It is a manufacturing defect of the L2 switch itself. This issue will not raise it's ugly head unless the network is setup as described here. The controller has to be replaced. There is a command that can be entered in console to reset the MIPS service every so often: “period 900,mips_reset” if you Putty to the console and leave out the quotes if doing via RS232. If this is still an issue, I can also give you a way to test future controllers to ensure this will not happen.
Umm... This was well over 2 years ago, and the OP never stated the problem continued or the controller had to be replaced. This sounded to me like a simple network mis-configuration on either the 3300 or network that was fixed easily... What are you talking about here?
-
Don't tell me this issue is showing up on MXE III's ! LORD !. So the 3300 is on an untagged access port of your voice VLAN?. After a few minutes you lose connection to the phones and can't ping unless you enter 'VLAN_OFF' from the console?
This is a MAJOR issue with the L2 switch on MXeII's. From what I have found. It is a manufacturing defect of the L2 switch itself. This issue will not raise it's ugly head unless the network is setup as described here. The controller has to be replaced. There is a command that can be entered in console to reset the MIPS service every so often: “period 900,mips_reset” if you Putty to the console and leave out the quotes if doing via RS232. If this is still an issue, I can also give you a way to test future controllers to ensure this will not happen.
Umm... This was well over 2 years ago, and the OP never stated the problem continued or the controller had to be replaced. This sounded to me like a simple network mis-configuration on either the 3300 or network that was fixed easily... What are you talking about here?
The original post was regarding a network mis-config. What normanbing is talking about is a known issue with MXe II L2 switches failing requiring the controller to be replaced.
Ralph
-
Don't tell me this issue is showing up on MXE III's ! LORD !. So the 3300 is on an untagged access port of your voice VLAN?. After a few minutes you lose connection to the phones and can't ping unless you enter 'VLAN_OFF' from the console?
This is a MAJOR issue with the L2 switch on MXeII's. From what I have found. It is a manufacturing defect of the L2 switch itself. This issue will not raise it's ugly head unless the network is setup as described here. The controller has to be replaced. There is a command that can be entered in console to reset the MIPS service every so often: “period 900,mips_reset” if you Putty to the console and leave out the quotes if doing via RS232. If this is still an issue, I can also give you a way to test future controllers to ensure this will not happen.
Umm... This was well over 2 years ago, and the OP never stated the problem continued or the controller had to be replaced. This sounded to me like a simple network mis-configuration on either the 3300 or network that was fixed easily... What are you talking about here?
The original post was regarding a network mis-config. What normanbing is talking about is a known issue with MXe II L2 switches failing requiring the controller to be replaced.
Ralph
It should be noted that I've been told by Mitel that the MXE-III contains the same MIPS processor that's the root of the issue with the MXe and MXe-II L2 failure problem, but I haven't seen the problem on a III yet.