After finishing part 3, our BIG IP and BIG IQ devices are now properly deployed and configured we need now to move over SCVMM2012R2 console and add our BIG IP as a network service to serve as our NVGRE gateway.
Before doing so, be sure that you have installed the F5 network gateway powershell module onto the VMM Server (each node if in HA).
Navigate now to the F5GatewayProvider folder in your powershell modules folder and edit the script gateway-one-bigip.cfg
We are going to change only two entries into the script (these in bold) but you can try (at your own risk) to play with other options
-
<GatewaySettings>
<!– The management address of the BIG-IQ –>
<BigIqAddress>192.168.2.250</BigIqAddress>
<!– The name of the BIG-IQ device group where we will find one BIG-IPs –>
<BigIqDeviceGroup>scvmm</BigIqDeviceGroup>
<!– When the plugin creates a provider self-IP , what should be staged and enforced firewall policies be? –>
<!– If you have not provisioned AFM or you do not want to use it on provider self IPs, leave this empty –>
<!– If you fill in a policy name, it is your responsibility to ensure that it’s created before it’s needed. –>
<ProviderFwEnforcedPolicy></ProviderFwEnforcedPolicy>
<ProviderFwStagedPolicy></ProviderFwStagedPolicy>
<!– If you might ever have two different VM Networks that contain the same IP address, –>
<!– then UseRouteDomains should be true. If you’re not sure, leave it as true because it’s safer –>
<!– If you are sure that you’ll never re-use IP addresses in different VM Networks, you could –>
<!– set this to false to avoid a small scalability hit in configuring your BIG-IP –>
<UseRouteDomains>true</UseRouteDomains>
<!– This is the range of route domains that may be used by this gateway on the BIG-IPs. –>
<!– It is only relevant if UseRouteDomains is true. –>
<!– This is a really important setting if you create multiple gateways on the same –>
<!– set of BIG-IPs (which is common if you want to do an active-active gateway setup) –>
<!– This ensures that each gateway will not use route domains belonging to other gateways –>
<!– sharing the same BIG-IP. Make sure that for each gateway that shares a set of BIG-IPs, –>
<!– you give a unique range of route domains. (Gateways on different BIG-IPs can use the same –>
<!– range of route domains.) –>
<!– Note that this range is inclusive: all of the route domains from first to last will be used, –>
<!– including ‘first’ and ‘last’ –>
<RouteDomainRange first=”1″ last=”500″/>
<!– If you are using a plain old BIG-IP, 11.5.1 or earlier, then UseInboundTunnelMode should be false –>
<!– If you are using the engineering hotfix that makes the NVGRE tunnel pair look like a single tunnel, it should be true –>
<!– If you’re not sure, ask support or set it to false. Both should work, but when available setting it to true –>
<!– is nicer. –>
<UseInboundTunnelMode>false</UseInboundTunnelMode>
<!– If CreateForwardingVirtual is true, when a gateway is added to a customer virtual subnet, –>
<!– a forwarding virtual server will be added. Note that this is only done if UseRouteDomains is also true –>
<CreateForwardingVirtual>true</CreateForwardingVirtual>
<!– How do you want to handle SNAT on the forwarding virtual, assuming you requested it? –>
<!– Currently you can specify two values: none or automap. If you’re not sure, leave it as automap –>
<ForwardingVirtualSNAT>automap</ForwardingVirtualSNAT>
<!– When the plugin creates a self-IP on a customer’s virtual subnet, what traffic should be allowed? –>
<!– You can specify “all”, “none”, or “default”, but not custom values –>
<CustomerSelfIpAllow>all</CustomerSelfIpAllow>
<!– When the plugin creates a self-IP on a customer’s virtual subnet, what should be staged firewall policy be? –>
<!– If you have not provisioned AFM or you do not want to use it on customer self IPs, leave this empty –>
<!– IF you fill in a policy name, it is your responsibility to ensure that it’s created before it’s needed. –>
<CustomerSelfFwStagedPolicy></CustomerSelfFwStagedPolicy>
<!– When the plugin creates a self-IP on a customer’s virtual subnet, what should be enforced qfirewall policy be? –>
<!– If you have not provisioned AFM or you do not want to use it on customer self IPs, leave this empty –>
<!– IF you fill in a policy name, it is your responsibility to ensure that it’s created before it’s needed. –>
<CustomerSelfFwEnforcedPolicy></CustomerSelfFwEnforcedPolicy>
<!– If you need to set the MTU on the NVGRE tunnels to a specific value, fill this in –>
<!– If you do not set it, leave it as “0” and the MTU will be set automatically –>
<!– (which is a good idea if you’re not sure) –>
<TunnelMtu>0</TunnelMtu>
<!– Normally leave this alone, but if you need to change to an alternate NVGRE tunnel –>
<!– profile, you can set it here. It must be created, and it must be for NVGRE–>
<TunnelProfile>nvgre</TunnelProfile>
<!– If DumpGatewayState is true, then we will create a file in the same directory as the log –>
<!– file named F5-Gateway-CONFIGFILENAME-state.txt. It will have information about –>
<!– the mapping of SCVMM routing domains to route domains as well as the set of VSIDs –>
<!– managed within each routing domain. It’s optional because it takes time to generate –>
<!– and you may not care. It’s useful if you are building BIG-IP config on –>
<!– top of the config generated by the plugin. It may be less useful if UseRouteDomains is false –>
<DumpGatewayState>true</DumpGatewayState>
</GatewaySettings>
Now we can launch the SCVMM2012R2 console and go to Fabric | Networking | Network Service and “Add Network Service”
Fill in a name.
Select F5 Networks Inc from manufacturer and BIG-IP as model
Click Next and click Create Run as account, you will use the Admin credential of BIG IP.
Specify the name of the configuration file we modified earlier.
Click Next and then click Test to ensure everything is ok.
Check SCVMM jobs
Now we need to configure connectivity settings on our gateway in order to define frontend and backend.
Check SCVMM jobs again
it looks like everything went fine and we can start using our new gateway. So let’s try it !
Go to VM Network and if you have an existing HNV network, right click on it and go to connectivity and the enable the gateway.
Please not that only direct routing is allowed with BIG IP, we are not doing NAT!
Now let’s check if it really did work!
From SCVMM jobs it looks quite good
let’s check now in BIG IP
And finally let’s check an a hyper-v host using get-netvirtualizationlookuprecord
We can also take a look into the gateway logs which will be located on our VMM Server.
Everything worked as intended as you can see my VM inside my HNV network use 10.0.0.5 ip and has been given by our gateway 10.10.0.5 on our PA network.
I hope that this series about configuring F5 BIG IP VE for SCVMM2012R2 has been useful to you. I did run into this work this summer and didn’t have the time since to put every pieces into an article but is now finally done! You can start now playing a bit with BIG IP and BIG IQ and not only for NVGRE but other capabilities as well such as NLB, application edge and so on.
Related
