ScreenOS Firewalls (NOT SRX)
Reply
Visitor
tim13
Posts: 4
Registered: ‎10-23-2008
0

SSG-20 ADSL-PIM failover ?

[ Edited ]

I have two mini-PIM ADSL interfaces configured and active. As soon as I configure the failover under Network-Interfaces-Backup  (primary/secondary) the secondary interface will go down and also disconnect from the PPPoA. As a result of the PPPoA going down the inactive interface will loose it's connectivity and IP address. The log will show the interface as startingPPPoA negotiations every 60 seconds (log=PPPoA ADSL-2 started negotiation.), but then the PPP fails for some reason (log=PPPoA ADSL-2 connection attempt failed (LCP,CHAP/PAP, IPCP link setup)). Once I remove the failover setting, the PPPoA willcome up without errors and stay connected.

 

I know, if I had external ADSL interfaces this would not be an issue, because the external interfaces would keep the PPP links, and the SSG would only switch Ethernet ports. But the reason for buying the SSG-20 was exactly that it does have 2 **internal** ADSL interfaces - to avoid having 3boxes (2xADSL+1xSSG-5).

 

Primary link works fine, and force of failover/revert also works. When I fail over manually to the secondary link, it will stay there only for a short time (force_time=interval*threshold ?) and then fail over back to the primary link.

 

QUESTION: All this PPP teardown is a real nuisance because it takes a lot longer (20x) than my track-ip interval. As such, failover will take several minutes at best (not seconds). Also, seems not really a good idea to continuously reconnect the PPP because I will receive a new IP from the ISP every time the PPP connects. Also the logs entries are misleading (suggesting an error where there is none).

 

All suggestions welcome,

SSG-20, 2xADSL interfaces, JunOS 6.1.0r3

PPPoA is set to auto-connect; 30 secs before re-connect

Message Edited by tim13 on 11-06-2008 12:54 PM
Visitor
tim13
Posts: 4
Registered: ‎10-23-2008
0

Re: SSG-20 ADSL-PIM failover ?

Sorry, I am new to Juniper, but for me this (PPPoA/PPPoE teardown + error messages every 3 minutes) is NOT normal!

Can anybody please tell me how to file for an enhancement request with Juniper ? 

 

thanks,

 

I have to live with 480 identical messages per day = 3360 per week = 14448 per month = 1733376 per year

 

2008-11-18 17:21:42 notif PPPoA Tiscali-ADSL connection attempt failed (LCP, CHAP/PAP, IPCP link setup).

2008-11-18 17:21:12 notif PPPoA Tiscali-ADSL started negotiation.

2008-11-18 17:19:41 notif PPPoA Tiscali-ADSL connection attempt failed (LCP, CHAP/PAP, IPCP link setup).

2008-11-18 17:19:11 notif PPPoA Tiscali-ADSL started negotiation.

2008-11-18 17:17:41 notif PPPoA Tiscali-ADSL connection attempt failed (LCP, CHAP/PAP, IPCP link setup).

2008-11-18 17:17:11 notif PPPoA Tiscali-ADSL started negotiation.

2008-11-18 17:15:41 notif PPPoA Tiscali-ADSL connection attempt failed (LCP, CHAP/PAP, IPCP link setup).

2008-11-18 17:15:11 notif PPPoA Tiscali-ADSL started negotiation.

2008-11-18 17:13:40 notif PPPoA Tiscali-ADSL connection attempt failed (LCP, CHAP/PAP, IPCP link setup).

2008-11-18 17:13:10 notif PPPoA Tiscali-ADSL started negotiation.

New User
CraigC
Posts: 1
Registered: ‎02-16-2009
0

Re: SSG-20 ADSL-PIM failover ?

I've got roughly the same situation as the original poster.  I've gotten the Network->Interfaces->Backup primary-backup failover / failback to a point where it happens relatively quickly, but there are real problems to the overall approach.

 

1) I want to know if my backup connection is functioning without manual intervention and testing failover/failback. To monitor this, I need the circuit to be up and responding, even if I'm not sending traffic in that direction.

2) The constant informational alerts for the backup interface are ridiculous.  If the engineers want it to work this way, they should at least incorporate a method of alert suppression for these alerts. Note, I still want to see other informational alerts, just not these.

 

Is there a resolution for this problem?

 

I've opened a case with Juniper, but the person working the case, so far anyway, doesn't seem to understand why this behavior isn't OK.  It seems to me that a better way to handle interface failover is via route preferences / metrics, with both ADSL connections live all the time.  I've tested this and it works great on primary link failure, but the traffic doesn't return to the primary link when the primary link re-establishes itself... which is odd, since the primary route makes it back into the routing table, is preferred, and shows as the active route.  Again, I've got a case open and am awaiting guidance, but if you have experience getting this to work, please share.

Visitor
tim13
Posts: 4
Registered: ‎10-23-2008
0

Re: SSG-20 ADSL-PIM failover ?

I have updated to v6.2.0r1.0 but that has not changed the PPP bouncing. As I have a check-IP interval of 5 minutes, the backup interface reboots it's PPP every 5 mins and receives a new IP from the ISP. As far as I can tell, the only way to fix that is not to use the mini-PIM ADSL but an external ADSL modem connected to ethernet/0. This is not a solution, but rather a work-around to remove PPP from the SSG-20; and move it to a LINKSYS device,

 

I have briefly tried to use both ADSL-PIM's active; it will actually work (kind-of) i.e. both will show up as default routes for 0.0.0.0 - but all packets are passed to the first one. When one interface fails, you will have connectivity issues because of asymmetric routing; so that's not very practical.

 

I also noticed that there are policy issues with the failover. IMHO the SSG-20 has issues with policy timeout (the 6.2.0 release note seems to confirm this); which means that a policy will remain active on a failed interface - i.e. not fail over correctly. In this case (about twice a month) the "clear session dst-ip 11.22.33.44" command will restore my connectivity.

 

One solution may be to define a tunnel and use only one policy on the tunnel (instead of two VIP's on each of the two ADSL-PIM's) - for me this would do the trick because my VoIP server has a static IP.

 

 

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.