Điện thoại trên một số thiết bị chuyển mạch không thể hoàn tất quy trình DHCP


16

Lý lịch

Tôi có máy chủ Windows DHCP (Server 2008 R2) phân phát địa chỉ cho một số phạm vi. Một trong những phạm vi đó là dành cho một số Điện thoại IP Mitel. Các điện thoại được cấu hình để sử dụng tùy chọn dhcp 125 để lấy thông tin cấu hình. Khi điện thoại khởi động, nó không biết nên sử dụng vlan nào và do đó, nó chỉ nhận được vlan mặc định (không được gắn thẻ) của bất kỳ cổng nào mà nó được kết nối. Máy chủ dhcp cung cấp cho nó phản hồi bao gồm thông tin tùy chọn 125 và điện thoại có thể đọc những gì vlan nên sử dụng từ phản hồi này. Sau đó, điện thoại sẽ giải phóng địa chỉ ban đầu và yêu cầu thuê dhcp mới bằng cách sử dụng thẻ vlan chính xác. Các điện thoại cũng thường có máy tính được kết nối với cổng thông qua. Các gói từ các máy tính không bao giờ được gắn thẻ, và do đó, PC sẽ ở trên vlan gốc (không được gắn thẻ) cho cổng. Điều này đã làm việc cho chúng tôi trong nhiều năm.

Vấn đề và triệu chứng

Ở đâu đó trong vài tuần qua, một cái gì đó đã thay đổi, và tôi không chắc là gì. Các điện thoại sẽ tiếp tục hoạt động miễn là chúng không khởi động lại, có nghĩa là các yêu cầu gia hạn dhcp phải được xử lý chính xác. Điện thoại được kết nối với một số thiết bị chuyển mạch thậm chí có thể tồn tại khi khởi động lại. Tuy nhiên, điện thoại được kết nối với các thiết bị chuyển mạch khác sẽ không hoàn thành quy trình khi chúng khởi động lại. Tất cả các điện thoại của chúng tôi đang sử dụng PoE được sao lưu bởi UPS, vì vậy đã lâu rồi kể từ khi bất kỳ thiết bị nào được khởi động lại. Điều này có nghĩa là tôi không có ý tưởng khi vấn đề lần đầu tiên xuất hiện. Những gì tôi biết là một điện thoại đã bị lỗi khi khởi động lại vào ngày hôm qua và để khắc phục sự cố ngày hôm nay, chúng tôi đã thiết lập lại tủ chuyển đổi đó. Bây giờ không có điện thoại nào trên công tắc đó đang hoạt động (rất may đó vẫn là một số nhỏ). Tôi cũng biết rằng mọi thứ đã hoạt động gần cuối tháng 1,

Khi tôi xem một chiếc điện thoại khởi động, tôi có thể thấy nó thành công lấy địa chỉ đầu tiên. Sau đó, nó đọc thành công thông tin tùy chọn 125, đặt thẻ vlan chính xác và giải phóng hợp đồng thuê IP gốc. Nó thậm chí có thể nhận và chấp nhận một đề nghị trên vlan chính xác từ máy chủ . Tuy nhiên, đó là nơi mọi thứ dừng lại. Điện thoại có một thông báo trên màn hình cho biết " DHCP: Offer 2 ACC", nhưng máy chủ Windows DHCP đã không ghi lại hợp đồng thuê và điện thoại không bao giờ di chuyển. Tôi chỉ có thể đoán rằng gói DHCP REQUEST không bao giờ đến được máy chủ Windows và vì vậy điện thoại đang chờ ACK cuối cùng từ Windows mà vẫn ổn để tiếp tục.

Cách giải quyết

Cuối cùng tôi đã có thể có được một chiếc điện thoại hoạt động trở lại. Để làm điều đó, trước tiên tôi phải ngắt kết nối máy tính. Sau đó, tôi đặt cổng chuyển đổi điện thoại thành không được gắn trên vlan điện thoại, không có thành viên trên PC vlan. Điện thoại sẽ khởi động lại chính xác. Tại thời điểm này, tôi có thể đặt cấu hình cổng chuyển đổi trở lại vị trí cần thiết và miễn là không ai cố gắng gọi số đó khi tôi đặt lại cổng, điện thoại không bao giờ bị lỗi. Sau đó tôi có thể kết nối lại máy tính. Rõ ràng, đó không phải là một quá trình lý tưởng, mặc dù vì điện thoại khởi động lại nên hiếm khi tôi có thể sử dụng nó để khiến mọi người làm việc lại cho đến khi tôi có thể tìm ra nguyên nhân gốc rễ. Các văn phòng hiện đã đóng cửa trong tuần và vì vậy vấn đề này thực sự sẽ được phép ngồi vào cuối tuần (Tôi không có chìa khóa cho các văn phòng riêng lẻ nơi có điện thoại).

