Point-to-Point T1 Configuration

jezg76

A question for any of you fine gentleman or ladies if they do actually exist in IT. Do they???

Anyway, today I helped set up my first real life T1 link at work. Alright, alright, that's enough applause for me. :P

It was 2 2811's in a point-to-point setup. The T1 WIC was this fella:



This, of course, means it has the integrated CSU/DSU. Now, I am well into my 4th month of hardcore CCNA readings and most of my WAN/Serial readings involve demarc => CSU/DSU => Router, with the CSU/DSU providing the clocking. Also, the back-to-back connection with DCE/DTE cables and the DCE side doing the clocking.

Now to the million dollar question...

Does only one side of these point-to-point routers needs to provide the clocking? And, if so, would this config be accurate to have on one side?:

Interface serial 0/0
service-module t1 clock source internal
service-module t1 timeslots 1-24 speed 64                 
service-module t1 framing esf
service-module t1 linecode b8zs
ip address 10.1.1.1 255.255.255.252
encapsulation ppp
fair-que
no shut

Would the other side then look like this?:

Interface serial 0/0
service-module t1 clock source line
service-module t1 timeslots 1-24 speed 64                 
service-module t1 framing esf
service-module t1 linecode b8zs
ip address 10.1.1.2 255.255.255.252
encapsulation ppp
fair-que
no shut

I think I understand the framing, line code, and timeslots, but fair-que is not a friend to Google.

Books make sense until you hit the real world...

Thanks, in advance, for any input!!!

dtlokee

Typically you would set the clock source to line when you're pulling T-1 circuits off the telco, but in a back to back config, one side provides the clock and the other side follows it. The clock source internal tells the router to provide clock.

As for the fair-queue command, this instructs the router to dequeue the packets in a fashon that gives preference to smaller less agressive traffic flows and dequeue them for transmission first. The thinking here is that your time sensitive traffic is typically smaller packets vs flows like file transfers which use large packets.

jezg76

Thanks dt!

I appreciate the response immensely.

One more question if anyone wants to help a fella out with work-related issues.

Subnet 192.168.220.0/24 on FA0/0 on Router 1.
T1 in between.
Subnet 192.168.220.0/24 on FA0/1 on Router 2.

We wanted to try to have connectivity for a clustered app as we move our infrastructure slowly to a new building. Of course, they need to be in the same subnet, but we want to bring over the passive node first, while still having the failover capability of the cluster.

192.168.220.0/24 === R1 +++++++ T1 ++++++++ R2 === 192.168.220.0/24

A fellow at work believes this can happen. Me, on the other hand don't see how without some serious NAT'ing going on.

Although I don't think this will help us, I did find a way to ping from one subnet to the other, but it involved using an ip natting, both inside and out, to resolve the inherent arp issue with a packet coming from an address which resides on a subnet in the router, resulting in all kinds of encapsulation failing ping debugs.

Let's say 192.168.220.53 is on the left from the diagram above. 192.168.220.54 is on the right.

R1(config)#ip nat outside source static 192.168.220.54 172.16.10.2

But, if my thinking is right, this is only half the battle as the source of anything from 192.168.220.53 will still end up on R2 saying, "WTF, I can't arp this!". So...

R1(config)#ip nat inside source static 10.200.0.4 192.168.220.53

10.200.0.0/24 is the subnet for the T1 link.

So, when .53 wants to talk to .54, it has to do it by using 172.16.10.2.

And, this goes for R2, as well for the reverse data flow.

Like I said, this doesn't help my RL situation, but is that proper thinking, in regards to trying to have the same subnet communicate across routers? My god I hope so.

Thanks for listening.

mikej412

jezg76 wrote:

A fellow at work believes this can happen.

Bridge the two Ethernet interfaces over the T1

Humper

^^ Bridging would work.

I hope your colleague was thinking the same thing

networker050184

Unless you have a need for the same subnet to be on both sides I'd just break it into two smaller subnets. I alwasys remeber K.I.S.S. - Keep It Simple Stupid!

phreak

dtlokee wrote:

Typically you would set the clock source to line when you're pulling T-1 circuits off the telco, but in a back to back config, one side provides the clock and the other side follows it. The clock source internal tells the router to provide clock.

Correct you are sir!


I have a new hub and spoke configuration that I am putting in for a customer. Their T's will be running over a private microwave system. This system does not provide clock, so the hub router provides timing, and the spokes pull timing from the 'line'.

jezg76

I thank you all for your input. The bridging of the Ethernet segments worked like a charm. I sure hope that is NP stuff because that isn't in any NA books I've read.

phreak

Yes, this is all NP stuff.


The hub and spoke configuration I am working on actually breaks into the IE level. I feel so special....haha.



Just a fun FWIW I patched a total of 4 t-1's today on a DSx panel with a wire wrap gun. Did all the cross connects, figured out the panel polarity with the bantam jacks, etc all on my own.