EHWIC-4G-LTE Randomly loses IP address after a week or two of operation

[Matthew Millman]

I have one of these cards, configured like this:

interface Dialer1
 ip address negotiated
 no ip unreachables
 ip nat outside
 ip virtual-reassembly in
 dialer pool 2
 dialer idle-timeout 0
 dialer string lte
 dialer persistent
 no cdp enable

interface Cellular0/0/0
 no ip address
 ip nat outside
 ip virtual-reassembly in
 encapsulation slip
 dialer in-band
 dialer pool-member 2
 async mode interactive

It mostly works fine, but every week or two it stops passing traffic, when I check the interfaces - I see this:

# show ip int brief
Dialer1 0.0.0.0 YES IPCP up up

All I have to do to fix it is this:

# clear interface dialer1

And then we're back in business again.

How would I make it automatically sort its self out when it loses its IP address?

[Spooster IT Services]

Hi Matthew Millman,

Try the following configuration to configure Always-On Connection

interface dialer1
dialer watch-group 1

!

dialer watch-list 1 ip 5.6.7.8 0.0.0.0
dialer watch-list 1 delay route-check initial 60
dialer watch-list 1 delay connect 1

[Matthew Millman]

That is interesting looking. Not quite sure if it'd work for me though. In my case it is a second WAN interface.

Whatever I entered as the ip/mask would likely always be reachable through the primary connection, and I can only assume this wouldn't work.

When I do a 'show ip route' I do see there is one route, for the IP of Dialer1 its self:

# show ip route

C x.x.x.x/32 is directly connected, Dialer1

# dialer watch-list 1 ip x.x.x.x 255.255.255.255

So I've put the dialer watch on that. Fingers crossed that is good enough.

[Spooster IT Services]

dialer watch-list 1 ip 5.6.7.8 0.0.0.0

The route above is the dummy route. It should not be mandatory to be in routing table you can use the command as it is above.

[Matthew Millman]

Okay, have put it in as you stated

If you don't mind me asking, how is watching for a route that will never exist a mechanism for testing if the connection is OK?

[Spooster IT Services]

Hi Matthew,

Monitoring the watched routes is done in the following sequence:

1. Whenever a watched route is deleted, Dialer Watch checks whether there is at least one valid route for any of the defined watched IP addresses.

2. If no valid route exists, the primary line is considered down and unusable.

3. If a valid route exists for at least one of the defined IP addresses and if the route is pointing to an interface other than the backup interface configured for Dialer Watch, the primary link is considered up.

4. If the primary link goes down, Dialer Watch is immediately notified by the routing protocol and the secondary link is brought up.

5. Once the secondary link is up, at the expiration of each idle timeout, the primary link is rechecked.

6. If the primary link remains down, the idle timer is indefinitely reset.

7. If the primary link is up, the secondary backup link is disconnected. Additionally, you can set a disable timer to create a delay for the secondary link to disconnect, after the primary link is reestablished.

In our case we want that backup as Always-On Connection. So Dialer will check the routing table for this dummy route (5.6.7.8 0.0.0.0) and it will not find that route in table and assume that primary link is down and remain always on.

Hope this will help you to understand....

[Matthew Millman]

Okay I get it

Just final question: Why doesn't 'dialer persistent' do this?

[Spooster IT Services]

"Dialer persistent" also do the same thing to keep the dialer Always-On but it has some odd behaviour with LTE. This is what i have experienced so far with all our LTE setups. Is there any specific reason to configure Dialer interface? I have done the following setup and it is working fine:-

no interface Dialer1

interface Cellular0/0/0
ip address negotiated
ip nat outside
ip virtual-reassembly in
encapsulation slip
dialer in-band
dialer idle-timeout 0
dialer enable-timeout 1
dialer string lte
dialer watch-group 1
async mode interactive
pulse-time 0

!

dialer watch-list 1 ip 5.6.7.8 0.0.0.0
dialer watch-list 1 delay route-check initial 60
dialer watch-list 1 delay connect 1

[Matthew Millman]

"dialer persistent" is the very reason I configured a dialer interface.

If it turns out it is worthless on LTE - I would take pride in removing it.

[Matthew Millman]

From a little more experimentation of this - I don't think there is any difference between 'dialer persistent' and dialer watch. They both do the same thing perfectly well.

In my case, there is a more fundamental problem. With chat debug on, I get a lot of this when it's failing:

CHAT0/0/0: Expecting string: OK

CHAT0/0/0: Timeout expecting: OK

So both 'dialer persistent' and 'dialer watch' are dong the job they're supposed to do.

Another thing I've noticed is that it's flipping between UMTS and LTE an awful lot. Eventually needing to be reset before it'll work again.

The big long piece of RG-58 I have running between the card and external antenna isn't doing it a lot of favours, attenuating 2.6GHz LTE, to the extent where it's falling back to UMTS many times a day.

Now running another test with the router in a more suitable place with its antenna connected directly.

[Matthew Millman]

My conclusion on this issue is:

My original setup had the router inside a steel rack, with a 10(ish) metre piece of RG58/U leading to an external antenna. This cable performs poorly at 2.6GHz, meaning that 4G connectivity was limited, resulting in constant swapping between 3G/4G.

That in its self shouldn't have caused the original issue, but it seems that after a long period of swapping between bands the 4G EHWIC "gives up" and has to be reset (even when signal is restored). I don't know any other workaround under those conditions.

My solution? Stop it from having to switch bands in the first place. I tossed the RG58/U cable and replaced it with LMR400. It's an obnoxiously large and rigid cable, furthermore, TNC connectors for LMR400 aren't particularly easy to get - but, it performs superbly at 2.6GHz and has fixed my problem. I now have a constant uninterrupted 4G service.

[Matthew Millman]

First test was to attach the watch list to the external Dialer interface.

It was unsuccessful. After 3 days I find the Dialer1 interface up/up but with ip address of 0.0.0.0.

I've now changed my config to be the same as yours without the Dialer.

Do find myself wondering if the fact that the interface is still "up/up" is meaning that the dialer watch isn't bothering to do anything when this happens.

We'll see...