OpenBSD Journal

Developer Blog: todd: T1 art(4)

Contributed by todd on from the it-just-works dept.

Most people using OpenBSD are familiar with either using ethernet devices or dialup networking via ppp(8). Some even have the pleasure of using pppoe(4) or pppoe(8).

Recently I went from knowing zero about T1 configuration to having a working system using the art(4) (Accoom Networks Artery) T1 card.

A careful read through hostname.if(5) will note that for point-to-point interface like a T1 interface, the dest keyword is useful to setup the remote IP. To add routes beyond the default route in mygate, one must use the '!' to add a route to the remote end using the route(8) command. 
$ cat /etc/hostname.art0
inet 1.2.3.81 0xfffffffc
dest 1.2.3.82
media T1
timeslot 1-24
!route -qn add 1.2.5.8/29 1.2.3.82
$ ifconfig art0
art0: flags=8051 mtu 1500
        timeslot: 1-24
        media: TDM t1
        status: active
        inet 1.2.3.81 --> 1.2.3.82 netmask 0xfffffffc 
        inet6 fe80::213:20ff:fedc:94fe%art1 ->  prefixlen 64 scopeid 0x2
$

This permitted an OpenBSD system to replace an aging cisco system with only a few seconds of downtime to move the cable and change some routes. The client only knew we were testing some new equipment and has no idea as to the details of the new equipment. Equally interesting is the fact that there have been no complaints from this client with the connection in the last several months of its operation.

Great news, considering the art(4) driver was committed in the middle of August, 2005 by claudio@ who also happens to work for the company making the card. Imagine that, OpenBSD hardware drivers supported by a company making hardware. Great news indeed ;-)

Now, if there is ever any question as to what is going on, since this is a regular network interface in OpenBSD, one can use standard utilities such as tcpdump to examine network traffic.

One thing I did discover, much to my dismay, is that in the US we have T1s with 24 channels of 64k each. In Europe it is common to have E1's which have 32 channels of 64k each. Ugh!

Caveats:

  • Redundancy department need not apply, it is not possible to have a redundant T1 router.
  • There has not yet been a sub/virtual interface for T1's coded. This means that only one interface is possible per T1 card currently. Should such a virtual interface be coded, it would permit up to 24 sub interfaces per T1 or 32 per E1.

I would write more, but what more is there to write? It just 'works', like it should.

(Comments are closed)

Comments

  1. By Justin (216.17.68.210) on

    Awesome. route(4) is not too helpful in this case, might want to try route(8)

    If I ever have a need to get a T1 up myself I will definitely take a look at this hardware.

    Comments

    1. By Anonymous Coward (202.6.138.33) on

      Interesting that "man route" on an OpenBSD box brings up route(8), whereas http://www.openbsd.org/cgi-bin/man.cgi?query=route brings up route(4).

    2. By Todd T. Fries (66.210.111.62) todd@openbsd.org on http://todd.fries.net/

      Thanks for the catch. I've now fixed the route vs route(8) link to point to the right man page.

  2. By Anonymous Coward (70.109.50.2) on

    Could someone please post information on where and how to buy these T1 cards? The manufacturer appears to be pretty stealthy.

    Comments

    1. By Oneiros (84.245.178.238) martin@oneiros.de on www.oneiros.de

      Googling helps: Wim sells them.

      Comments

      1. By Dameon (68.227.166.222) on

        Here is what appears to be their main page for this card
        http://www.accoom.net/accoom-flyer.pdf

      2. By Anonymous Coward (159.93.100.69) on

        > Googling helps: Wim sells them.

        I can't find any page to order it. :(

  3. By yo2lux (82.79.81.6) on

    Great article Todd !

  4. By Lars Hansson (203.65.246.6) on

    "Redundancy department need not apply, it is not possible to have a redundant T1 router."

    Why not? Please elaborate.

    Comments

    1. By Todd T. Fries (66.210.111.62) todd@openbsd.org on http://todd.fries.net/

      With a T1, just like a DSL line, or a phone line, unlike ethernet,
      you have a point-to-point link between one device and another device
      via a copper pair. It is my understanding that you cannot have two devices active on one end and expect things to work properly. You may have a standby system and physically move the cable from one system to another, but that is hardly CARP/redundancy. If someone knows differently please speak up, but this is my understanding.

      Comments

      1. By Anonymous Coward (134.58.253.131) on

        You cannot attach 2 devices on each side to a single T1 line. You can however use two T1's, both with seperate terminating equipment (running OpenBSD with CARP for example) in parallel.

    2. By Anonymous Coward (66.39.191.42) on

      The poster never heard of "BGP" or "OSPF"

    3. By Anonymous Coward (195.245.251.18) on

      > "Redundancy department need not apply, it is not possible to have a redundant T1 router."
      >
      > Why not? Please elaborate.
      >

      Does anyone know if OpenBSD supports T1 bonding via multilink PPP or perhaps the frame-relay protocol? We use this method currently with Cisco routers to provide a measure of redundancy by ordering 2 P2P T1s with different local loops between two sites. Once bonded, the failure of one T1 means the 2nd will continue to carry traffic. Not too helpful if you have more than 1 T1 worth of bandwidth usage, but aggregation of bandwidth can still be considered a perk of this method.

      Comments

      1. By andrew fresh (66.185.224.6) andrew@mad-techies.org on http://openbsd.somedomain.net

        Does anyone know if OpenBSD supports T1 bonding via multilink PPP or perhaps the frame-relay protocol?

        Unfortunatly at this time "sppp(4) does not support multilink ppp." Although it would be really kewl!

        We use this method currently with Cisco routers to provide a measure of redundancy by ordering 2 P2P T1s with different local loops between two sites. Once bonded, the failure of one T1 means the 2nd will continue to carry traffic. Not too helpful if you have more than 1 T1 worth of bandwidth usage, but aggregation of bandwidth can still be considered a perk of this method.

        I was hoping to do this as well, I had to use route-to to do the load balancing. At some point I need to make ifstated insert and remove that rule so if one line goes down it doesn't try to route-to that line. However, it has not been enough of a problem to be a priority at this point.

        You can have a look at the end of my thread about this on misc@

  5. By Abe Al-Saleh (70.98.186.20) alsaleha@gmail.com on

    Redundancy need not apply? Do you need smacking with a cluestick or what? What do you think routing protocols were invented for? It's entirely possible to have a redundant t1 router setup under openbsd. In my case, I not only have redundant routers and T1s, I also have redundant upstreams.

    Comments

    1. By phessler (209.204.157.100) on

      How do you get a single T1 drop split between two routers? Not both active at the same time, but a CARP style master/slave. That is the redundancy todd is talking about. 

      t1 from telco
    |
    |
  ----- ???
  |   |
  |  router2
