RED 10 and static WAN

Dear Jack,

Can you give me tutorial, how to setup static ip?
where is RED provisioning server?

Hi ghufron,

perhaps this link will help you: https://support.astaro.com/support/index.php/RED_Initial_Setup

tov

Hi Jack,

Thanks for your input and sorry about the delay of this feedback. I followed your advice and it worked like a charm in my lab environment.

But I'd like to share my experience when we last week tried to install the first RED in a production environment for a client. This scenario is a connection with a static IP on the WAN interface on the RED.

I set up the initial configuration according to your advice in this thread. The RED was then shipped to the location where it should go in production. This is when the problems start. The RED reboots every 70-75 seconds and the blink codes tells me “Static network config invalid, trying DHCP fallback in 10 seconds”. We tried to power off/on both the ISP router and the RED, but the result was the same. We connected a laptop directly to the ISP router and set the static IP. This worked just as it should. Connection to the Internet was verified ok. I checked the log files of the main ASG but nothing showed up about the RED. Clearly, the RED never got as far as to the main ASG.

At this point I was about to blame the RED. So I configured a new RED and shipped it to the location. The result was the same. No connection to the main ASG and the RED rebooted every 70-75 seconds. Things were getting frustrating and now I started point my anger to the ISP router. It's a Cisco 870. Commonly the interfaces on such routers shut down when there's no link. So I was thinking, maybe the interface doesn't have the time to come up before the RED thinks something is wrong and falls back to DHCP and then reboots. The solution to this was of course to install a switch between the LAN interface on the ISP router and the WAN interface on the RED. And what do you know, FINALLY, the connection to the main ASG came up and everything worked as it should.

So what did we learn about this? Of course we can continue to install a switch between the ISP router and the RED. But why this extra cost if it can be solved differently? We could ask the ISP to configure the interface to never shut down even if there's no link, if it's possible. But we'll always risk loosing that extra configuration deep down in “ISP bureaucracy” during upgrades and what not. So maybe the best solution to solve this is to let the RED try for a bit longer before it falls back to DHCP and reboots.

This became a long rant. But I hope some of you that have some impact at Astaro HQ, or stumbled into the same problem, read this to the end. We will talk to our Astaro distributor, or directly to Astaro, and see if something can be done about this issue. I know that my client appreciate the extra effort we've put in to this case to solve the problem. And since this was a new client for us that went from a competitive brand of firewalls to Astaro, we feel pretty damn good that we managed to solve this issue as fast as we did.


/Hansi

Hi Jack,

Thanks for your input and sorry about the delay of this feedback. I followed your advice and it worked like a charm in my lab environment.

But I'd like to share my experience when we last week tried to install the first RED in a production environment for a client. This scenario is a connection with a static IP on the WAN interface on the RED.

I set up the initial configuration according to your advice in this thread. The RED was then shipped to the location where it should go in production. This is when the problems start. The RED reboots every 70-75 seconds and the blink codes tells me “Static network config invalid, trying DHCP fallback in 10 seconds”. We tried to power off/on both the ISP router and the RED, but the result was the same. We connected a laptop directly to the ISP router and set the static IP. This worked just as it should. Connection to the Internet was verified ok. I checked the log files of the main ASG but nothing showed up about the RED. Clearly, the RED never got as far as to the main ASG.

At this point I was about to blame the RED. So I configured a new RED and shipped it to the location. The result was the same. No connection to the main ASG and the RED rebooted every 70-75 seconds. Things were getting frustrating and now I started point my anger to the ISP router. It's a Cisco 870. Commonly the interfaces on such routers shut down when there's no link. So I was thinking, maybe the interface doesn't have the time to come up before the RED thinks something is wrong and falls back to DHCP and then reboots. The solution to this was of course to install a switch between the LAN interface on the ISP router and the WAN interface on the RED. And what do you know, FINALLY, the connection to the main ASG came up and everything worked as it should.

So what did we learn about this? Of course we can continue to install a switch between the ISP router and the RED. But why this extra cost if it can be solved differently? We could ask the ISP to configure the interface to never shut down even if there's no link, if it's possible. But we'll always risk loosing that extra configuration deep down in “ISP bureaucracy” during upgrades and what not. So maybe the best solution to solve this is to let the RED try for a bit longer before it falls back to DHCP and reboots.

This became a long rant. But I hope some of you that have some impact at Astaro HQ, or stumbled into the same problem, read this to the end. We will talk to our Astaro distributor, or directly to Astaro, and see if something can be done about this issue. I know that my client appreciate the extra effort we've put in to this case to solve the problem. And since this was a new client for us that went from a competitive brand of firewalls to Astaro, we feel pretty damn good that we managed to solve this issue as fast as we did.


/Hansi

Hello Hansi,

Expect this to be addressed in an upcoming up2date package (I don't have a release number or ETA).  Thank you for having the patience to work through it, and for describing the issue clearly.

Hi Jack,

Thanks for your input and sorry about the delay of this feedback. I followed your advice and it worked like a charm in my lab environment.

But I'd like to share my experience when we last week tried to install the first RED in a production environment for a client. This scenario is a connection with a static IP on the WAN interface on the RED.

I set up the initial configuration according to your advice in this thread. The RED was then shipped to the location where it should go in production. This is when the problems start. The RED reboots every 70-75 seconds and the blink codes tells me “Static network config invalid, trying DHCP fallback in 10 seconds”. We tried to power off/on both the ISP router and the RED, but the result was the same. We connected a laptop directly to the ISP router and set the static IP. This worked just as it should. Connection to the Internet was verified ok. I checked the log files of the main ASG but nothing showed up about the RED. Clearly, the RED never got as far as to the main ASG.

At this point I was about to blame the RED. So I configured a new RED and shipped it to the location. The result was the same. No connection to the main ASG and the RED rebooted every 70-75 seconds. Things were getting frustrating and now I started point my anger to the ISP router. It's a Cisco 870. Commonly the interfaces on such routers shut down when there's no link. So I was thinking, maybe the interface doesn't have the time to come up before the RED thinks something is wrong and falls back to DHCP and then reboots. The solution to this was of course to install a switch between the LAN interface on the ISP router and the WAN interface on the RED. And what do you know, FINALLY, the connection to the main ASG came up and everything worked as it should.

So what did we learn about this? Of course we can continue to install a switch between the ISP router and the RED. But why this extra cost if it can be solved differently? We could ask the ISP to configure the interface to never shut down even if there's no link, if it's possible. But we'll always risk loosing that extra configuration deep down in “ISP bureaucracy” during upgrades and what not. So maybe the best solution to solve this is to let the RED try for a bit longer before it falls back to DHCP and reboots.

This became a long rant. But I hope some of you that have some impact at Astaro HQ, or stumbled into the same problem, read this to the end. We will talk to our Astaro distributor, or directly to Astaro, and see if something can be done about this issue. I know that my client appreciate the extra effort we've put in to this case to solve the problem. And since this was a new client for us that went from a competitive brand of firewalls to Astaro, we feel pretty damn good that we managed to solve this issue as fast as we did.


/Hansi

Another solution would be to enable Portfast on the Cisco's internal port; this is probably an STP issue -- but as Jack said, they are going to modify the firmware of the RED to workaround it. -- it does sound a lot like a similar issue we had with the new Wireless Access points in beta testing.