[Vyatta-users] Network connections slow...was: Restricting access to default route
Hi, Okay maybe I should tell the reason I would like to get that default route (with those restrictions) in our Vyatta router. :) As it says in the footer of my e-mail we just moved to a new office. In the old situation we had the following. Switch for the 192.168.1.0/24 network connected to the firewall (192.168.1.2 is the interface on the firewall) Switches for the 192.168.10.0/24 network (internal network) Servers who would need a connection to the internet (ie. mail servers, http proxy etc.) have an extra network card connected to the 192.168.1.0/24 switch. Servers who don't need a connection to the internet and all client PC's on the network are connected to the 192.168.10.0/24 switch. Now that we are in the new office I used a Soekris machine with 3 network interfaces. eth0 = 192.168.1.1 for the 192.168.1.0/24 network eth1 = 192.168.10.1 for the 192.168.10.0/24 network eth2 = 192.168.254.2 for the 192.168.254.0/24 network The switches are still there for the 192.168.1.0/24 network so the servers who need a direct internet connection are on that switch. Some connections in our network are very slow at the moment and the only new factor is the Vyatta router. An ssh session to a server takes a long time, when I put a default route that sets the next-hop to the firewall interface 192.168.1.2 then evertything is fast again even the windows servers seem to respond quicker. Take the default route out and everything slows down again. Even starting a VMware console on my PC is quicker with that default. Without that route starting the VMware console manager takes ages to even start up, let alone starting a virtual machine on my PC. Problem with that default route is that any PC on the 192.168.10.0/24 network can get to the firewall and that is not something we like. Hence the idea to put restrictions on the which machines can use that default route. Maybe someone has been in this situation before and could point me to a thread about this subject so I can study it more. Thnx in advance. SeeYa, Michel Wij zijn verhuisd naar een pand aan het Surinameplein. Ons bezoekadres is niet langer Jacques Veltmanstraat 463, maar SURINAMEPLEIN 122, 1058 GV Amsterdam. Alle overige gegevens zoals telefoonnummers, faxnummer, postadres zijn ongewijzigd. We moved to a new office. Our visiting address changed from Jacques Veltmanstraat 463 to SURINAMEPLEIN 122, 1058 GV Amsterdam, the Netherlands. All our other contact details such as phone and fax numbers and mail address will remain the same. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] Possible OSPF problems
I think I have a problem with some OSPF routing. I have a small
network setup (see attached image) which uses 2 OSPF areas, with 3
subnets. I have a LAN subnet (192.168.10.0/23, Area 0.0.0.1) and a
DMZ subnet (172.20.0.0/23, Area 0.0.0.0) and a public subnet which is
not configured using OSPF.
I can connect and ping nodes from LAN -- DMZ no problem and can
also ping from DMZ - Public no problem. But when I try to ping
and connect to machines within my own public range LAN - Public
I have some connectivity issues. Pings will take a while and time
out, then eventually (2 - 10 seconds) it's like OSPF has figured how
to get there and they works. If them hosts then have not been
contacted in a while since it started working, I have the ping and
connectivity problems again.
Does anyone have any idea where I might be going wrong here?
protocol config for the both internal routers below with respective
OSPF and routing tables. If you need further information please let
me know.
Thank for the help.
---
protocols {
ospf4 {
router-id: 10.1.1.1
rfc1583-compatibility: false
ip-router-alert: false
area 0.0.0.0 {
area-type: normal
interface eth1 {
link-type: broadcast
address 172.20.1.251 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
area 0.0.0.1 {
area-type: normal
interface eth0 {
link-type: broadcast
address 192.168.11.253 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
}
static {
disable: false
}
}
Routes: 8/8, Paths: 8/8
0.0.0.0/0[ospf(1)] to 172.20.1.253via eth1
10.1.1.1/32[connected(0)] to 10.1.1.1
via lo
10.1.1.3/32[ospf(2)] to 172.20.1.253via eth1
10.1.1.4/32[ospf(2)] to 172.20.1.252via eth1
127.0.0.0/8[connected(0)] to 127.0.0.1
via lo
172.20.0.0/23[connected(0)] to 172.20.1.251
via eth1
192.168.10.0/23[connected(0)] to
192.168.11.253via eth0
192.168.11.254/32[connected(0)] to 192.168.11.254
via eth0
protocols {
ospf4 {
router-id: 10.1.1.2
rfc1583-compatibility: false
ip-router-alert: false
area 0.0.0.0 {
area-type: normal
interface eth1 {
link-type: broadcast
address 172.20.1.250 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
area 0.0.0.1 {
area-type: normal
interface eth0 {
link-type: broadcast
address 192.168.11.252 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
}
static {
disable: true
}
}
Routes: 7/7, Paths: 7/7
0.0.0.0/0[ospf(1)] to 172.20.1.253via eth1
10.1.1.2/32[connected(0)] to 10.1.1.2
via lo
10.1.1.3/32[ospf(2)] to 172.20.1.253via eth1
10.1.1.4/32[ospf(2)] to 172.20.1.252via eth1
127.0.0.0/8[connected(0)] to 127.0.0.1
via lo
172.20.0.0/23[connected(0)] to
[Vyatta-users] (no subject)
We need traceroutes and other info, but like state above what's the host configuration look like? I was thinking it could have been an ip_forward issues but you claim one network block able to connect outbound, so ip_forwarding doesn't seem to be any issue. I know this seem obvious but make sure not local firewall are enable on the hosts . ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] Transparent IP Mapping
I currently have a Netopia R910 supporting my network. My ISP has provided me with a /29 subnet. The Netopia permits these additional IP Addressed to be behind my R910 through what they call Transparent IP Mapping. These IP addressed live on the same switch as my 10.x.x.x/24 network. Does the Vyatta permit this? From what I've read, the VLAN looks like it will work, but some clarification would be appreciated. Here is the text from Netopia's site on the Transparent IP Mapping: If your ISP has assigned you multiple static IP addresses you may want to have one or more of these IP's assigned directly to hosts or servers behind the Netopia with NAT enabled. If you want to place a public IP onto the local workstation, (i.e. not a 192.168.1.x address), then this Quick Guide will take you through this process step-by-step. How this is done will be determined by the type of routing (or bridging) handled from the ISP. The IP's can be routed to the Ethernet interface of the router, or be bridged to you on the WAN interface. This configuration will transparently map your public IP addresses in a way that will allow you to configure workstations behind the router to hold these public IP addresses and make them publicly accessible, bypassing the NAT process on this secondary subnet. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Possible OSPF problems
If you're pinging public - public, it's the same subnet, which means the
devices are communicating directly, and not even going through the router,
so OSPF shouldn't be an issue.
Trace a traceroute from one of the devices in question, or see if you can
get a packet capture. COULD be a switch, spanning tree issue, interface
configuration mismatch or . . .
Best,
Justin
On Feb 6, 2008 5:05 AM, Joe Pub [EMAIL PROTECTED] wrote:
I think I have a problem with some OSPF routing. I have a small
network setup (see attached image) which uses 2 OSPF areas, with 3
subnets. I have a LAN subnet (192.168.10.0/23, Area 0.0.0.1) and a
DMZ subnet (172.20.0.0/23, Area 0.0.0.0) and a public subnet which is
not configured using OSPF.
I can connect and ping nodes from LAN -- DMZ no problem and can
also ping from DMZ - Public no problem. But when I try to ping
and connect to machines within my own public range LAN - Public
I have some connectivity issues. Pings will take a while and time
out, then eventually (2 - 10 seconds) it's like OSPF has figured how
to get there and they works. If them hosts then have not been
contacted in a while since it started working, I have the ping and
connectivity problems again.
Does anyone have any idea where I might be going wrong here?
protocol config for the both internal routers below with respective
OSPF and routing tables. If you need further information please let
me know.
Thank for the help.
---
protocols {
ospf4 {
router-id: 10.1.1.1
rfc1583-compatibility: false
ip-router-alert: false
area 0.0.0.0 {
area-type: normal
interface eth1 {
link-type: broadcast
address 172.20.1.251 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
area 0.0.0.1 {
area-type: normal
interface eth0 {
link-type: broadcast
address 192.168.11.253 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
}
static {
disable: false
}
}
Routes: 8/8, Paths: 8/8
0.0.0.0/0[ospf(1)] to 172.20.1.253via eth1
10.1.1.1/32[connected(0)] to 10.1.1.1
via lo
10.1.1.3/32[ospf(2)] to 172.20.1.253via eth1
10.1.1.4/32[ospf(2)] to 172.20.1.252via eth1
127.0.0.0/8[connected(0)] to 127.0.0.1
via lo
172.20.0.0/23[connected(0)] to 172.20.1.251
via eth1
192.168.10.0/23[connected(0)] to
192.168.11.253via eth0
192.168.11.254/32[connected(0)] to 192.168.11.254
via eth0
protocols {
ospf4 {
router-id: 10.1.1.2
rfc1583-compatibility: false
ip-router-alert: false
area 0.0.0.0 {
area-type: normal
interface eth1 {
link-type: broadcast
address 172.20.1.250 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
area 0.0.0.1 {
area-type: normal
interface eth0 {
link-type: broadcast
address 192.168.11.252 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
Re: [Vyatta-users] Possible OSPF problems
Ah - my mistake in terminology translation :-)
Since is IS running through the router, turn on tshark on one of the
router interfaces, see what's on the (virtual) wire when you start a ping.
Does the router even see it inbound through the virtual switch?
Justin
On Feb 6, 2008 5:05 AM, Joe Pub [EMAIL PROTECTED] wrote:
I think I have a problem with some OSPF routing. I have a small
network setup (see attached image) which uses 2 OSPF areas, with 3
subnets. I have a LAN subnet (192.168.10.0/23, Area 0.0.0.1) and a
DMZ subnet (172.20.0.0/23, Area 0.0.0.0) and a public subnet which is
not configured using OSPF.
I can connect and ping nodes from LAN -- DMZ no problem and can
also ping from DMZ - Public no problem. But when I try to ping
and connect to machines within my own public range LAN - Public
I have some connectivity issues. Pings will take a while and time
out, then eventually (2 - 10 seconds) it's like OSPF has figured how
to get there and they works. If them hosts then have not been
contacted in a while since it started working, I have the ping and
connectivity problems again.
Does anyone have any idea where I might be going wrong here?
protocol config for the both internal routers below with respective
OSPF and routing tables. If you need further information please let
me know.
Thank for the help.
---
protocols {
ospf4 {
router-id: 10.1.1.1
rfc1583-compatibility: false
ip-router-alert: false
area 0.0.0.0 {
area-type: normal
interface eth1 {
link-type: broadcast
address 172.20.1.251 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
area 0.0.0.1 {
area-type: normal
interface eth0 {
link-type: broadcast
address 192.168.11.253 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
}
static {
disable: false
}
}
Routes: 8/8, Paths: 8/8
0.0.0.0/0[ospf(1)] to 172.20.1.253via eth1
10.1.1.1/32[connected(0)] to 10.1.1.1
via lo
10.1.1.3/32[ospf(2)] to 172.20.1.253via eth1
10.1.1.4/32[ospf(2)] to 172.20.1.252via eth1
127.0.0.0/8[connected(0)] to 127.0.0.1
via lo
172.20.0.0/23[connected(0)] to 172.20.1.251
via eth1
192.168.10.0/23[connected(0)] to
192.168.11.253via eth0
192.168.11.254/32[connected(0)] to 192.168.11.254
via eth0
protocols {
ospf4 {
router-id: 10.1.1.2
rfc1583-compatibility: false
ip-router-alert: false
area 0.0.0.0 {
area-type: normal
interface eth1 {
link-type: broadcast
address 172.20.1.250 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
area 0.0.0.1 {
area-type: normal
interface eth0 {
link-type: broadcast
address 192.168.11.252 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
}
static {
disable: true
}
}
Routes: 7/7, Paths: 7/7
Re: [Vyatta-users] Possible OSPF problems
On 06/02/2008, Justin Fletcher [EMAIL PROTECTED] wrote:
Ah - my mistake in terminology translation :-)
Since is IS running through the router, turn on tshark on one of the
router interfaces, see what's on the (virtual) wire when you start a ping.
Does the router even see it inbound through the virtual switch?
Well after doing some tcpdump's on either side of each router it looks
like the ping requests are getting through all the way to the public
side and are not responding. So there must be a routing issue within
the public side not coming back. I guess I will have to investigate
further.
Thanks for your help.
Justin
On Feb 6, 2008 5:05 AM, Joe Pub [EMAIL PROTECTED] wrote:
I think I have a problem with some OSPF routing. I have a small
network setup (see attached image) which uses 2 OSPF areas, with 3
subnets. I have a LAN subnet (192.168.10.0/23, Area 0.0.0.1) and a
DMZ subnet (172.20.0.0/23, Area 0.0.0.0) and a public subnet which is
not configured using OSPF.
I can connect and ping nodes from LAN -- DMZ no problem and can
also ping from DMZ - Public no problem. But when I try to ping
and connect to machines within my own public range LAN - Public
I have some connectivity issues. Pings will take a while and time
out, then eventually (2 - 10 seconds) it's like OSPF has figured how
to get there and they works. If them hosts then have not been
contacted in a while since it started working, I have the ping and
connectivity problems again.
Does anyone have any idea where I might be going wrong here?
protocol config for the both internal routers below with respective
OSPF and routing tables. If you need further information please let
me know.
Thank for the help.
---
protocols {
ospf4 {
router-id: 10.1.1.1
rfc1583-compatibility: false
ip-router-alert: false
area 0.0.0.0 {
area-type: normal
interface eth1 {
link-type: broadcast
address 172.20.1.251 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
area 0.0.0.1 {
area-type: normal
interface eth0 {
link-type: broadcast
address 192.168.11.253 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
}
static {
disable: false
}
}
Routes: 8/8, Paths: 8/8
0.0.0.0/0[ospf(1)] to 172.20.1.253via eth1
10.1.1.1/32[connected(0)] to 10.1.1.1
via lo
10.1.1.3/32[ospf(2)] to 172.20.1.253via
eth1
10.1.1.4/32[ospf(2)] to 172.20.1.252via
eth1
127.0.0.0/8[connected(0)] to 127.0.0.1
via lo
172.20.0.0/23[connected(0)] to 172.20.1.251
via eth1
192.168.10.0/23[connected(0)] to
192.168.11.253via eth0
192.168.11.254/32[connected(0)] to 192.168.11.254
via eth0
protocols {
ospf4 {
router-id: 10.1.1.2
rfc1583-compatibility: false
ip-router-alert: false
area 0.0.0.0 {
area-type: normal
interface eth1 {
link-type: broadcast
address 172.20.1.250 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
area 0.0.0.1 {
area-type: normal
interface eth0 {
link-type: broadcast
address 192.168.11.252 {
Re: [Vyatta-users] Transparent IP Mapping
Yes, the Vyatta will do this - with a LOT more control. Your Netopia is doing NAT for you; if you want it, you'll be able to configure it. By default, of course, NAT isn't configured on the Vyatta, so you'll have to set it up to get the results you want. Best, Justin On Feb 6, 2008 7:42 AM, Rob Menzies [EMAIL PROTECTED] wrote: I currently have a Netopia R910 supporting my network. My ISP has provided me with a /29 subnet. The Netopia permits these additional IP Addressed to be behind my R910 through what they call Transparent IP Mapping. These IP addressed live on the same switch as my 10.x.x.x/24 network. Does the Vyatta permit this? From what I've read, the VLAN looks like it will work, but some clarification would be appreciated. Here is the text from Netopia's site on the Transparent IP Mapping: If your ISP has assigned you multiple static IP addresses you may want to have one or more of these IP's assigned directly to hosts or servers behind the Netopia with NAT enabled. If you want to place a public IP onto the local workstation, (i.e. not a 192.168.1.x address), then this Quick Guide will take you through this process step-by-step. How this is done will be determined by the type of routing (or bridging) handled from the ISP. The IP's can be routed to the Ethernet interface of the router, or be bridged to you on the WAN interface. This configuration will transparently map your public IP addresses in a way that will allow you to configure workstations behind the router to hold these public IP addresses and make them publicly accessible, bypassing the NAT process on this secondary subnet. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Munin and Vyatta
No, but you can get 1 on-board and 1 on an expansion module. You can investigate the options for yourself: http://www.logicsupply.com/products/system3677 (just choose the Jetway mainboard to get the daughterboard options). Ken Felix (C) wrote: Question does that configuration comes with 2 onboard LAN interfaces? ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] Rate Limiting
This might have been covered before and I just don't remember the details.. But is there any way to rate limit a vlan with Vyatta? I recall reading something about Linux and tc.. anyone? Thanks in advance :) ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Rate Limiting
Try this: http://www.hackosis.com/index.php/2007/11/08/linux-router-bandwidth-management-example/ If you need help getting it working on a vif let me know, I have it working. --- Aubrey Wells (mobile) Senior Engineer Shelton | Johns Technology Group Support: [EMAIL PROTECTED] sheltonjohns.com -Original Message- From: Max [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 2/6/08 4:10 PM Subject: [Vyatta-users] Rate Limiting This might have been covered before and I just don't remember the details.. But is there any way to rate limit a vlan with Vyatta? I recall reading something about Linux and tc.. anyone? Thanks in advance :) ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Rate Limiting
This should be available by the Glendale/VC4 beta time-frame coming up in the next couple of months. Regards, Sanjoy Dey Vyatta Inc. [EMAIL PROTECTED] Tel: 650-413-7277 -Original Message- From: [EMAIL PROTECTED] [mailto:vyatta-users- [EMAIL PROTECTED] On Behalf Of Max Sent: Wednesday, February 06, 2008 1:38 PM To: Aubrey Wells Cc: [EMAIL PROTECTED] Subject: Re: [Vyatta-users] Rate Limiting This looks quite nice! Boy you know what would make Vyatta even more awesome? If the CLI/WebUI had this built in! Wooo what hotness :D Thanks a bunch! On Feb 6, 2008 3:17 PM, Aubrey Wells [EMAIL PROTECTED] wrote: Try this: http://www.hackosis.com/index.php/2007/11/08/linux-router-bandwidth- management-example/ If you need help getting it working on a vif let me know, I have it working. --- Aubrey Wells (mobile) Senior Engineer Shelton | Johns Technology Group Support: [EMAIL PROTECTED] sheltonjohns.com -Original Message- From: Max [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 2/6/08 4:10 PM Subject: [Vyatta-users] Rate Limiting This might have been covered before and I just don't remember the details.. But is there any way to rate limit a vlan with Vyatta? I recall reading something about Linux and tc.. anyone? Thanks in advance :) ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] WAN Load Balancing
-BEGIN PGP SIGNED MESSAGE- On Tue, 5 Feb 2008, Dave Roberts wrote: One thing you could do is use the WAN load balancing feature and change the weight factors between the links as you approach the maximum. There is currently no way to do this automatically, though coupled with QoS you might be able to work something out. Personally, I would go this route with WAN LB weight adjustment rather than OSPF. Having not yet played with Glendale, the answer to this may be obvious, but... is there a way to execute Vyatta commands via cron? Being able to schedule the insertion/removal of a higher priority static route would solve Abhilash's problem and be a very cool feature. In the current version I guess you could probably do scheduled config changes using expect. Has anyone tried doing so? - -- Dave Pifke, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBR6pJjTuW2fOIQC3pAQF9jgQAmV/z++gL5CA0PuWhdsfJ8tYewsCncSfN y8clYip2s4TjMVKEiVY3hA2B3oRyVZAhhmKyPAF3c5mhSuVIV5b05V7B+1Q5QWqr JRTJjfSW7sHPfIYIIEV4NOQzYqVmubBu/A8/pJbWUP5aU4+2Yo1fC4eTZxM/VB9G j3ltmAeybxU= =PoHn -END PGP SIGNATURE- ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] WAN Load Balancing
it is possible to echo the commands into xorpsh. i've got some commands done that way in my rc.local, no reason why you couldn't cron them. assessing return codes from the commands would be difficult though. you could end up with no routes at all if something went sideways. Dave Pifke wrote: -BEGIN PGP SIGNED MESSAGE- On Tue, 5 Feb 2008, Dave Roberts wrote: One thing you could do is use the WAN load balancing feature and change the weight factors between the links as you approach the maximum. There is currently no way to do this automatically, though coupled with QoS you might be able to work something out. Personally, I would go this route with WAN LB weight adjustment rather than OSPF. Having not yet played with Glendale, the answer to this may be obvious, but... is there a way to execute Vyatta commands via cron? Being able to schedule the insertion/removal of a higher priority static route would solve Abhilash's problem and be a very cool feature. In the current version I guess you could probably do scheduled config changes using expect. Has anyone tried doing so? - -- Dave Pifke, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBR6pJjTuW2fOIQC3pAQF9jgQAmV/z++gL5CA0PuWhdsfJ8tYewsCncSfN y8clYip2s4TjMVKEiVY3hA2B3oRyVZAhhmKyPAF3c5mhSuVIV5b05V7B+1Q5QWqr JRTJjfSW7sHPfIYIIEV4NOQzYqVmubBu/A8/pJbWUP5aU4+2Yo1fC4eTZxM/VB9G j3ltmAeybxU= =PoHn -END PGP SIGNATURE- ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
