From: Michael D. S. <md...@he...> - 2002-05-04 00:52:28
|
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. [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. [9] We should be able to use Andrew Hoying's ifcheck.lrp to automatically manage the routing tables -- shouldn't we? [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? What do you think? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . |