Sep 12 23:08:06 snmp: IP addr 0xc0a8cdfb port 0 Sep 12 23:08:06 KERNEL: 1:process `trapd' is using obsolete setsockopt SO_BSDCOMPAT Sep 12 23:08:03 KERNEL: 2:process `snmpd' is using obsolete setsockopt SO_BSDCOMPAT Sep 12 23:08:02 publisher: |publisher| Dropping message from 8214 for service '51 (service not found)' Sep 12 23:08:02 certmgr: |certmgr| Received unknown message Sep 12 23:08:00 fpapps: |fpapps| vrrp: vrid "1" - VRRP state transitioned from INIT to BACKUP I ended my session last night around 2300, after that there are a few stranges mesages: There is also a few other messages in the log of the standby. I also tried to upload the 6.1.3.4 software on the standby again, but that didn't change anything. The errormessage i included in the last post does not suggest a problem with the key. The key has been entered numerous times, to be certain its correct. Tried rebooting after the change, same problem. As i erased all the master redundancy and VRRP setup, i used only the interface IP's when doing the master redundancy setup, same problem.Īs i enter the peer-ip-address command, i'm suddenly unable to ping interface IP, loopback or even the VRRP IP. This is one of the things i tried yesterday. On 6.1.3.3 this option is not available, opposed to 6.1.3.4. Looks like a bug to me, especially when i'm pretty sure i had it up-and-running on code version 6.1.3.3.Ĭan not go back to 6.1.3.3 as this version is missing the USB modeswitch parameter under provisioning profile, as we push a 3G profile to several AP groups. Sep 12 22:43:28 |stm| Unexpected stm (Station management) runtime error at data_path_handler, 642, data_path_handler: recv - Network is down I get the same error on the MASTER controller a few seconds later. Sep 12 22:42:27 |stm| Unexpected stm (Station management) runtime error at data_path_handler, 642, data_path_handler: recv - Network is down On the BACKUP controller I get this message in the errorlog: Controllers reported correct status as well, one MASTER and one BACKUP.Īs soon as I enter the master redundancy setup (master-vrrp and peer-ip-address) on both controllers, the addresses I have used for the peer are now unavailable. I could now ping the VRRP IP as well from both controllers. I then programmed VRRP on both controllers and enabled the setup. Rebooted both controllers, when they came up again, I could ping across both controllers, both the vlan interface IP and the loopback. First I erased all master redundancy setup on both controllers, and all VRRP setup as well. 251 (loopback) but only the vlan 1 interface IP (.208). I'm also fairly sure the setup between these to controllers was working earlier, but then i did NOT use the. I'm pretty sure i have done this type of config before without problems The peer IP seen in the master redundancy config (192.168.205.251) is the loopback of the standby. (Riis_3400_Master) #show master-redundancyĪll the interfaces both physical and loopback are in the same subnet, so this should be a fairly easy L2 setup. Tracking type is master-up-time, duration 30 minutes, value 20 Priority 110, Advertisement 1 sec, Preemption Enable Delay 0 Periodic synchronization is enabled and runs every 30 minutes Last failure cause: Standby switch did not respond to the start request or is not ready Total size of RF plan data: 0 bytes, 0 files Local User Database backup file size: 0 bytes Last manual synchronization time: Wed Sep 12 20:31:15 2012 Please wait.Ĭurrent state is: "WAITING FOR ACK FROM STANDBY TO START". (Riis_3400_Master) #show database synchronize Ran the command as Colin suggested and the output: Well, the sync fails, obviously, with the message that the standby does not ack the start of sync.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |