On Fri, 3 May 2002, Michael D. Schleif wrote:

> DCD: Special Second External Interface ???
> 
> [1] Summary diagram:
> 
> +-------------------+
> |                   |
> |  Remote Vendor    |
> |  Private Network  |
> |                   |
> +-------------------+
>  Florida ^
>          |
>  Chicago v
> +-----------------------+
> |                       |
> |  ISDN Router          |
> |  Auto Dial, NAT, &c.  |
> |                       |
> +-----------------------+
>     ^ 192.168.14.252
>     |
>     | 192.168.14.0/24
>     |
>     v 192.168.14.254
> +-------------------+
> |  eth1             |       +------------+
> |                   |  T-1  |            |
> |  DCD         wan1 |<----->|  Internet  |
> |                   |       |            |
> |  eth0             |       +------------+
> +-------------------+
>     ^ 192.168.11.254
>     |
>     v
> +------------+
> |            |<- 192.168.10.0/24
> |  Internal  |
> |  Network   |
> |            |<- 192.168.11.0/24
> +------------+
>   ^          ^
>   |          |
>   |          +- 192.168.12.0/24
>   |
>   +- 192.168.13.0/24
> 
> 
> [2] This Chicago DCD user has a fully functioning network -- everything
> below `eth1' in the diagram.
> 
> [3] There is no problem exchanging data with their Florida vendor while
> the T-1 is working.

... through the T-1, so the florida network expects to route packets to
chicago via the T-1, right?

> [4] When the T-1 goes down, Chicago must continue to be able to send
> data to Florida!
> 
> [5] Prior to the T-1, all data exchange was done via ISDN -- so, that is
> already available.
> 
> [6] All that is required to make (initiate?) the ISDN connection is to
> ping the ISDN Router -- while it is powered on ;>
> 
> [7] We are only interested in initiating connection from Chicago --
> one-way.
>
> [8] Since this is point-to-point, firewall rules are not required; but,
> they are highly desirable.

You should decide whether you want masquerading through 192.168.14.254
early on... you may need to hack the firewall/routing yourself either way.
If you don't masq, the routing from the florida end may be more
complicated.  Remember that if you are not using masquerading or default
routes, every router has to know how to route to every other router.

> [9] We should be able to use Andrew Hoying's ifcheck.lrp to
> automatically manage the routing tables -- shouldn't we?

I haven't used it, but it sounds promising.  Nor have I used ISDN.  But I
would guess there is an ifup-type script on the florida end.

> [10] I just spent six (6) hours trying to figure out how to add this
> design for eth1 to this existing DCD -- I am very frustrated!
> 
> [11] How can this design be implemented under these conditions?

I don't know.  But I strongly suspect you will have to get cooperation on
the florida side as far as routing goes.  The fact that you did not
provide any details for that end makes me wonder if you may not be putting
enough energy into completing the circuit from that end.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<[EMAIL PROTECTED]>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]

------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to