Re: [Vyatta-users] Cluster heartbeat / change to ucast?
Thanks, again! -Original Message- From: Justin Fletcher [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2008 2:07 PM To: Chad Hurley Cc: [EMAIL PROTECTED] Subject: Re: [Vyatta-users] Cluster heartbeat / change to ucast? Not yet, but it is one of the enhancements requested in bug 2730 (https://bugzilla.vyatta.com/show_bug.cgi?id=2730). To keep it a permanent setting, you can modify the perl script that generates it; it's /opt/vyatta/sbin/vyatta-update-cluster.pl in VC4. Best, Justin On Tue, Mar 4, 2008 at 11:01 AM, Chad Hurley [EMAIL PROTECTED] wrote: Thanks for the reply. Do you know if it is possible to specify this in the Vyatta configuration so that you don't need to reconfigure it each time? -CH -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Fletcher Sent: Tuesday, March 04, 2008 11:16 AM To: [EMAIL PROTECTED] Subject: Re: [Vyatta-users] Cluster heartbeat / change to ucast? Yes, you can edit the configuration directly; however, you'll need to modify it again on reboot as it's created from the Vyatta configuration. Best, Justin On Tue, Mar 4, 2008 at 4:43 AM, Chad Hurley [EMAIL PROTECTED] wrote: The heartbeat from my Vyatta cluster is creating errors on another cluster on my network. I would like to change the default bcast heartbeat to ucast. Does anyone know if it is save to edit the following file directly without any adverse affects? File: /etc/ha.d/ha.cf Current config: keepalive 1 deadtime 4 warntime 2 initdead 120 logfacility daemon bcast eth0 eth1 auto_failback off node riv1 riv2 ping 192.168.5.3 192.168.0.221 respawn hacluster /usr/lib/heartbeat/ipfail I would like to replace the bcast line with: ucast eth0 192.168.5.5 ucast eth1 192.168.0.252 Anyone had luck with this type of config? Thanks, Chad ___ 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] cannot clear t3-options
Hi Chad, The t3-options parent node is a required node that has a set of default values nested beneath it. If you want to delete the actual option values you've set beneath t3-options to get back to the defaults, you can try deleting the values nodes individually: delete interface wan0 t3-options line-coding etc. etc. The node is required in order to load the correct driver options for either T1/ E1 or T3/ E3 so it needs to be there before you can successfully commit the serial interface configuration. Thank you, Robyn Chad Hurley wrote: Hi, When I try to delete my t3-options I get the following error: Commit Failed t1/e1/t3/e3-option is not specified Is there a work around for this? Thanks, Chad Hurley ___ 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] cannot clear t3-options
Ah, Thanks! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robyn Orosz Sent: Wednesday, March 05, 2008 9:53 AM To: [EMAIL PROTECTED] Subject: Re: [Vyatta-users] cannot clear t3-options Hi Chad, The t3-options parent node is a required node that has a set of default values nested beneath it. If you want to delete the actual option values you've set beneath t3-options to get back to the defaults, you can try deleting the values nodes individually: delete interface wan0 t3-options line-coding etc. etc. The node is required in order to load the correct driver options for either T1/ E1 or T3/ E3 so it needs to be there before you can successfully commit the serial interface configuration. Thank you, Robyn Chad Hurley wrote: Hi, When I try to delete my t3-options I get the following error: Commit Failed t1/e1/t3/e3-option is not specified Is there a work around for this? Thanks, Chad Hurley ___ 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
[Vyatta-users] vif 1 on wan0
Sorry for all the questions but this is the first time I have used anything outside of Ethernet on a Vyatta router. I have configured a Sangoma A301 card and the system finds fine. I have configured it with vif 1 and assigned an address. However, when I try to ping the address from the router itself I get the error: connect: Network is unreachable Am I missing something? Thanks again in advance. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] vif 1 on wan0
ppp You are right. This is a new router with a new ISP and we have not gotten the link up with the LEC for testing yet. Thanks for the feedback. -Chad From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aubrey Wells Sent: Wednesday, March 05, 2008 10:09 AM To: [EMAIL PROTECTED] Subject: Re: [Vyatta-users] vif 1 on wan0 Is your serial connection up? You won't be able to ping it until the connection comes up because that's when the vif gets created. if you do a ifconfig from the shell, you will probably see that wan0.1 is not created yet. Are you using ppp or c-hdlc? -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com On Mar 5, 2008, at 10:06 AM, Chad Hurley wrote: Sorry for all the questions but this is the first time I have used anything outside of Ethernet on a Vyatta router. I have configured a Sangoma A301 card and the system finds fine. I have configured it with vif 1 and assigned an address. However, when I try to ping the address from the router itself I get the error: connect: Network is unreachable Am I missing something? Thanks again 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] vif 1 on wan0
Is your serial connection up? You won't be able to ping it until the connection comes up because that's when the vif gets created. if you do a ifconfig from the shell, you will probably see that wan0.1 is not created yet. Are you using ppp or c-hdlc? -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com On Mar 5, 2008, at 10:06 AM, Chad Hurley wrote: Sorry for all the questions but this is the first time I have used anything outside of Ethernet on a Vyatta router. I have configured a Sangoma A301 card and the system finds fine. I have configured it with vif 1 and assigned an address. However, when I try to ping the address from the router itself I get the error: connect: Network is unreachable Am I missing something? Thanks again 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] Request for link redundancy suggestions
Hi Everyone, I have exhausted my ideas and am now looking for suggestions on how to achieve my goal of having redundant links from two clustered Vyatta boxes. I'll lay out the technical details and goal first. We have two edge layer 3 switches which are stacked (with stacking modules and cable, so they are a single logical switch with a single administration interface. For those not familiar with stacking, they act like separate 48 port blades in a switch chassis) and two Vyatta boxes with clustering configured. The cluster resources are one public VIP, and one private VIP. I am excluding the rest of the network architecture to focus in on the links between the two Vyatta boxes and the edge (logical) switch. Our network design requirements document stated we wanted to have no single point of failure in our network backbone. To meet this goal, we have 2 ISP drops with 2 cables per drop (spanning-tree used to select designated cable on each drop) to our edge switch stack; one cable from each drop is connected to each switch (think connected to each blade) so if an edge switch in the stack dies (or if a blade in the chassis dies) traffic can still run through the surviving edge switch (blade). As mentioned, we also have two Vyatta boxes clustered. The only part of this that I can't figure out how to make redundant is the gigabit network cable between each Vyatta box and the edge switch stack (named link1-1, link1-2, and link2-1, link2-2 below). I am hoping to hear some suggestions on how this might be achieved within our architecture. So far I have considered port-channeling and spanning-tree, but neither of these appear to be a solution in this case. Here is an ASCII drawing of this description: ISP-drop1-1|-| ISP-drop1-2|edge-sw-1|link2-1 | |link2-2 | |-| | | -link1-1--| |ISP-drop2-1 | | |-link1-2-|edge-sw-2|ISP-drop2-2 | | || |-| | | || | | || -- | || | || | | || | | |--| |--| | vyatta-1 | | vyatta-2 | |--| |--| I realize the link1 and link2 can be done with one cable from each Vyatta box to the edge switch stack, but we are trying to eliminate each cable as a single point of failure by providing a backup cable from each Vyatta box to the edge. We have no interest in applying a 'duct-tape and bubble gum' hacked together solution on our network backbone, so I am hoping there is a standardized method to achieve our goal. I am concerned that I am misunderstanding something or missing an option which has left me at my dead end. Here is how I have gotten to this logical dead end. Vyatta (VC3) does not support Linux bonded NICs (devices named bondX) in the command shell or web interface, so port-channeling is not an option. Vyatta (VC3) does support bridge groups, but not officially assigning them IPs within Xorpsh or the web interface (yes I know the Linux shell method, but we are avoiding any unofficial hacks). With 2 bridged interfaces, running spanning-tree with the switch ports to have only one active cable would meet our goal, but we need the clustering to move a VIP resource back and forth between the bridge group interfaces on the two Vyatta boxes, and as far as I can tell from reading the manuals and forums and guides, this is not supported. Am I understanding things correctly? I am ok with the answer being there is no way to do what you want at this time, I just don't want to miss an officially supported method if it exists. If we just have to use a single cable from each Vyatta box to the edge stack, it is not optimal but it is acceptable. Thanks very much for suggestions. -Daniel -- Daniel Stickney - Linux Systems Administrator Email: [EMAIL PROTECTED] ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Problems with Glendale Alpha 2
- Paco Alcantara [EMAIL PROTECTED] wrote: .- I am looking for PPPoE commands are I cannot find them. Any help?? Well I have seen the commands in the documentation but when I try to configure the interface set interfaces ethernet eth0 the next item that could be pppoe is not available. Where is my error?? Hi Paco -- Here's an example of configuring PPPOE on Glendale Alpha 2: vyatta:~# show version Version :vc4.0.0 Built by:[EMAIL PROTECTED] Built on:Tue Feb 26 02:48:23 UTC 2008 Build ID:0802260248e2da7ea Boot via:disk Uptime :11:21:58 up 6 min, 1 user, load average: 0.04, 0.31, 0.20 vyatta:~# configure [edit] [EMAIL PROTECTED] set interfaces ethernet eth3 pppoe 7 [edit] [EMAIL PROTECTED] set interfaces ethernet eth3 pppoe 7 user-id [EMAIL PROTECTED] [edit] [EMAIL PROTECTED] set interfaces ethernet eth3 pppoe 7 password [edit] [EMAIL PROTECTED] commit [edit] [EMAIL PROTECTED] save Saving configuration to '/opt/vyatta/etc/config/config.boot'... Done [edit] [EMAIL PROTECTED] exit exit vyatta:~# show interfaces pppoe pppoe7: POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP mtu 1500 qdisc pfifo_fast qlen 100 link/ppp inet 76.200.163.135 peer 151.164.184.125/32 scope global pppoe7 RX: bytespackets errorsdroppedoverrun mcast 64 4 0 0 0 0 TX: bytespackets errorsdroppedcarrier collisions 241 8 0 0 0 0 vyatta:~# Note that there is a bug in Glendale Alpha 2 that will prevent the PPPOE link from coming up once configured. Fortunately, the fix is a one-line change to the PPPOE configuration template. You can make the fix by editing the file: /opt/vyatta/share/vyatta-cfg/templates/interfaces/ethernet/node.tag/pppoe/node.def Change the line that reads: sudo sh -c echo pty \/usr/sbin/pppoe -m 1412 -I $VAR(../@)\ \ to instead read: sudo sh -c echo pty \\\/usr/sbin/pppoe -m 1412 -I $VAR(../@)\\\ \ I.e. there need to be three backslash characters before the second and third quote character. After you have made that change, reboot your system, and PPPOE should work as expected. This fix has been checked into the source tree and will be in our next Glendale release, BTW. If the link doesn't come up, you can use tcpdump on the ethernet interface to troubleshoot, e.g.: vyatta:~# tcpdump -n -e -i eth3 Note also that we have a command to force the link down,e,g: vyatta:~# set interface pppoe pppoe7 down Bringing PPPOE interface pppoe7 down vyatta:~# and a command to bring the link back up: vyatta:~# set interface pppoe pppoe7 up Bringing PPPOE interface pppoe7 up. vyatta:~# Bringing the link down and back up re-starts the PPPOE protocol exchange from scratch, so my usual troubleshooting technique is to run tcpdump on the ethernet interface, then bring the PPPOE link down and back up, then watch the protocol exchanges. I hope that helps! Bob. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Request for link redundancy suggestions
ISP-drop1-1|-| ISP-drop1-2|edge-sw-1|link2-1 | |link2-2 | |-| | | -link1-1--| |ISP-drop2-1 | | |-link1-2-|edge-sw-2|ISP-drop2-2 | | || |-| | | || | | || -- | || | || | | || | | |--| |--| | vyatta-1 | | vyatta-2 | |--| |--| I realize the link1 and link2 can be done with one cable from each Vyatta box to the edge switch stack, but we are trying to eliminate each cable as a single point of failure by providing a backup cable from each Vyatta box to the edge. If you do run only one cable from each vyatta router, then you still have cable redundancy as there are two routers in the cluster. Do you really need the added protection of four cables? What situation do you forsee where three cables simultaneously fail? Jonathon. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Request for link redundancy suggestions
Daniel, If you're able to use the glendale alpha (i.e. VC4.0.0) it does have support for adding an IP address on the bridge interface and it also supports ECMP which might be an option for your dual links. I wrote a quick howto for ECMP on the new forum at: http://www.vyatta.org/forum/viewtopic.php?t=20 stig -Original Message- From: [EMAIL PROTECTED] [mailto:vyatta-users- [EMAIL PROTECTED] On Behalf Of Daniel Stickney Sent: Wednesday, March 05, 2008 11:42 AM To: [EMAIL PROTECTED] Subject: [Vyatta-users] Request for link redundancy suggestions Hi Everyone, I have exhausted my ideas and am now looking for suggestions on how to achieve my goal of having redundant links from two clustered Vyatta boxes. I'll lay out the technical details and goal first. We have two edge layer 3 switches which are stacked (with stacking modules and cable, so they are a single logical switch with a single administration interface. For those not familiar with stacking, they act like separate 48 port blades in a switch chassis) and two Vyatta boxes with clustering configured. The cluster resources are one public VIP, and one private VIP. I am excluding the rest of the network architecture to focus in on the links between the two Vyatta boxes and the edge (logical) switch. Our network design requirements document stated we wanted to have no single point of failure in our network backbone. To meet this goal, we have 2 ISP drops with 2 cables per drop (spanning-tree used to select designated cable on each drop) to our edge switch stack; one cable from each drop is connected to each switch (think connected to each blade) so if an edge switch in the stack dies (or if a blade in the chassis dies) traffic can still run through the surviving edge switch (blade). As mentioned, we also have two Vyatta boxes clustered. The only part of this that I can't figure out how to make redundant is the gigabit network cable between each Vyatta box and the edge switch stack (named link1-1, link1-2, and link2-1, link2- 2 below). I am hoping to hear some suggestions on how this might be achieved within our architecture. So far I have considered port-channeling and spanning-tree, but neither of these appear to be a solution in this case. Here is an ASCII drawing of this description: ISP-drop1-1|-| ISP-drop1-2|edge-sw-1|link2-1 | |link2-2 | |-| | | -link1-1--| |ISP-drop2-1 | | |-link1-2-|edge-sw-2|ISP-drop2-2 | | || |-| | | || | | || -- | || | || | | || | | |--| |--| | vyatta-1 | | vyatta-2 | |--| |--| I realize the link1 and link2 can be done with one cable from each Vyatta box to the edge switch stack, but we are trying to eliminate each cable as a single point of failure by providing a backup cable from each Vyatta box to the edge. We have no interest in applying a 'duct-tape and bubble gum' hacked together solution on our network backbone, so I am hoping there is a standardized method to achieve our goal. I am concerned that I am misunderstanding something or missing an option which has left me at my dead end. Here is how I have gotten to this logical dead end. Vyatta (VC3) does not support Linux bonded NICs (devices named bondX) in the command shell or web interface, so port-channeling is not an option. Vyatta (VC3) does support bridge groups, but not officially assigning them IPs within Xorpsh or the web interface (yes I know the Linux shell method, but we are avoiding any unofficial hacks). With 2 bridged interfaces, running spanning-tree with the switch ports to have only one active cable would meet our goal, but we need the clustering to move a VIP resource back and forth between the bridge group interfaces on the two Vyatta boxes, and as far as I can tell from reading the manuals and forums and guides, this is not supported. Am I understanding things correctly? I am ok with the answer being there is no way to do what you want at this time, I just don't want to miss an officially supported method if it exists. If we just have to use a single cable from each Vyatta box to the edge stack, it is not optimal but it is acceptable. Thanks very much for suggestions. -Daniel -- Daniel Stickney - Linux Systems Administrator Email: [EMAIL PROTECTED] ___ 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
[Vyatta-users] VC4 Alpha 2: Clustering and VRRP with the same virtual interface?
Hi everybody! I'm testing vyatta 4, and I have a problem, I would like to use VRRP for down link detect and clustering for destination test with the same virtual IP. I have used two vyatta router with one interface only for the clustering signals and to route the packages from the master router to the slave when one interface is down. My problem is, for example when vyatta1 (primary and vrrp master) is vrrp master and vyatta2 is active at the cluster, (due to vyatta1 can't reach the destination but the link is up), when vyatta1 wants to take the control of the router, one of the cluster, the router reboots alone. Whats is happening? Can't I use VRRP and clustering with the same virtual IP? Thanks a lots. Regards, Manuel Romero. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Request for link redundancy suggestions
Hi Stig, I will be following the Glendale release, though I want to keep only stable releases in production. Glad to know this feature is coming down the pipe though. Thanks! -Daniel Stig Thormodsrud wrote: Daniel, If you're able to use the glendale alpha (i.e. VC4.0.0) it does have support for adding an IP address on the bridge interface and it also supports ECMP which might be an option for your dual links. I wrote a quick howto for ECMP on the new forum at: http://www.vyatta.org/forum/viewtopic.php?t=20 stig -Original Message- From: [EMAIL PROTECTED] [mailto:vyatta-users- [EMAIL PROTECTED] On Behalf Of Daniel Stickney Sent: Wednesday, March 05, 2008 11:42 AM To: [EMAIL PROTECTED] Subject: [Vyatta-users] Request for link redundancy suggestions Hi Everyone, I have exhausted my ideas and am now looking for suggestions on how to achieve my goal of having redundant links from two clustered Vyatta boxes. I'll lay out the technical details and goal first. We have two edge layer 3 switches which are stacked (with stacking modules and cable, so they are a single logical switch with a single administration interface. For those not familiar with stacking, they act like separate 48 port blades in a switch chassis) and two Vyatta boxes with clustering configured. The cluster resources are one public VIP, and one private VIP. I am excluding the rest of the network architecture to focus in on the links between the two Vyatta boxes and the edge (logical) switch. Our network design requirements document stated we wanted to have no single point of failure in our network backbone. To meet this goal, we have 2 ISP drops with 2 cables per drop (spanning-tree used to select designated cable on each drop) to our edge switch stack; one cable from each drop is connected to each switch (think connected to each blade) so if an edge switch in the stack dies (or if a blade in the chassis dies) traffic can still run through the surviving edge switch (blade). As mentioned, we also have two Vyatta boxes clustered. The only part of this that I can't figure out how to make redundant is the gigabit network cable between each Vyatta box and the edge switch stack (named link1-1, link1-2, and link2-1, link2- 2 below). I am hoping to hear some suggestions on how this might be achieved within our architecture. So far I have considered port-channeling and spanning-tree, but neither of these appear to be a solution in this case. Here is an ASCII drawing of this description: ISP-drop1-1|-| ISP-drop1-2|edge-sw-1|link2-1 | |link2-2 | |-| | | -link1-1--| |ISP-drop2-1 | | |-link1-2-|edge-sw-2|ISP-drop2-2 | | || |-| | | || | | || -- | || | || | | || | | |--| |--| | vyatta-1 | | vyatta-2 | |--| |--| I realize the link1 and link2 can be done with one cable from each Vyatta box to the edge switch stack, but we are trying to eliminate each cable as a single point of failure by providing a backup cable from each Vyatta box to the edge. We have no interest in applying a 'duct-tape and bubble gum' hacked together solution on our network backbone, so I am hoping there is a standardized method to achieve our goal. I am concerned that I am misunderstanding something or missing an option which has left me at my dead end. Here is how I have gotten to this logical dead end. Vyatta (VC3) does not support Linux bonded NICs (devices named bondX) in the command shell or web interface, so port-channeling is not an option. Vyatta (VC3) does support bridge groups, but not officially assigning them IPs within Xorpsh or the web interface (yes I know the Linux shell method, but we are avoiding any unofficial hacks). With 2 bridged interfaces, running spanning-tree with the switch ports to have only one active cable would meet our goal, but we need the clustering to move a VIP resource back and forth between the bridge group interfaces on the two Vyatta boxes, and as far as I can tell from reading the manuals and forums and guides, this is not supported. Am I understanding things correctly? I am ok with the answer being there is no way to do what you want at this time, I just don't want to miss an officially supported method if it exists. If we just have to use a single cable from each Vyatta box to the edge stack, it is not optimal but it is acceptable. Thanks very much for suggestions. -Daniel