router1

      Comments

      1. By Anonymous Coward (134.58.253.131) on

        This would only be possible by replugging the cable. That just means having spare equipment on-site, which will lower the MTTR, but manual intervention is still required.

        Replugging the cable could also be automated by building (or buying, if anyone produces such things) a relay-controlled electronic switch. This could for example be a microcontroller-based device which listens to heartbeat signals from both routers, and "plugs" the T1 into the other router when one dies. On the routers themselves, you could use CARP to do the rest. Of course this cable-switching-device is a nice single point of failure... But as such a device is way simpler than a router, it may improve overall reliability. Would surely be a nice project :-)

      2. By Lars Hansson (203.65.246.6) on

        Naturally you cant get redundancy with only one physical line (this is the same for ethernet) but what if you have 2 T1/E1's on one box?

      3. By Anonymous Coward (205.188.116.73) on


        Most isp's drop the circuits into their routes on channelized cards, like STM-1/STM-4 (OC-3/OC-12), some routers and line cards support
        SDH/SONET MSP protection on circuits and can move the IP endpoint
        to the active circuit, even between routers.

        So yes, you can drop one circuit on two different routers.

        That beeing said, two separate circuits and BGP is usually preferred,
        lower port cost and complexity for the ISP, and it works on all
        hardware.

        /Tony S

    2. By Amir Mesry (66.23.227.241) sully@tierpath.com on

      So you have 2 T1's and are using the same ISP, are you doing load balancing and Redundancy, or just Redundancy? I am interested to know.

      Comments

      1. By Daniel Ouellet (66.63.10.94) daniel@presscom.net on

        You don't need to setup backup, it's a waist really, specially if that's from the same ISP. What I do is configuring my router using ppp multilink like this below and the good advantage of it is that you have backup if you like, but better as both T1 really are use at the same time and they share the load totally as well on per packets basic and it's even traffic betweem them, in and out.

        Very simple to do, however this card at this time doesn't support this multilink but may well come with one very soon, who knows.

        Cisco simple example or multilink setup, all data extracted, only the relevant part kept in place and obviously the IP's are changed too. (:>

        This is the customer side and obviously, you can then figure out the ISP side after that. If needed I could provide it, but it's good for the reader. Only restriction obviously here is that the customer T1's needs to come out of the same pop, same router as well as the same chanalize DS3 too.

        So, this provide you backup if you like as it doesn't matter if one T1 goes dead, the other one keep going. Obviously if the DS3 side goes dead, then you are out of luck, but almost every time there is a problem, it's always on the T1 side and in most case it was when a tech was send to do work in that phone closet, or neighborhood box, etc. Or in some case I have seen a few years ago, a mouse family took home in the box. (:>

        Other then that, you have a nice setup and take advantage of the merge speed of both T1's as well as having built in backup capability, but that's all you can do.

        There is no way to connect two routers to the same T1's at the same time. You end up with signaling problems.

        Daniel

        ==============


        interface Multilink1
        description Combine multi-link T1's connection to PressCom Internet
        ip address 1.1.1.2 255.255.255.252
        ip access-group inbound in
        ip access-group outbound out
        no ip redirects
        no ip proxy-arp
        ip route-cache policy
        no cdp enable
        ppp multilink
        ppp multilink fragment delay 10
        ppp multilink interleave
        ppp multilink group 1
        service-policy input Set-DSCP
        service-policy output QoS-Policy

        ...

        interface Serial0
        description Multi-link connection T1's #1 to PressCom Internet
        no ip address
        encapsulation ppp
        no cdp enable
        ppp multilink
        ppp multilink group 1
        !
        interface Serial1
        description Multi-link connection T1's #2 to PressCom Internet
        no ip address
        encapsulation ppp
        no cdp enable
        ppp multilink
        ppp multilink group 1

        ...

        ip route 0.0.0.0 0.0.0.0 Multilink1 1.1.1.1

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]