f5devcentral / f5-cloud-failover-extension

F5 Cloud Failover Extension (Archived)
Apache License 2.0
5 stars 1 forks source link

Azure setup #10

Closed Charding2008 closed 4 years ago

Charding2008 commented 4 years ago

Having two issue following the Azure lab guide

Have installed f5-cloud-failure on.

Issues 1: Posting example declaration below fails { "class": "Cloud_Failover", "environment": "azure", "externalStorage": { "scopingTags": { "f5_cloud_failover_label": "mydeployment" } }, "failoverAddresses": { "scopingTags": { "f5_cloud_failover_label": "mydeployment" } }, "failoverRoutes": { "scopingTags": { "f5_cloud_failover_label": "mydeployment" }, "scopingAddressRanges": [ "192.168.1.0/24" ] } } error: {"message":"Cloud Provider initialization failed with error: connect ECONNREFUSED 169.254.169.254:80 Error: connect ECONNREFUSED 169.254.169.254:80\n at Object._errnoException (util.js:1022:11)\n at _exceptionWithHostPort (util.js:1044:20)\n at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1198:14)"

question what is the default Address range meant to be? my bigip's are all in the 10.x range.

Issue 2. Setting up access to Azure’s Instance Metadata Service

Not sure I'm using the correct IP's as the defaults provide do not get saved ( tried with both tmsh and Postman). What is the 169.xxx address? think it needs more clarity here.

jsevedge commented 4 years ago

@Charding2008 The error is a result of one of the prereqs not being fulfilled I believe. CFE needs to talk to the Azure metadata service, so the BIG-IP routing needs to be set up for that. We describe that in some detail here: https://clouddocs.f5.com/products/extensions/f5-cloud-failover/latest/userguide/azure.html#setting-up-access-to-azure-s-instance-metadata-service

The scoping address ranges is meant to filter down not only which route tables but also which specific routes in the route table should have the next hop address updated (if route failover is required). So the scoping address ranges should match the cidr blocks of any routes where the next hop address should be updated to follow the active BIG-IP. This could use some additional explanation in the documentation.

Charding2008 commented 4 years ago

Hi James

Presumably I should be able to ping the Azure MetaData IP?

I’ve added the route per the guide you mention, as well the admin privledges. But ping not working, I using the Azure LB with a pair of F5 LB’s in A/A as per the Azure guide - https://github.com/F5Networks/f5-azure-arm-templates/tree/master/supported/failover/same-net/via-lb/3nic/existing-stack/byol

Here’s the results:

tmsh modify sys db config.allow.rfc3927 value enable

[Azureuser@big-ip0:Active:In Sync] ~ # tmsh create sys management-route metadata-route network 169.254.169.254/32 gateway 192.0.2.1

01020037:3: The requested Management Route (/Common/metadata-route) already exists.

[Azureuser@big-ip0:Active:In Sync] ~ # tmsh save sys config

Saving running configuration...

Saving Ethernet mapping...done

[Azureuser@big-ip0:Active:In Sync] ~ # ping 169.254.169.254

PING 169.254.169.254 (169.254.169.254) 56(84) bytes of data.

^C

--- 169.254.169.254 ping statistics ---

7 packets transmitted, 0 received, 100% packet loss, time 5999ms

Thanks Charles

From: James Sevedge notifications@github.com Reply to: f5devcentral/f5-cloud-failover-extension reply@reply.github.com Date: Tuesday, 21 January 2020 at 21:57 To: f5devcentral/f5-cloud-failover-extension f5-cloud-failover-extension@noreply.github.com Cc: charles harding Charles.Harding@F5.com, Mention mention@noreply.github.com Subject: Re: [f5devcentral/f5-cloud-failover-extension] Azure setup (#10)

EXTERNAL MAIL: noreply@github.com

@Charding2008https://github.com/Charding2008 The error is a result of one of the prereqs not being fulfilled I believe. CFE needs to talk to the Azure metadata service, so the BIG-IP routing needs to be set up for that. We describe that in some detail here: https://clouddocs.f5.com/products/extensions/f5-cloud-failover/latest/userguide/azure.html#setting-up-access-to-azure-s-instance-metadata-service

The scoping address ranges is meant to filter down not only which route tables but also which specific routes in the route table should have the next hop address updated (if route failover is required). So the scoping address ranges should match the cidr blocks of any routes where the next hop address should be updated to follow the active BIG-IP.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/f5devcentral/f5-cloud-failover-extension/issues/10?email_source=notifications&email_token=ABZPVDHV6ZYW4TIZO6BY2T3Q65VULA5CNFSM4KJXEG52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJRNF2Q#issuecomment-576901866, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABZPVDDIY6MAMN4EKMEBL63Q65VULANCNFSM4KJXEG5Q.

Charding2008 commented 4 years ago

Curl fails also, think it’s the route gateway of 192.0.2.1 – in the azure example what device is the 192.0.2.1?

[Azureuser@big-ip0:Active:In Sync] ~ # curl -H Metadata:true "http://169.254.169.254/metadata/instance" curl: (7) Failed to connect to 169.254.169.254 port 80: Connection refused

From: charles harding Charles.Harding@F5.com Date: Wednesday, 22 January 2020 at 11:14 To: f5devcentral/f5-cloud-failover-extension reply@reply.github.com, f5devcentral/f5-cloud-failover-extension f5-cloud-failover-extension@noreply.github.com Cc: Mention mention@noreply.github.com Subject: Re: [f5devcentral/f5-cloud-failover-extension] Azure setup (#10)

Hi James

Presumably I should be able to ping the Azure MetaData IP?

I’ve added the route per the guide you mention, as well the admin privledges. But ping not working, I using the Azure LB with a pair of F5 LB’s in A/A as per the Azure guide - https://github.com/F5Networks/f5-azure-arm-templates/tree/master/supported/failover/same-net/via-lb/3nic/existing-stack/byol

Here’s the results:

tmsh modify sys db config.allow.rfc3927 value enable

[Azureuser@big-ip0:Active:In Sync] ~ # tmsh create sys management-route metadata-route network 169.254.169.254/32 gateway 192.0.2.1

01020037:3: The requested Management Route (/Common/metadata-route) already exists.

[Azureuser@big-ip0:Active:In Sync] ~ # tmsh save sys config

Saving running configuration...

Saving Ethernet mapping...done

[Azureuser@big-ip0:Active:In Sync] ~ # ping 169.254.169.254

PING 169.254.169.254 (169.254.169.254) 56(84) bytes of data.

^C

--- 169.254.169.254 ping statistics ---

7 packets transmitted, 0 received, 100% packet loss, time 5999ms

Thanks Charles

From: James Sevedge notifications@github.com Reply to: f5devcentral/f5-cloud-failover-extension reply@reply.github.com Date: Tuesday, 21 January 2020 at 21:57 To: f5devcentral/f5-cloud-failover-extension f5-cloud-failover-extension@noreply.github.com Cc: charles harding Charles.Harding@F5.com, Mention mention@noreply.github.com Subject: Re: [f5devcentral/f5-cloud-failover-extension] Azure setup (#10)

EXTERNAL MAIL: noreply@github.com

@Charding2008https://github.com/Charding2008 The error is a result of one of the prereqs not being fulfilled I believe. CFE needs to talk to the Azure metadata service, so the BIG-IP routing needs to be set up for that. We describe that in some detail here: https://clouddocs.f5.com/products/extensions/f5-cloud-failover/latest/userguide/azure.html#setting-up-access-to-azure-s-instance-metadata-service

The scoping address ranges is meant to filter down not only which route tables but also which specific routes in the route table should have the next hop address updated (if route failover is required). So the scoping address ranges should match the cidr blocks of any routes where the next hop address should be updated to follow the active BIG-IP.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/f5devcentral/f5-cloud-failover-extension/issues/10?email_source=notifications&email_token=ABZPVDHV6ZYW4TIZO6BY2T3Q65VULA5CNFSM4KJXEG52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJRNF2Q#issuecomment-576901866, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABZPVDDIY6MAMN4EKMEBL63Q65VULANCNFSM4KJXEG5Q.

Charding2008 commented 4 years ago

Fixed, the 192.0.2.1 is the Management’s default route, which perhaps wasn’t obvious to me. Maybe worth adding that address to the diagram, or highlighting it may need to change and where to check etc.

Thanks Charles

From: charles harding Charles.Harding@F5.com Date: Wednesday, 22 January 2020 at 11:26 To: f5devcentral/f5-cloud-failover-extension reply@reply.github.com, f5devcentral/f5-cloud-failover-extension f5-cloud-failover-extension@noreply.github.com Cc: Mention mention@noreply.github.com Subject: Re: [f5devcentral/f5-cloud-failover-extension] Azure setup (#10)

Curl fails also, think it’s the route gateway of 192.0.2.1 – in the azure example what device is the 192.0.2.1?

[Azureuser@big-ip0:Active:In Sync] ~ # curl -H Metadata:true "http://169.254.169.254/metadata/instance" curl: (7) Failed to connect to 169.254.169.254 port 80: Connection refused

From: charles harding Charles.Harding@F5.com Date: Wednesday, 22 January 2020 at 11:14 To: f5devcentral/f5-cloud-failover-extension reply@reply.github.com, f5devcentral/f5-cloud-failover-extension f5-cloud-failover-extension@noreply.github.com Cc: Mention mention@noreply.github.com Subject: Re: [f5devcentral/f5-cloud-failover-extension] Azure setup (#10)

Hi James

Presumably I should be able to ping the Azure MetaData IP?

I’ve added the route per the guide you mention, as well the admin privledges. But ping not working, I using the Azure LB with a pair of F5 LB’s in A/A as per the Azure guide - https://github.com/F5Networks/f5-azure-arm-templates/tree/master/supported/failover/same-net/via-lb/3nic/existing-stack/byol

Here’s the results:

tmsh modify sys db config.allow.rfc3927 value enable

[Azureuser@big-ip0:Active:In Sync] ~ # tmsh create sys management-route metadata-route network 169.254.169.254/32 gateway 192.0.2.1

01020037:3: The requested Management Route (/Common/metadata-route) already exists.

[Azureuser@big-ip0:Active:In Sync] ~ # tmsh save sys config

Saving running configuration...

Saving Ethernet mapping...done

[Azureuser@big-ip0:Active:In Sync] ~ # ping 169.254.169.254

PING 169.254.169.254 (169.254.169.254) 56(84) bytes of data.

^C

--- 169.254.169.254 ping statistics ---

7 packets transmitted, 0 received, 100% packet loss, time 5999ms

Thanks Charles

From: James Sevedge notifications@github.com Reply to: f5devcentral/f5-cloud-failover-extension reply@reply.github.com Date: Tuesday, 21 January 2020 at 21:57 To: f5devcentral/f5-cloud-failover-extension f5-cloud-failover-extension@noreply.github.com Cc: charles harding Charles.Harding@F5.com, Mention mention@noreply.github.com Subject: Re: [f5devcentral/f5-cloud-failover-extension] Azure setup (#10)

EXTERNAL MAIL: noreply@github.com

@Charding2008https://github.com/Charding2008 The error is a result of one of the prereqs not being fulfilled I believe. CFE needs to talk to the Azure metadata service, so the BIG-IP routing needs to be set up for that. We describe that in some detail here: https://clouddocs.f5.com/products/extensions/f5-cloud-failover/latest/userguide/azure.html#setting-up-access-to-azure-s-instance-metadata-service

The scoping address ranges is meant to filter down not only which route tables but also which specific routes in the route table should have the next hop address updated (if route failover is required). So the scoping address ranges should match the cidr blocks of any routes where the next hop address should be updated to follow the active BIG-IP.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/f5devcentral/f5-cloud-failover-extension/issues/10?email_source=notifications&email_token=ABZPVDHV6ZYW4TIZO6BY2T3Q65VULA5CNFSM4KJXEG52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJRNF2Q#issuecomment-576901866, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABZPVDDIY6MAMN4EKMEBL63Q65VULANCNFSM4KJXEG5Q.

shyawnkarim commented 4 years ago

Thanks for reaching out to us with your issue. I've gone ahead and created Jira Issue #136 to add additional clarity around routes.