Điện thoại này tôi đã sửa là điện thoại dịch vụ trong phòng máy chủ, được kết nối trực tiếp với bộ chuyển mạch lõi của chúng tôi. Có thể sự cố là do sự cố với thẻ định tuyến hoặc xử lý trên công tắc lõi, do đó cách khắc phục sẽ không hiệu quả đối với các văn phòng từ xa nơi các gói được chuyển qua (được gắn bởi) các công tắc khác, nhưng tôi sẽ rất ngạc nhiên nếu điều đó xảy ra, cho rằng tôi biết nó phải xử lý gia hạn dhcp và các cuộc trò chuyện điện thoại thực tế một cách chính xác.

Một vấn đề khó khăn là việc để cổng được gắn thẻ trên PC vlan có nghĩa là điện thoại thay vì thất bại với thông báo " DHCP: Offer 1 ACC". Tôi cần phải loại bỏ hoàn toàn vlan đó để thành công.

Lưu ý: Bây giờ tôi đã xác nhận rằng công việc xung quanh có hiệu quả trong các tòa nhà từ xa. Điều này khiến tôi nghi ngờ rằng các thiết bị của mình bằng cách nào đó không được gán cho vlan chính xác. Thực tế là tôi đã gặp sự cố trên bộ chuyển mạch lõi của mình và nó đã xảy ra ở một số nơi trên mạng cùng một lúc, cho thấy rằng bộ chuyển mạch lõi có thể là vấn đề. Không có gì cụ thể để xem xét, tôi đang lên lịch cho một cửa sổ bảo trì vào gần cuối tuần để khởi động lại công tắc. Tôi cũng có thể cập nhật firmware.

Môi trường

Công tắc cốt lõi của chúng tôi là một HP 5406zl. Công tắc này xử lý định tuyến liên vlan. Máy chủ Windows DHCP được kết nối trực tiếp với bộ chuyển mạch. Các công tắc điểm cuối được kết nối với công tắc lõi thông qua SFP sợi và các cổng này được gắn thẻ cho tất cả các vlans ở cả hai đầu. Công tắc lõi cấu hình mỗi vlan với một ip helper-addresscài đặt trỏ nó đến máy chủ DHCP của chúng tôi và một dhcp relay-option 82 replacedòng để máy chủ dhcp sẽ biết phạm vi sử dụng. Các cấu hình này và cấu hình cổng trên các thiết bị chuyển mạch điểm cuối, đã không thay đổi trong ít nhất 16 tháng. Chúng tôi đã có chuyển đổi và đặt lại điện thoại khác trong thời gian đó.

Hầu hết các thiết bị chuyển mạch điểm cuối của chúng tôi là dòng HP 2530. Các công tắc này dường như hoạt động chính xác (điện thoại trên 3 2530 khác nhau đã khởi động lại chính xác ngày hôm nay). Đó là thiết bị chuyển mạch cũ có vấn đề. Chúng tôi có một 3Com 4200 cũ và một 4210 sẽ không hoạt động. Điện thoại dịch vụ được kết nối trực tiếp với công tắc lõi được đề cập trước đó cũng sẽ không hoạt động.

Câu hỏi

Tại thời điểm này, dự đoán tốt nhất của tôi là bản cập nhật Windows trên máy chủ dhcp đã thay đổi hành vi, nhưng tôi không thể thấy được. Hoặc có thể công tắc lõi không xử lý chính xác gói REQUEST đó, nhưng tôi chắc chắn rằng không có gì thay đổi ở đó và nó không giải thích tại sao chỉ có một số công tắc điểm cuối nhất định được thực hiện. Làm thế nào tôi có thể giải quyết vấn đề này?

Cập nhật:

Đây là đoạn trích nhật ký dhcp từ điện thoại bị lỗi:

10,03 / 06 / 15,12: 40: 40, Assign, 10.1.2.158 ,, 08000F197844 ,, 3189088995,0 ,,, 11,03 / 06 / 15,12: 40: 40, Gia hạn, 10.1.2.158, , 08000F197844 ,, 3189088995,0 ,,, 12,03 / 06 / 15,12: 40: 41, Phát hành, 10.1.2.158 ,, 08000F197844 ,, 3189088995,0 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154 ,, 08000F197844 ,, 0,6 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154 ,, 08000F197844 ,, 0,6 ,,,

Các địa chỉ 10.xxx là PC vlan (lựa chọn đó có trước tôi tại địa điểm này). Điện thoại nên có loại địa chỉ đó lúc đầu, vì vậy đó là mong đợi. Tuy nhiên, sau thông báo phát hành, tôi cũng mong đợi tìm thấy một đề nghị cho một địa chỉ trong phạm vi 192.168.16.x, bởi vì tôi có thể thấy trên điện thoại rằng một đề nghị đã được chấp nhận (trừ khi tôi hiểu sai "ACC"). Thật thú vị khi tôi không bao giờ thấy máy chủ cố gắng đưa ra một địa chỉ như vậy, mặc dù điện thoại nghĩ rằng nó đã nhận được một địa chỉ.

