At the time x the router detects interface up/down while the RF link is healthy.
.Feb 15 01:32:25: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down. Feb 15 01:32:35: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to up
.Feb 15 01:32:55: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down
.Feb 15 01:33:05: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to up
At the time x+y the IP connectivity goes down, with the RF healthy.
To regain the IP connectivity we must disconnect and reconnect the coax cable between the Cisco and the Mini-Link!
It can work some days, some weeks or some months ant then the problem re-happen.
We've already wrote to cisco and Ericsson: no problem detected.
Line protocol down is due to the loss of keepalive packets on the cisco. On serial ports a keepalive is send periodically (10 seconds? - I forget). Then the far end (the other router I would imagine and not the Ericsson but I am not sure) sends the keepalive back.
formatting link
describes the keepalive process and "debug serial int" As long as you dont have a large number of interfaces on the router you could leave this running long term I would think without affecting router performance.
you need to arrange to log the debug messages of course.
To troubleshoot first look at the error counters on the interfaces sh int at *both* ends
Also determine if there are other problems with the link.
I would leave a long term ping running on the link to see how it is actually performing.
pingplotter is VERY good. Use full length packets at 1 per second. Also try a full load test with iperf or netperf or ttcp or otherwise.
How are you doing the clocking? Each serial link needs
**exactly** one clock source. Either the ericsson or the Cisco must generate a clock? I do not know if the erricson link simulates a serial link end to end or if it is effectively a bridge that terminates each serial link on it. Understanding this is critical to correct clocking configuration.
On a telco provided serial link it is normal for the telco to provide the clock.
formatting link
Troubleshooting Serial Line Problems
Please post sh int from both ends and the configuration of the serial interfaces. Report on results of long term ping
The Ericsson must have interface stats as well. Find those too.
It may be possible to recover without disconnecting with reset int serial x/x/x
Clocking is provided by the M320 Juniper; the Mini-Link is passive for the clock.
Cisco Interface:
interface Serial1/0 description LINK 34 Mb mtu 1500 ip address X.X.160.202 255.255.255.252 no ip route-cache cef no ip route-cache no ip mroute-cache load-interval 30 dsu bandwidth 34010 dsu mode 1
Juniper Interface:
show configuration interfaces e3-2/1/0 description "* 34Mbps * ; clocking internal; encapsulation cisco-hdlc; e3-options { compatibility-mode kentrox; } unit 0 { family inet { address X.X.160.201/30; } }
Thanks Enrico
"bod43" ha scritto nel messaggio news: snipped-for-privacy@h20g2000yqn.googlegroups.com... > Hello,
Line protocol down is due to the loss of keepalive packets on the cisco. On serial ports a keepalive is send periodically (10 seconds? - I forget). Then the far end (the other router I would imagine and not the Ericsson but I am not sure) sends the keepalive back.
formatting link
the keepalive process and "debug serial int" As long as you dont have a large number of interfaces on the router you could leave this running long term I would think without affecting router performance.
you need to arrange to log the debug messages of course.
To troubleshoot first look at the error counters on the interfaces sh int at *both* ends
Also determine if there are other problems with the link.
I would leave a long term ping running on the link to see how it is actually performing.
pingplotter is VERY good. Use full length packets at 1 per second. Also try a full load test with iperf or netperf or ttcp or otherwise.
How are you doing the clocking? Each serial link needs
**exactly** one clock source. Either the ericsson or the Cisco must generate a clock? I do not know if the erricson link simulates a serial link end to end or if it is effectively a bridge that terminates each serial link on it. Understanding this is critical to correct clocking configuration.
On a telco provided serial link it is normal for the telco to provide the clock.
formatting link
Serial Line Problems
Please post sh int from both ends and the configuration of the serial interfaces. Report on results of long term ping
The Ericsson must have interface stats as well. Find those too.
It may be possible to recover without disconnecting with reset int serial x/x/x
Why is route caching disabled? Without it, you will never even come close to utilizing a 34Mbps circuit and there are only very specific circumstances where this should be disabled (like doing per-packet load-balancing, but you still run into performance issues)
Anyway, the circuit is not your problem because line protocol is going down not the circuit. If you do a show interface on the serial and it will show up/down. This means the circuit is up, but no line protocol. I would suspect that the problem could be the Juniper side. Next time this happens, try doing a shut/no shut on the Juniper side to see if this jump starts the interface to up. You could also try changing the encapsulation to PPP instead of using HDLC.
formatting link
describes the keepalive process and "debug serial int"
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.