Interfaces uninitialized?
I am testing the VE in both Vmware ws 7 and Virtualbox. Unfortunatly with the same result. I can't get the interfaces to work. I have added them as host only but the interfaces show up as "UNINITIALIZED" and without a mac address. I can't see that I get any connectivity at all on the interfaces. The release notes mention UNINITIALIZED but that it should work anyway.
Virtual Server returning empty response
Hi, I have setup LTM VE on my laptop with a single virtual server and a single pool with two backends. My pool is up and running and http health checks are ok. When I configure my virtual server as type='Performance (HTTP)' I can connect to my virtual server from the browser and get a normal response. When I change the virtual server type to 'standard' (with defaults) then the first request go fine (new type not applied yet?) but after a few requests I start getting empty responses. In firefox this is show as an blank page and google chrome returns ERR_EMPTY_RESPONSE. There is no logging in the BIG-IP log and I seen no entries in the application server logs so it appears that the request are not forwarded by the BIG-IP. Any idea what I am doing wrong? regards, RichardBIG-IP Configuration Conversion Scripts
Kirk Bauer, John Alam, and Pete White created a handful of perl and/or python scripts aimed at easing your migration from some of the “other guys” to BIG-IP.While they aren’t going to map every nook and cranny of the configurations to a BIG-IP feature, they will get you well along the way, taking out as much of the human error element as possible.Links to the codeshare articles below. Cisco ACE (perl) Cisco ACE via tmsh (perl) Cisco ACE (python) Cisco CSS (perl) Cisco CSS via tmsh (perl) Cisco CSM (perl) Citrix Netscaler (perl) Radware via tmsh (perl) Radware (python)
Welcome to the BIG-IP LTM VE forums
Thanks for checking out the forums for the BIG-IP LTM VE. This is where you can come to discuss your experiences with LTM VE, ask questions of others that are using it, share suggestions, and look for help. This is not official technical support so there are no SLAs but the DevCentral community usually does an outstanding job of helping each other out, and you'll likely find a wealth of knowledge and experience here. So let us know how you like it, or if you haven't seen it yet check out the BIG-IP LTM VE page on DevCentral to get started. Click here ColinBIG-IP LTM VE: Transfer your iRules in style with the iRule Editor
The new LTM VE has opened up the possibilities for writing, testing and deploying iRules in a big way. It’s easier than ever to get a test environment set up in which you can break things develop to your heart’s content. This is fantastic news for us iRulers that want to be doing the newest, coolest stuff without having to worry about breaking a production system. That’s all well and good, but what the heck do you do to get all of your current stuff onto your test system? There are several options, ranging from copy and paste (shudder) to actual config copies and the like, which all work fine. Assuming all you’re looking for though is to transfer over your iRules, like me, the easiest way I’ve found is to use the iRule editor’s export and import features. It makes it literally a few clicks and super easy to get back up and running in the new environment. First, log into your existing LTM system with your iRule editor (you are using the editor, right? Of course you are…just making sure). You’ll see a screen something like this (right) with a list of a bagillionty iRules on the left and their cool, color coded awesomeness on the right. You can go through and select iRules and start moving them manually, but there’s really no need. All you need to do is go up to the File –> Archive –> Export option and let it do its magic. All it’s doing is saving text files to your local system to archive off all of your iRuley goodness. Once that’s done, you can then spin up your new LTM VE and get logged in via the iRule editor over there. Connect via the iRule editor, and go to File –> Archive –> Import, shown below. Once you choose the import option you’ll start seeing your iRules popping up in the left-hand column, just like you’re used to. This will take a minute depending on how many iRules you have archived (okay, so I may have more than a few iRules in my collection…) but it’s generally pretty snappy. One important thing to note at his point, however, is that all of your iRules are bolded with an asterisk next to them. This means they are not saved in their current state on the LTM. If you exit at this point, you’ll still be iRuleless, and no one wants that. Luckily Joe thought of that when building the iRule editor, so all you need to do is select File –> Save All, and you’ll be most of the way home. I say most of the way because there will undoubtedly be some errors that you’ll need to clean up. These will be config based errors, like pools that used to exist on your old system and don’t now, etc. You can either go create the pools in the config or comment out those lines. I tend to try and keep my iRules as config agnostic as possible while testing things, so there aren’t a ton of these but some of them always crop up. The editor makes these easy to spot and fix though. The name of the iRule that’s having a problem will stay bolded and any errors in that particular code will be called out (assuming you have that feature turned on) so you can pretty quickly spot them and fix them. This entire process took me about 15 minutes, including cleaning up the code in certain iRules to at least save properly on the new system, and I have a bunch of iRules, so that’s a pretty generous estimate. It really is quick, easy and painless to get your code onto an LTM VE and get hacking coding. An added side benefit, but a cool one, is that you now have your iRules backed up locally. Not only does this mean you’re double plus sure that they won’t be lost, but it means the next time you want to deploy them somewhere, all you have to do is import from the editor. So if you haven’t yet, go download your BIG-IP LTM VE and get started. I can’t recommend it enough. Also make sure to check out some of the really handy DC content that shows you how to tweak it for more interfaces or Joe’s supremely helpful guide on how to use a single VM to run an entire client/LTM/server setup. Wicked cool stuff. Happy iRuling. #Colin
What Hypervisors have you tried LTM VE in?
While VMware Workstation 7, ESX and ESXi 4 are supported, many of the other Hypervisors on the market are not. This does not mean that the LTM VE will not run in them. Folks have had great success with Fusion 2 and 3 as well as Virtual Box 3. What other hypervisors have you tried LTM VE in, and what issues did you find if any?IP::addr and IPv6
Did you know that all address internal to tmm are kept in IPv6 format? If you’ve written external monitors, I’m guessing you knew this. In the external monitors, for IPv4 networks the IPv6 “header” is removed with the line: IP=`echo $1 | sed 's/::ffff://'` IPv4 address are stored in what’s called “IPv4-mapped” format. An IPv4-mapped address has its first 80 bits set to zero and the next 16 set to one, followed by the 32 bits of the IPv4 address. The prefix looks like this: 0000:0000:0000:0000:0000:ffff: (abbreviated as ::ffff:, which looks strickingly simliar—ok, identical—to the pattern stripped above) Notation of the IPv4 section of the IPv4-formatted address vary in implementations between ::ffff:192.168.1.1 and ::ffff:c0a8:c8c8, but only the latter notation (in hex) is supported. If you need the decimal version, you can extract it like so: % puts $x ::ffff:c0a8:c8c8 % if { [string range $x 0 6] == "::ffff:" } { scan [string range $x 7 end] "%2x%2x:%2x%2x" ip1 ip2 ip3 ip4 set ipv4addr "$ip1.$ip2.$ip3.$ip4" } 192.168.200.200 Address Comparisons The text format is not what controls whether the IP::addr command (nor the class command) does an IPv4 or IPv6 comparison. Whether or not the IP address is IPv4-mapped is what controls the comparison. The text format merely controls how the text is then translated into the internal IPv6 format (ie: whether it becomes a IPv4-mapped address or not). Normally, this is not an issue, however, if you are trying to compare an IPv6 address against an IPv4 address, then you really need to understand this mapping business. Also, it is not recommended to use 0.0.0.0/0.0.0.0 for testing whether something is IPv4 versus IPv6 as that is not really valid a IP address—using the 0.0.0.0 mask (technically the same as /0) is a loophole and ultimately, what you are doing is loading the equivalent form of a IPv4-mapped mask. Rather, you should just use the following to test whether it is an IPv4-mapped address: if { [IP::addr $IP1 equals ::ffff:0000:0000/96] } { log local0. “Yep, that’s an IPv4 address” } These notes are covered in the IP::addr wiki entry. Any updates to the command and/or supporting notes will exist there, so keep the links handy. Related Articles F5 Friday: 'IPv4 and IPv6 Can Coexist' or 'How to eat your cake ... Service Provider Series: Managing the ipv6 Migration IPv6 and the End of the World No More IPv4. You do have your IPv6 plan running now, right ... Question about IPv6 - BIGIP - DevCentral - F5 DevCentral ... Insert IPv6 address into header - DevCentral - F5 DevCentral ... Business Case for IPv6 - DevCentral - F5 DevCentral > Community ... We're sorry. The IPv4 address you are trying to reach has been ... Don MacVittie - F5 BIG-IP IPv6 Gateway Module
BIG-IP LTM VE on KVM?
F5 now posts BIGIP-11.3.0.2806.0.qcow2.zip I followed the instructions on this document http://support.f5.com/content/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ve-kvm-setup-11-3-0/_jcr_content/pdfAttach/download/file.res/BIG-IP%C2%AE_Virtual_Edition_Setup_Guide_for_Linux_KVM.pdf the VM starts up and everything but some processes do not seem to run correctly. here is the output of "tmsh show sys version" [root@localhost:NO LICENSE:] config tmsh show sys version Cannot connect to mcpd Cannot connect to mcpd. Your preferences and aliases will not be available until it comes back up. The connection to mcpd has been lost, try again. I also get these messages every 10 seconds [root@localhost:NO LICENSE:] config Jul 8 16:37:18 localhost emerg logger: Re-starting chmand Jul 8 16:37:28 localhost emerg logger: Re-starting chmand Jul 8 16:37:38 localhost emerg logger: Re-starting chmand Jul 8 16:37:48 localhost emerg logger: Re-starting chmand I tried to post the domain xml file I'm using here on devcentral but no success. so here's the pastebin link. any suggestions to change this XML file would be GREATLY APPRECAITED. regards Click HereF5 BIGIP VE is failing to install on VMWARE ESXi 6.5
May you help pointing me in the right direction for the issue am facing here. Please note that I am only facing issue on VMware ESXi 6.5. Deployments on prior ESXi versions and Workstations are working as expected. Problem Details F5 BIGIP VE is failing to install on VMware ESXi 6.5 with error message "Failed to deploy VM: postNFCData failed: Capacity of uploaded disk is larger than requested". Tests Done Tried deploying BIGIP-11.6.0.0.0.401.LTM-scsi.ova and it failed with same error message. Tried deploying BIGIP-13.0.0.2.0.1671.ALL-scsi.ova and it failed with same error message. Successfully installed BIGIP-12.1.2.1.0.271.LTM_1SLOT-scsi.ova. Observation VM creation with any F5 OVA template with two *.vmdk files is failing. Seems BIGIP-12.1.2.1.0.271.LTM_1SLOT-scsi.ova deployment succeeded because it has ONE *.vmdk file.BIG-IP Configuration Object Naming Conventions
George posted an excellent blog on hostname nomenclature a while back, but something we haven’t discussed much in this space is a naming convention for the BIG-IP configuration objects. Last week, DevCentral community user Deon posted a question on exactly that. Sometimes there are standards just for the sake of having one, but in most cases, and particularly in this case, having standards is a very good thing. Señor Forum, hoolio, and MVP hamish weighed in with some good advice. [app name]_[protocol]_[object type] Examples: www.example.com_http_vs www.example.com_http_pool www.example.com_http_monitor As hoolio pointed out in the forum, each object now has a description field, so the metadata capability is there to establish identifying information (knowledge base IDs, troubleshooting info, application owners), but having an object name that is quickly searchable and identifiable to operational staff is key. Hamish had a slight alternative format for virtuals: [fqdn]_[port] For network virtuals, I’ve always made the network part of the name, as hamish also recommends in his guidance: network VS's tend to be named net-net.num.dot.ed-masklen. e.g. net-0.0.0.0-0 is the default address. Where they conflict (e.g. two defaults depending on src clan, it gets an extra descriptor between net- and the ip address. e.g. net-wireless-0.0.0.0-0 (Default network VS for a wireless VLAN). I don't currently have any network VS's for specific ports. But they'd be something like net-0.0.0.0-0-port Your Turn What standards do you use? Share in the comments section below, or post to the forum thread.
