Latest update on the following issues: Strangely all the aliases have kicked in and working. There was no restart of the LRP machine and we have no clue what resulted in this sudden change of heart by the machine. All the aliases are available when we tested this morning.
System seems to have gone thru' a gestation period! Our aliases problem is resolved now, all by itself. Thanks --- J Oddissy <[EMAIL PROTECTED]> wrote: > Hello, > > > > http://www.lartc.org/howto/lartc.rpdb.multiple-links.html#AEN268 > > > > We are trying to accomplish the routing for multiple > uplinks/providers. We almost succeeded, except for > our aliases! We have a block of 32 addresses from > two different providers. We are using Bering 1.2. > Following is our etc/network/interfaces file: > > > > #===============Begin /etc/netowk/interfaces > =========================== > auto lo > iface lo inet loopback > > > > auto eth0 > iface eth0 inet static > address 1.2.3.98 > masklen 27 > broadcast 1.2.3.127 > gateway 1.2.3.97 > # Aliases for first ISP > up ip address add 1.2.3.99/27 dev eth0 label eth0:99 > #................THROUGH.............. > up ip address add 1.2.3.126/27 dev eth0 label > eth0:126 > > > > auto eth1 > iface eth1 inet static > address 4.5.6.98 > broadcast 4.5.6.127 > masklen 27 > gateway 4.5.6.97 > # Aliases for second ISP > up ip address add 4.5.6.99/27 dev eth1 label eth1:99 > #................THROUGH.............. > up ip address add 4.5.6.126/27 dev eth1 label > eth1:126 > > > > auto eth2 > iface eth2 inet static > address 7.8.9.98 > masklen 24 > broadcast 7.8.9.255 > > > > ###### SPLIT ACCESS ########################### > up ip route add 1.2.3.98/27 dev eth0 src 1.2.3.98 > table ISP1 > up ip route add default via 1.2.3.97 table ISP1 > up ip route add 4.5.6.98/27 dev eth1 src 4.5.6.98 > table ISP2 > up ip route add default via 4.5.6.97 table ISP2 > > > > #ip route add 1.2.3.96/27 dev eth0 src 1.2.3.98 > #ip route add 4.5.6.96/27 dev eth1 src 4.5.6.98 > #ip route add default via 1.2.3.97 > > > > up ip rule add from 1.2.3.98 table ISP1 > up ip rule add from 4.5.6.98 table ISP2 > > > > up ip route add 7.8.9.0/24 dev eth2 table ISP1 > up ip route add 4.5.6.98/27 dev eth1 table ISP1 > up ip route add 127.0.0.0/8 dev lo table ISP1 > up ip route add 7.8.9.0/24 dev eth2 table ISP2 > up ip route add 1.2.3.98/27 dev eth0 table ISP2 > up ip route add 127.0.0.0/8 dev lo table ISP2 > > > > # Load balancing > up ip route add default scope global nexthop via > 1.2.3.97 dev eth0 weight 1 nexthop via 4.5.6.97 dev > eth1 weight 1 > > > > #===============End /etc/netowk/interfaces > =========================== > > > > Some observations: > 1. 'gateway' setting seems to be playing a major > role > on what aliases work. In desperation we tried > several > of the following combinations. > > > > 2. Main interfaces work in all but one configuration > > and the trouble is only with aliases. > > > > 3. If eth0's gateway alone is set, then all aliases > on > eth0 work, but only 98,99,105,110,112,115,119,125 > work > on eth1, consistently > > > > 4. If the eth1's gateway alone is set, only the main > eth0's interface works and others don't work. For > eth1, > only the above set of aliases works. > > > > 5. If eth0's gateway is set for both eth0 and eth1 > then eth0 aliases all work, but the above set of > aliases of eth1 give out: "Destination Port > Unreachable". > > > > 6. If eth1's gateway is set for both eth0 and eth1 > then > also for eth1 only above set of aliases work, > whereas > for eth0, we get Destinatin Port Unreachable for 108 > and 120, rest get stuck. > > > > 7. If the gateway is set with the respective values, > then nothing (including the main interface) works on > the eth0. For the eth1 again only the above set of > aliases work. > > > > 8. From the LAN (ie internallly) though, > interestingly > all interfaces are pingable! > > > > 9. If the 'gateway' parameter is set, then the load > balancing rule does not kick in. > > > > 10. If gateway parameter is removed from both the > interfaces (eth0 & eth1) then the loading rule is > visible in 'ip route' list and it works( we tested > it using tracetroute), but aliases in both > interfaces > are affected. Only some become available for pings > and others get stuck. > > > > 11. Excepting for some aliases not available, split > access work and if the load balancing rule kicked > in, > that works too. > > > > We are not too concerned about loading balancing > outgoing traffic at this point. Our primary aim is > to > provide split access, which in itself seems to be > working, but only with few aliases available on the > second interface. > > > > Any ideas/suggestions on what we may be doing wrong? > Any pointers or help is appreciated! > > > > Thanks > > > > S.A. > === message truncated === __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click ------------------------------------------------------------------------ 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