Tôi đã xem xét ý tưởng có một máy chủ dhcp giả mạo trên mạng (nó cung cấp một địa chỉ trước máy chủ Windows, nhưng không có các tùy chọn dhcp cần thiết cho điện thoại để tiếp tục), nhưng điều đó không giải thích tại sao điện thoại hoạt động khi và chỉ khi Tôi loại bỏ hoàn toàn bất kỳ đường dẫn đến PC vlan. Dù sao thì tôi cũng sẽ kiểm tra nó vào buổi sáng bằng cách kết nối máy tính xách tay của tôi với một cổng được đặt cho vlan điện thoại, nhưng nếu có ai có lời giải thích tốt hơn trong lúc này, tôi rất muốn nghe.

Đây là bản sao của cấu hình chuyển đổi:

http://pastebin.com/veXjCRXu


Bạn đã đưa ra một phỏng đoán có giáo dục rằng gói DHCP REQUEST không bao giờ đến được máy chủ. Bây giờ hãy tăng mức ghi nhật ký trên máy chủ DHCP hoặc đánh hơi một số lưu lượng và xác minh linh cảm của bạn. Đừng mắc kẹt. Bạn có thể làm được việc này.
Skyhawk

1
Không có câu trả lời cho bạn, nhưng +1 cho một câu hỏi được suy nghĩ kỹ và thử nghiệm.
Cấp

1
@Skyhawk Đã dừng lại để ăn tối, nhưng đó là bước tiếp theo của tôi. Kết quả là trong câu hỏi.
Joel Coel 7/03/2015

Bạn có thể cho tôi phiên bản phần mềm ProCurve 5406zl của bạn không?
ehhite 7/03/2015

1
Tôi có xu hướng chạy các công tắc này trên một phiên bản cụ thể trong 6-12 tháng. Tôi có các công tắc tương tự được sử dụng với điện thoại Shoretel sử dụng cùng một khái niệm. Sẽ rất thú vị khi xem một cấu hình vệ sinh.
ewwhite

Câu trả lời:


2

Tôi đã khắc phục sự cố ngày hôm nay bằng cách xóa thẻ vlan cho điện thoại vlan trên cổng kết nối với máy chủ dhcp của chúng tôi. Điều này rất lạ đối với tôi rằng điều này đã hoạt động, vì các hệ thống khác sử dụng sơ đồ tương tự (còn gọi là: SSID Wifi sử dụng 802.1q) yêu cầu thẻ hoặc khách hàng không thể nhận địa chỉ. Nó đã làm việc, vì vậy tôi sẽ không quá chăm chỉ, nhưng tôi sẽ thấy thú vị khi xem câu trả lời với lý thuyết tại sao nó lại như vậy.


0

Bạn nên xem xét việc chạy gói chụp ở hai bên của (các) công tắc có vấn đề và sau đó xem xét việc này trong Wireshark. Điều này sẽ có thể cho bạn biết 1) nếu lưu lượng truy cập bị chặn bởi máy chủ DHCP giả mạo (dựa trên địa chỉ MAC) và 2) nếu có thứ gì đó bị xáo trộn hoặc bị hủy (ví dụ: có thể bạn cần chuyển tiếp DHCP). Điều này có thể yêu cầu phản chiếu cổng hoặc 3com có ​​thể hỗ trợ chụp trực tiếp trên công tắc.


0

Nếu bạn thấy rằng vấn đề này xuất hiện trở lại, bạn có thể muốn kiểm tra kích thước của phạm vi DHCP của bạn và có bao nhiêu hợp đồng thuê đang được sử dụng. Nếu các hợp đồng thuê DHCP cũ không bị phá hủy, máy chủ của bạn có thể nghĩ rằng không còn địa chỉ nào trong nhóm và không thể gán địa chỉ mới. Điều này đúng ngay cả khi không có thiết bị nào phản hồi trong vlan. Nếu phạm vi DHCP của bạn là 7 ngày, có thể lên đến 7 ngày trước khi bạn có thể nhận được hợp đồng thuê mới. Tương tự như vậy, việc thay đổi cấu hình của bạn xung quanh sẽ giải quyết vấn đề vì sẽ có một loạt địa chỉ mới có thể bị loại bỏ hoặc có thể xóa các hợp đồng thuê tùy thuộc vào thay đổi cấu hình. Tôi sẽ đề nghị đặt thời gian thuê cho một mức rất thấp, như một giờ cho phạm vi đó nếu đây là trường hợp.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.