🚀 go-pugleaf

>> We ran into a problem when we tried this a year or two ago.  There is a
>> philosophy difference between cisco and Sun on how IP routing over X.25
>> should be done.  cisco routers like to treat an X.25 network as a
>> single multi-point network, where each router has a list of X.121
>> addresses corresponding to the IP addresses for each other router, and
>> will build circuits on demand and close them after an inactivity
>> timeout expires.  (This is similar to the way DDN X.25 operates, I
>> believe.)

This is basically true. If you do not time out your connections on the DDN,
the PSNs (packet switch nodes) will do it for you to reclaim resources.
However I believe they will only do this for DDN Standard which are IP over
X.25 calls.

>> Sun's X.25 over IP implementation, however, likes to treat the X.25
>> network as a collection of permanent point-to-point links, each with
>> its own network or subnet number.  It also insists that one end of
>> each link be responsible for ensuring that the circuit is up at all
>> times.

Provided you do not pay connect time, this is a fine model. Can Sun handle
multiple VCs using the same IP subnet/network number? Or must they be
different?

>> We did get the Sun to talk to the cisco router, but we had these problems:
>> 
>> 1) Since the cisco assumed that each router on the X.25 network
>> was directly connected to each other one, it refused to route an
>> IP packet back over the same X.25 interface it came in on.

We relaxed this restriction in the 8.0 release when we introduced the
concept of routing neighbors for all routing protocols, including IGRP and
RIP. You do something like:

router igrp 666
network 10.0.0.0
neighbor 10.0.0.1
neighbor 10.0.0.2

This will cause the router to send a direct routing update to hosts
10.0.0.1 and 10.0.0.2. Routing updates will still be broadcast too. The
routing code is also smart enough to do split horizon on the neighbor
instead of on the interface. This has the benefit of allowing packets to be
sent out over the same interface they were received without sending a
redirect. Routes learned by neighbors on the same interface will be sent to
the other neighbors on that same interface (but not back to the neighbor
who spoke of them originally).

This gives you the flexibility to have it both ways. Treat the X.25 network
like a big LAN with the assumption that all routers hear one device's
routing updates. Or like a collection of point-to-point lines where you
hand-craft your own routing topology using the neighbor subcommand.

>> 2) The cisco liked to build parallel X.25 circuits to the same destination.
>> Sun's x25manager barfed at this.  I think there might have been a way to
>> disable this on the cisco, but I'm not sure.

The x25 nvc N configuration command will control this. By default N is 1
which should help Sun's software interoperate with ours.

>> 3) The Sun had to take the responsiblity for keeping the circuit up,
>> since it doesn't do circuit building on demand.

We considered having a mode where the circuits come up immediately. However
I have never heard anyone ask for this so I didn't bother. There are plenty
of things to do based on what is asked for.

Greg Satz
cisco