Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About earl_m
earl_m
Here to help
Member since Mar 5, 2021
Mar 22 2021
Community Record
9
Posts
0
Kudos
0
Solutions
Badges
Mar 12 2021
7:06 AM
Hi cmr, I have tried that and still no luck.
... View more
Mar 12 2021
7:06 AM
Hi Greenberet, I put a PC on the voice VLAN at the site and was able to reach our DNS servers so IP communication looks good. I do not believe there is a firewall on the DNS servers, but I will find out. I do not have access into our DNS servers, but I can try and get someone in our Systems group to try that. It's looking more like it is something within our Call Managers that is missing.
... View more
Mar 10 2021
9:31 AM
Okay so I got onsite personnel to send me the phone status messages we are seeing. It is getting a DNS timeout to our Call Managers. The DNS server information assigned to the Voice VLAN is correct. We only use 2 DNS servers throughout the whole enterprise and have never had any issues with DNS with our phone system. I am stumped here.
... View more
Mar 9 2021
6:07 AM
Hi Greenberet. We only use 2 DNS server addresses throughout our enterprise, so I don't think it's anything DNS related. The Voice VLAN has the same DNS server settings as every other phone in our enterprise uses. I will get with someone at the branch office to read me the status messages on the phones. Thank you.
... View more
Mar 8 2021
11:09 AM
Hi Greenberet, that is good to know. We have several VoIP phone systems within our enterprise (across the state) that have their Option 150 set to the nearest Voice Gateway, and it has always been successful. We do not have ports 69/6970/6972 filtered in our central firewall. Now that I have the Option 150 in the Voice VLAN set to our call manager cluster, I am still not seeing the phones register with Call Manager. Perhaps I should reboot the MX68 appliance for changes to take effect?
... View more
Mar 8 2021
11:03 AM
Hi Bruce, my apologies for the delay in response. I have now set the Option 150 to our CUCM cluster, and still the phones are not pulling their config/firmware. I asked another co-worker within our department to check the Call Manager settings and he can't seem to find anything out of the ordinary. The 7942 model phone in my office has it's TFTP set to Call Manager 2. Of course, that is within our HQ office. This phone system over a Site-to-Site IPSec configuration (remote branch office) is the first of it's kind that we have within our enterprise.
... View more
Mar 5 2021
9:48 AM
I have tried pointing Option 150 to the VG and the CUCM cluster, neither of which have worked. I wasn't sure which one it should be pointing to. The phones do pick up an IP address from the local voice subnet that I have on the MX68 because the DHCP server is hosted on the MX68. I have been told by my co-workers that the TFTP server should be on the VG and not on the CUCM servers. The MX does have IP connectivity to the CUCM cluster and VG.
... View more
Mar 5 2021
9:03 AM
I am using IPSec VPN tunnels. The MX68 is a spoke and the MX250 is a hub. The Voice Gateway is on the side of the MX250 hub. The DHCP Option 150 is pointing to the JAX Voice Gateway (172.20.203.2) that you see there in that packet capture. We have several Cisco IP phones throughout the state that actually traverse an MPLS network to reach off-site remote voice gateways, and they register just fine. This IPSec VPN "Hub and Spoke" topology is the first one we have tried using.
... View more
Mar 5 2021
8:14 AM
Hello, I am new here to the Meraki forums. We are having issues with Cisco 8811 phones reaching our Call Manager at a remote branch office. More specifically, it is getting a "udp port 69 unreachable" when trying to contact our Voice Gateway that is housed at a District office in Jacksonville. Because of this, the phones cannot download their firmware/configuration from the TFTP/Voice Gateway server. We have a Meraki MX68 VPN appliance at a remote branch office in Ponte Vedra Beach, FL. We also have a MS225-48LP and a MS225-24P switch that are plugged into the MX68 appliance. The MX68 appliance creates a LAN-2-LAN VPN tunnel to our Distrcit office in Jacksonville, where there it terminates with a router then to a MX250 appliance where it enters our "intranet" network. The MX250 appliance is in the Jacksonville office and so is our Voice Gateway that we are using for this VoIP phone system. The Voice Gateway is actually a Cisco 2911 router hosting voice gateway services. On the MX68 appliance at the Ponte Vedra Beach branch office, I have Option 150 set in our DHCP server pointing to the Voice Gateway, but I have also tried pointing that Voice VLAN with Option 150 to our Call Manager as well. I was told that using the Voice Gateway for option 150 is what it should be set at, assuming this is where the TFTP server is hosted on. Moreover, the phones can be pinged from the Voice Gateway in Jacksonville and the MX68 appliance can ping our Call Managers in Tallahassee. The phones are getting IP addresses handed from our local DHCP server that we have running in the MX68 appliance; however, we are not seeing these phones register with our Call Manager. Provided below are some packet capture examples that I have got. Any help or advice would be greatly appreciated. 16:29:21.777557 IP (tos 0xb8, ttl 253, id 34922, offset 0, flags [none], proto ICMP (1), length 56) 172.20.203.2 > 172.23.14.80: ICMP 172.20.203.2 udp port 69 unreachable, length 36 IP (tos 0xb8, ttl 61, id 41516, offset 0, flags [none], proto UDP (17), length 59) 172.23.14.80.50944 > 172.20.203.2.69: 31 [|tftp] 16:29:25.730359 IP (tos 0x60, ttl 64, id 41564, offset 0, flags [none], proto UDP (17), length 59) 172.23.14.80.50944 > 172.20.203.2.69: [udp sum ok] 31 RRQ "CTLSEPCC7F75055883.tlv" octet 16:29:25.781978 IP (tos 0xb8, ttl 253, id 34926, offset 0, flags [none], proto ICMP (1), length 56) 172.20.203.2 > 172.23.14.80: ICMP 172.20.203.2 udp port 69 unreachable, length 36 IP (tos 0xb8, ttl 61, id 41564, offset 0, flags [none], proto UDP (17), length 59) 172.23.14.80.50944 > 172.20.203.2.69: 31 [|tftp] 16:29:31.015116 IP (tos 0x0, ttl 64, id 26706, offset 0, flags [none], proto TCP (6), length 60) 172.23.14.80.51348 > 172.20.203.2.6970: Flags [S], cksum 0xa13b (correct), seq 1873281886, win 29200, options [mss 1460,sackOK,TS val 6859770 ecr 0,nop,wscale 5], length 0 16:29:31.079141 IP (tos 0xb8, ttl 253, id 36511, offset 0, flags [none], proto TCP (6), length 40) 172.20.203.2.6970 > 172.23.14.80.51348: Flags [R.], cksum 0x277c (correct), seq 0, ack 1873281887, win 0, length 0 16:29:31.621927 IP (tos 0x60, ttl 64, id 41634, offset 0, flags [none], proto UDP (17), length 59) 172.23.14.80.49188 > 172.20.203.2.69: [udp sum ok] 31 RRQ "ITLSEPCC7F75055883.tlv" octet 16:29:31.672766 IP (tos 0xb8, ttl 253, id 35345, offset 0, flags [none], proto ICMP (1), length 56) 172.20.203.2 > 172.23.14.80: ICMP 172.20.203.2 udp port 69 unreachable, length 36 IP (tos 0xb8, ttl 61, id 41634, offset 0, flags [none], proto UDP (17), length 59) 172.23.14.80.49188 > 172.20.203.2.69: 31 [|tftp] 16:29:32.629043 IP (tos 0x60, ttl 64, id 41638, offset 0, flags [none], proto UDP (17), length 59) 172.23.14.80.49188 > 172.20.203.2.69: [udp sum ok] 31 RRQ "ITLSEPCC7F75055883.tlv" octet 16:29:32.679123 IP (tos 0xb8, ttl 253, id 35547, offset 0, flags [none], proto ICMP (1), length 56) 172.20.203.2 > 172.23.14.80: ICMP 172.20.203.2 udp port 69 unreachable, length 36 IP (tos 0xb8, ttl 61, id 41638, offset 0, flags [none], proto UDP (17), length 59) 172.23.14.80.49188 > 172.20.203.2.69: 31 [|tftp] 16:29:34.631282 IP (tos 0x60, ttl 64, id 41785, offset 0, flags [none], proto UDP (17), length 59) 172.23.14.80.49188 > 172.20.203.2.69: [udp sum ok] 31 RRQ "ITLSEPCC7F75055883.tlv" octet 16:29:34.682712 IP (tos 0xb8, ttl 253, id 35946, offset 0, flags [none], proto ICMP (1), length 56) 172.20.203.2 > 172.23.14.80: ICMP 172.20.203.2 udp port 69 unreachable, length 36 IP (tos 0xb8, ttl 61, id 41785, offset 0, flags [none], proto UDP (17), length 59) 172.23.14.80.49188 > 172.20.203.2.69: 31 [|tftp] 16:29:37.455711 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.23.14.80 tell 172.23.14.65, length 42 16:29:37.456270 ARP, Ethernet (len 6), IPv4 (len 4), Reply 172.23.14.80 is-at cc:7f:75:05:58:83, length 42 16:29:38.631855 IP (tos 0x60, ttl 64, id 41988, offset 0, flags [none], proto UDP (17), length 59) 172.23.14.80.49188 > 172.20.203.2.69: [udp sum ok] 31 RRQ "ITLSEPCC7F75055883.tlv" octet 16:29:38.682398 IP (tos 0xb8, ttl 253, id 35983, offset 0, flags [none], proto ICMP (1), length 56) 172.20.203.2 > 172.23.14.80: ICMP 172.20.203.2 udp port 69 unreachable, length 36 IP (tos 0xb8, ttl 61, id 41988, offset 0, flags [none], proto UDP (17), length 59) 172.23.14.80.49188 > 172.20.203.2.69: 31 [|tftp] Thank you.
... View more
© 2024 Cisco Systems, Inc.
