Re: Point-to-Point between US and Holland

jkrysinski · ‎08-18-2009

Hi,

I have a point-to-point setup between the US and Holland. Both locations are running integrated VWIC2-1MFT-T1/E1. Both locations are using the line for clocking as directed by the carrier. I am seeing a high rate of crc, abort, and input errors on the Holland side. I am waiting to hear from the provider on the testing of the lines but I have been struggling to get this line fully operational. My fear is that they will come back and say it is an equipment problem but I have replaced all the cables and have used external CSUs with the same results. This is my first attempt at setting up a point-to-point across the pond but my research is pointing at timing for causing the errors and performance degradation. I have attached portions of the configs from both routers. Any help would be greatly appreciated.

paolo bevilacqua · ‎08-18-2009

Your config is correct.

If they come back saying it's your equipment problem, you can reply asking to put a traffic generator for a 48h BER test, and that you will only accept an error rate better than 1 x million (international standard). Make sure you are present on site and are shown the test results first person.

In the meanwhile, your alternative for efficient and economic link between the two site should be an IPsec VPN over high speed circuits.

jkrysinski · ‎08-18-2009

Thank you for the response. My backup link is a IPsec VPN link. We had to go with the high priced point-to-point circuit for contractual reasons. I will keep your advice in mind when I hear back from the provider.

paolo bevilacqua · ‎08-18-2009

It should be worth then to present to the contract underwriters a refresh about telecommunications technologies of the current century.

Good luck and please remember to rate useful posts with the scrollbox below.

jkrysinski · ‎08-18-2009

I agree. The VPN has been very reliable. Something strange I am seeing and was hoping you might have an explanation for it. If I do a continuous ping with -l 1472 I don't get any crc, abort, or input errors. If I browse across this point to point from a Windows machine to another Windows machine the errors start to show immediately. Do you have any theories behind this behavior?

paolo bevilacqua · ‎08-18-2009

Yes, typically packet bursts do trigger circuit faults, while pings being nicely spaced really don't do much in that sense. Anyway, you should be able to ping 1500 bytes per packet before fragmentation occours.

Now, I don't think that is the case, but have you tried setting clock source internal on one side only ?

You can put here "show controllers E1 | T1" if you want.

jkrysinski · ‎08-18-2009

I have tried setting the line source to internal on each side. When I did this I left the other end at line. Attached is my show controllers from both locations.

paolo bevilacqua · ‎08-18-2009

All is good in the last mile so have telco do their tests.

Let us know what they find.

jkrysinski · ‎08-18-2009

I agree. The VPN has been very reliable. Something strange I am seeing and was hoping you might have an explanation for it. If I do a continuous ping with -l 1472 I don't get any crc, abort, or input errors. If I browse across this point to point from a Windows machine to another Windows machine the errors start to show immediately. Do you have any theories behind this behavior?

Joseph W. Doherty · ‎08-18-2009

If you're doing these pings tests from a Windows host, you might want to read: http://support.microsoft.com/kb/314825 ([edit] Although I don't think that's the issue.)

BTW, I agee with the other posters that ping tests don't really stress circuits. For loading the circuit, you might try a traffic generator.

Leo Laohoo · ‎08-18-2009

Hi Paolo,

"If they come back saying it's your equipment problem"

Since when do telco admit they made a configuration error in the first place?

:)

jkrysinski · ‎08-19-2009

Surprise....the provider is saying the line is good. To confuse matters even more the provider is saying that one end of my equipment needs to provide timing. That contradicts what another technician told me.

I was originally told that because this is an International P2P that the line had to provide the timing. I set one end to provide timing but the errors still occur.

And..the facilities manager for the building we are leasing in Holland remembers another client having issues similar to ours. They resolved the problem by moving the router closer to the DMARC. The location of the DMARC from what I have seen in Holland is directly downstairs from where my router sits. This is a two story building. I am waiting to hear back from the provider about them a technician being dispatched to Holland to test the line from the DMARC.

PS - My VPN is still up and running.

paolo bevilacqua · ‎08-20-2009

Hi, have you seen with your own eyes the results of a 72h BER test ? Actually by the way you describe the problem a 5 minutes test would be enough.

If not, don't belive anything telco is saying, and suspend all payments.

The "move the router up and down" is just courtyard talking that you should not care much about.

somsh · ‎08-21-2009

I accept with all above post....

I may sound silly but still I think there could be problem with power supply earthing .... I have also experienced similar issue in past ....

Also suggest to monitor bandwidth .. i.e.,when u r geting CRC error check the bandwidth usage percentage..

Thanks

Som

Wilson Samuel · ‎08-21-2009

Hi Som,

Mostly Datacenters have excellent Grounding/Earthing conditions, unless the power chord's Ground/Earth pin has been removed.

I dont think it may be an issue in this case, however its always good to check the Voltage Ref. between Ground and Neutral (if AC) or between Ground and Negetive (if DC)

Regards

Wilson Samuel