[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] 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
Re: [Vyatta-users] Emergency Config paste? How do you prepare?
Hi Aaron, The method that we have come up with and found to work great is using our internal workstation backup server which runs BackupPC (http://backuppc.sourceforge.net/). Since BackupPC supports backups of Linux systems (like most of our workstations), we just configured the Vyatta router as another backup client. BackupPC grabs a backup of the live config every 24 hours in our config, and archives them. In the BackupPC web interface, we can just browse the backups of the Vyatta system from any day, compare config changes with a Linux/Unix diff or by just reading it if the file isn't too huge, then initiate a restore of the config file from whatever day needed. Behind the curtain, BackupPC uses rsync to copy over the requested backup copy of the config file onto the Vyatta router. Then from the router shell, just load the restored copy of the config: # load /opt/vyatta/etc/config/config.boot and the desired config is restored. I can give more details if anyone wants, but that is the overview. Starting with a blank Vyatta config, we can get it fully re-configured with a backup config in less than 90 seconds. Without using backup software, one could have a script to scp/rsync the config files somewhere, and to restore an old config, scp the old config back on top of the live config and use the same load command from the router shell. Hope this helps. -Daniel [EMAIL PROTECTED] wrote: All, Coming from a Cisco world, I could copy the config file to a tftp server and once I have 1 interface open-- I could essentially paste in everything on a blank router(or com port). This is helpful when I had to replace a failing router with a backup one mid-day. How would I do the same with Vyatta? I was thinking if I could SCP the config file and make it the config.boot file, I could just do a reboot and it would all come back? Perhaps I'm a little confused on essentially doing a big 'paste' of all the configs, particularly the firewall rules. If anyone else has some good backup strategies on vyatta router configs, please share-- I'm a little new at this one. Thanks in advance, Aaron ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users -- Daniel Stickney - Linux Systems Administrator Email: [EMAIL PROTECTED] Cell: 720.422.2732 Work: 303.497.9369 ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Equivalent Command for Show IP BGP?
Hi Juan, I am not terribly familiar with IOS, but I believe you will find the command you are looking for within the Command Reference guide on about page 276. http://www.vyatta.com/twiki/pub/Community/CommandReference/Vyatta_CommandRef_VC3_v02.pdf Does this give you the answer to your question? -Daniel Juan E. Aguilar wrote: Does Vyatta have an equivalent command for Cisco's show ip bgp xxx.xxx.xxx.xxx? Thanks, Juan Aguilar ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users -- Daniel Stickney - Linux Systems Administrator Email: [EMAIL PROTECTED] Cell: 720.422.2732 Work: 303.497.9369 ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] VRRP Confusion
Thank you both Stig and Allan for your input. How might I disable the vmac setting? I found a file called /opt/vyatta/sbin/vrrpd.init, but no mention of the string vmac in all of /opt. An interesting point is that the failure to respond to pings except when tcpdump is running only occurs on vyatta02. When vyatta01 is master, it responds to pings on 192.168.10.1(VIP) and 192.168.10.3(eth1). When vyatta02 is master, neither the VIP it holds nor 192.168.10.2(eth1) respond to pings. I tried two other tests without success. I swapped out the switch they are all plugged into for the 192.168.10.0 network, and I also swapped the 10.2 IP to vyatta01 and the 10.3 IP to vyatta02, but that also made no difference. I have placed them back to their configuration as documented in my original email. Thanks for your time, -Daniel Allan Leinwand wrote: A thought here that may help cut through some of the confusion. I think that when you run tcpdump on the interface it places that interface into promiscuous mode. When in this mode, it can respond to pings to both the real IP address on the Ethernet and the virtual IP address (all packets are being received by the interface so when it sees one for it's own IP addresses, it responds). However, when the interface is running VRRP and in non-promiscuous mode I am unsure if the real IP and the virtual IP both respond to pings. Final caveat: I have not tried any of this recently, so with my advice YMMV. Thanks, allan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stig Thormodsrud Sent: Thursday, December 13, 2007 12:23 PM To: 'Daniel Stickney'; vyatta-users@mailman.vyatta.com; 'Daniel Stickney'; vyatta-users@mailman.vyatta.com Subject: Re: [Vyatta-users] VRRP Confusion I wonder if this might be solved with the disable-vmac setting? stig -Original Message- From: [EMAIL PROTECTED] [mailto:vyatta-users- [EMAIL PROTECTED] On Behalf Of Daniel Stickney Sent: Wednesday, December 12, 2007 2:47 PM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] VRRP Confusion Hello everyone, I used google to search the mail list archive, but didn't get any results for my issue. This is my second day working on the problem and my colleagues don't have any suggestions. This post is a little long, but I hope thorough enough to give all relevant information. Here is my setup: vyatta01 - eth0:192.168.2.50, eth1:192.168.10.3 vyatta02 - eth0:192.168.2.51, eth1:192.168.10.2 laptop01 - eth0:192.168.10.11 Laptop01 is connected to a switch, which also has cables from eth1 on both vyatta01 and vyatta02 connected. Eth0 on both vyatta01 and vyatta02 are connected into the main 192.168.2.0/24 network which has internet connectivity. With a base configuration of a default route to 192.168.2.21 on both vyatta01 and vyatta02, and the above IPs assigned to their respective network cards, I can ping 192.168.10.2 and 192.168.10.3 from laptop01; and I can ping 192.168.10.2 from vyatta01, and I can ping 192.168.10.3 from vyatta02. Basically, everything can ping everything. I then proceed to setup VRRP between vyatta01 and vyatta02 with the following config: --Vyatta02-- set interfaces ethernet eth1 vrrp vrrp-group 10 set interfaces ethernet eth1 vrrp virtual-address 192.168.10.1 set interfaces ethernet eth1 vrrp preempt true set interfaces ethernet eth1 vrrp priority 150 commit --Vyatta01-- set interfaces ethernet eth1 vrrp vrrp-group 10 set interfaces ethernet eth1 vrrp virtual-address 192.168.10.1 set interfaces ethernet eth1 vrrp preempt true set interfaces ethernet eth1 vrrp priority 20 commit So vyatta02 is the master, VIP is 192.168.10.1. Immediately, and as expected, I see in the output of show vrrp that vyatta02 considers itself the master, and vyatta01 sees itself as the backup. In a tcpdump from laptop01 I can see the VRRPv2 advertisements from vyatta02 every second. At this time from laptop01 I am unable to ping 192.168.10.1 or 192.168.10.2, but I can ping 192.168.10.3. The arp table on laptop01 shows the following: # arp -n Address HWtype HWaddress Flags MaskIface 192.168.10.3 ether 00:1A:A0:2A:04:0A C eth0 192.168.10.1 ether 00:00:5E:00:01:0A C eth0 192.168.10.2 ether 00:00:5E:00:01:0A C eth0 From vyatta01, I am also unable to ping 192.168.10.1 and 192.168.10.2. What is causing me great confusion is if on vyatta02 I login as root and execute a tcpdump -i eth1, instantly my pings from laptop01 and vyatta01 to both 192.168.10.1 and 192.168.10.2 start getting responses. As soon as I ctrl-c the tcpdump on vyatta02, the ping responses stop again. If I reconfigure the VRRP priority of vyatta02 to be lower than vyatta01, they change over to vyatta01 being the master, and vyatta02
Re: [Vyatta-users] VRRP Confusion
Ahhh, very interesting. That makes *perfect* sense for this issue. Since I happened to have a spare NIC, so I swapped out the previous card and put in a different one, and now VRRP works perfectly and everything can ping everything all the time, no matter whether vyatta01 or vyatta02 is master. Thank you all so much for your inputs! I would have never have guessed that my previous card's MAC address was unchangeable. In the output of ifconfig I could see the MAC address changing for eth1 when it switched between master and backup, so that possibility never occurred to me. Thanks again all! Daniel Justin Fletcher wrote: Ah, yes - you can't actually change the MAC on some hardware, so you end up in this confused state and only see packets destined for the interface in promiscuous mode (hence the suggestion to disable the virtual MAC . . .) Justin On Dec 13, 2007 12:29 PM, Allan Leinwand [EMAIL PROTECTED] wrote: A thought here that may help cut through some of the confusion. I think that when you run tcpdump on the interface it places that interface into promiscuous mode. When in this mode, it can respond to pings to both the real IP address on the Ethernet and the virtual IP address (all packets are being received by the interface so when it sees one for it's own IP addresses, it responds). However, when the interface is running VRRP and in non-promiscuous mode I am unsure if the real IP and the virtual IP both respond to pings. Final caveat: I have not tried any of this recently, so with my advice YMMV. Thanks, allan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stig Thormodsrud Sent: Thursday, December 13, 2007 12:23 PM To: 'Daniel Stickney'; vyatta-users@mailman.vyatta.com; 'Daniel Stickney'; vyatta-users@mailman.vyatta.com Subject: Re: [Vyatta-users] VRRP Confusion I wonder if this might be solved with the disable-vmac setting? stig -Original Message- From: [EMAIL PROTECTED] [mailto:vyatta-users- [EMAIL PROTECTED] On Behalf Of Daniel Stickney Sent: Wednesday, December 12, 2007 2:47 PM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] VRRP Confusion Hello everyone, I used google to search the mail list archive, but didn't get any results for my issue. This is my second day working on the problem and my colleagues don't have any suggestions. This post is a little long, but I hope thorough enough to give all relevant information. Here is my setup: vyatta01 - eth0:192.168.2.50, eth1:192.168.10.3 vyatta02 - eth0:192.168.2.51, eth1:192.168.10.2 laptop01 - eth0:192.168.10.11 Laptop01 is connected to a switch, which also has cables from eth1 on both vyatta01 and vyatta02 connected. Eth0 on both vyatta01 and vyatta02 are connected into the main 192.168.2.0/24 network which has internet connectivity. With a base configuration of a default route to 192.168.2.21 on both vyatta01 and vyatta02, and the above IPs assigned to their respective network cards, I can ping 192.168.10.2 and 192.168.10.3 from laptop01; and I can ping 192.168.10.2 from vyatta01, and I can ping 192.168.10.3 from vyatta02. Basically, everything can ping everything. I then proceed to setup VRRP between vyatta01 and vyatta02 with the following config: --Vyatta02-- set interfaces ethernet eth1 vrrp vrrp-group 10 set interfaces ethernet eth1 vrrp virtual-address 192.168.10.1 set interfaces ethernet eth1 vrrp preempt true set interfaces ethernet eth1 vrrp priority 150 commit --Vyatta01-- set interfaces ethernet eth1 vrrp vrrp-group 10 set interfaces ethernet eth1 vrrp virtual-address 192.168.10.1 set interfaces ethernet eth1 vrrp preempt true set interfaces ethernet eth1 vrrp priority 20 commit So vyatta02 is the master, VIP is 192.168.10.1. Immediately, and as expected, I see in the output of show vrrp that vyatta02 considers itself the master, and vyatta01 sees itself as the backup. In a tcpdump from laptop01 I can see the VRRPv2 advertisements from vyatta02 every second. At this time from laptop01 I am unable to ping 192.168.10.1 or 192.168.10.2, but I can ping 192.168.10.3. The arp table on laptop01 shows the following: # arp -n Address HWtype HWaddress Flags MaskIface 192.168.10.3 ether 00:1A:A0:2A:04:0A C eth0 192.168.10.1 ether 00:00:5E:00:01:0A C eth0 192.168.10.2 ether 00:00:5E:00:01:0A C eth0 From vyatta01, I am also unable to ping 192.168.10.1 and 192.168.10.2. What is causing me great confusion is if on vyatta02 I login as root and execute a tcpdump -i eth1, instantly my pings from laptop01 and vyatta01 to both 192.168.10.1 and 192.168.10.2 start getting responses. As soon as I ctrl-c the tcpdump on vyatta02, the ping responses stop again. If I reconfigure the VRRP priority of vyatta02 to be lower than vyatta01
[Vyatta-users] VRRP Confusion
:06.333001 IP 192.168.10.11 192.168.10.1: ICMP echo request, id 45946, seq 1, length 64 15:27:06.333181 IP 192.168.10.1 192.168.10.11: ICMP echo reply, id 45946, seq 1, length 64 15:27:07.331867 IP 192.168.10.11 192.168.10.1: ICMP echo request, id 45946, seq 2, length 64 15:27:07.332146 IP 192.168.10.1 192.168.10.11: ICMP echo reply, id 45946, seq 2, length 64 I have pasted the configurations of both vyatta01 and vyatta02 here: http://pastebin.com/f3f7bae41 I would love to hear back any suggestions anyone has about what the problem is and how I can get vyatt02 to respond normally to pings when it is the master, just like how vyatta01 responds when it is the master. Thanks for your time, Daniel -- Daniel Stickney - Linux Systems Administrator ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
