Is your router set to use DHCP to get a connection or PPPoE?
By default these units are set up to connect to your ISP by DHCP. Mine connected right away but I changed to PPPoE immediately on setting the unit up. The connection may be timing out from inactivity if you are using DHCP. ADSL usually requires a change to PPPoE for connecting. You should have received login credentials for your account from Teksavvy (I use Bell).
Login to your router ( default: http://192.168.1.1) and go to setp/WAN. Check what internet connection type you are using. If your are using DHCP change to PPPoE you get some additional options. Enter your user credentials and check off the keep alive radio button. Save the configuration changes and your router should reboot. That should keep your connection from timing out.
I took a look at the modem manual. There is a keep alive checkbox in the configuration settings for PPPoE. Is that checked off? There is also a dial on demand checkbox. Make sure that at least one of them is checked off so that your connection stays alive or at least dials back out if you go to the internet. If the screen shots in the manual show the defaults for PPPoE then neither one is checked off by default and once the connection drops it won't reconnect without repowering the modem.
The only other suggestion that I have is to take the Cisco router out of the equation and see if it is the culprit or not and then work from there. If it still drops after that it is the modem or Bell's switch.
Here is something else to consider, that I recall from my PPP link days.
In simple terms PPP over Ethernet behaves pretty much exactly like PPP, just some extra packets such as PADx packets.
PPP used keep alives packets to detect if the PPP link is up or down are sent out usually every ten seconds.
These keep alives are in the form of PPP Link Control protocol (LCP) echo request and echo-replies.
These LCP link control packets also compete with other data WAN traffic going over the PPPoE link.
If the WRVS4400N doesn't get responses to the LCP echo requests.
RFC2516 suggests "It is RECOMMENDED that the Access Concentrator ocassionally send
Echo-Request packets to the Host to determine the state of the session.
Otherwise, if the Host terminates a session without sending a Terminate-Request packet,
the Access Concentrator will not be able to determine that the session has gone away."
Usually on a PPP link both sides, service providers Access Concentrator and the WAN router will send echo requests and expect a echo-reply.
After a couple of echo-replies have been dropped, maybe due to competition against incoming data, full buffers, tail drop (whatever the reason), the router will send a LCP terminate request. My router thinks the link must be down and it is wasting it's time sending packets out over the down link. Which may explain what the service provider is saying we are sending, a LCP terminate request..we think the link is down and are terminating the PPP link.
This really isn't a bad situation, to me it suggests the router thinks that the link is down and will re-initiate a PPPoE session
and bring the link up again.
I don't think you can expect PPP links to be up 100 percent of the time, especially at times when the link is very busy. Unless the WRVS4400N log is showing something else at the time of PPPoE session failure, why is this problem of concern ?
Or is the cause of the problem the xDSL copper link itself, whereby Low level PPPoE packets are being lost due xDSL synchronization issues between the modem and the DSLAM. ( something to consider). Higher level TCP packets will retry if a packet gets lost. A wireshark capture may show this happening. If you see lots of TCP retry packets in a capture, maybe packets are getting dropped over the xDSL link. It's a possibility
I don't know if this makes a difference or not but the D-Link unit isn't just a modem. It is also a firewall and does the authentication as well. The Cisco unit is the "same" less the DSL modem. So which one is actually making the connection. If the Cisco WAN port is plugged into the LAN connection of the modem are they both competing for control of the connection by trying to connect simultaneously. If you want to use the Cisco router to its stated potential you should disable all of the functionality of the D-Link and just let it connect to the station as a modem (I don't know if that is possible). Let the Cisco do the authentication and firewall work. Right now it looks like it is might just be a fancy access point. If you just want to use it like that plug it into a LAN port.
Hi every one!!!When you are configuring a remote VPN connection, there
are some steps that are lost on the path. Here you can see those steps.
A) In your Cisco device: 1. Ensure you don´t have any rule denying the
traffic between the device and the remote...
** Update **These and a number of other issues have been addressed in
SRP520 MR3. Please see https://supportforums.cisco.com/docs/DOC-13853
for details on how to access this code.There have been a number of
reports of the SRP500 becoming unresponsive afte...
STANDARDSOURCECOMMENTSEthernet RJ-45 connector pin number12345678IEEE
802.3afusing data pairsRXDC+RXDC+TXDC-sparespareTXDC-sparespareIndustry
Standard for Embedded POE(used by Cisco Catalyst Switches)IEEE
802.3afusing spare pairs RXRXTXDC+DC+TXDC-DC-Indus...