Re: Maximum number of ip helper-addresses in IOS 16.6.6 Everest

vincent.morton · ‎08-09-2019

We have a customer who has a number of 3850 switches running IOS-XE 3.6.6

These switches have a lot of ip helper-addresses configured one one VLAN (>50)

We need to upgrade them to 16.6.6 but 16.6.6 restricts the number of ip helper-addresses to 16 per VLAN interface when ipbase feature set is active (this is what they have on 3.6.6 so ideally that's what they want on 16.6.6). I can't find any documentation stating whether that limit is increased if we increase the license level. In fact I can't even find the limit of 16 documented, I only know it exists becuase it won't allow me to add a 17th address in v16.6.6. Does anyone know if it is possible to increase this limit?

There is no need to tell me that even having 16 is not a good idea but the customer has found themselves in a position where that configuration was required to accommodate a particular system and they still rely on it.

It was like that when I got here and I need to find a way of accommodating the current setup and at the moment all I've got as options if the limit can't be increased are rationalise the ip helper-addresses or rip it out and start again (which I'm pretty sure they won't go for) so any help would be welcome. If the limit can't be increased, I'm sure to be asked why it has been imposed in the newer IOS version so if anyone can point me to a good document that explains that, or even one which explains concisely why having so many ip helper-addresses is not a good idea, that would also be welcome.

Reza Sharifi · ‎08-09-2019

May not be helpful to you but it is interesting to know that the 3750s support

more than 30 according to this post. Not sure what IOS version.

https://community.cisco.com/t5/switching/maximun-number-of-quot-ip-helper-address-quot/td-p/1917217

vincent.morton · ‎08-12-2019

Thanks Reza, I always liked 3750's but unfortunately the customer has >200 of the 3850's so I can't see them replacing them all. It looks like I'll need to work through rationalising the number of helper addresses under each interface. If anyone knows of a doc which explains, preferably in non-technical terms, why having lots of ip helper addresses isn't a good idea and/or why the limit has been imposed that would be appreciated.

Leo Laohoo · ‎08-09-2019

You may need to create a TAC Case.

Paul Chapman · ‎08-10-2019

I have to agree with Leo. You will need a TAC case to see about altering the limit.

The first question that comes to my mind though is why do you need more than 3 helpers for a given interface? I can see primary/secondary DHCP and an imaging server. Have you verified that all the IP helpers are actually live servers and not just legacy garbage that the client has never cleaned out?

Best Regards,

PSC

vincent.morton · ‎08-12-2019

Paul,

There will be room to rationalise the addresses but some of the addresses will be required in each part of the network. Its a sizeable network so and going round it, working out which addresses are needed where, making the changes and getting everything tested will be time consuming so I'm trying to avoid it.

I'm also not inclined to open a TAC case to ask how to do something that's contrary to good practice so that I can perpetuate something which shouldn't have been done in the first place.

If I need to go down the route of rationalising the addressing then I will but I'm still anticipating being asked why a switch code upgrade would stop the customer's system from working so if anyone can point me to a document which explains, preferably in non-technical terms, why the limit was imposed and/or why having loads of ip helper addresses is not a good idea, then that would at least make that part of the job easier.

Thanks,

Vincent

Martin L · ‎08-11-2019

why upgrade them to 16? what's wrong with 3.6? we ran lot of c3850 with 3.7.x in retail environment.

Leo Laohoo · ‎08-11-2019

@Martin L wrote:
why upgrade them to 16? what's wrong with 3.6? we ran lot of c3850 with 3.7.x in retail environment.

What's the CPU like? Any of them exhibiting very high CPU?

It could be CSCux39490. Very "popular" bug and, as of 12 August 2019, has 762 TAC cases attached.

vincent.morton · ‎08-12-2019

Thanks Leo, that looks like a pretty good reason to avoid 3.7 to me, although the bug notice does show a fixed-in release 3.7(4)E

The customer's reason for upgrading to Everest was that the current IOS failed a recent security audit. The End of Vulnerability/Security Support: OS SW for IOS-XE passed on May 1, 2018. Their current IOS didn't fail a previous audit so it looks like it's a relatively new vulnerability so it's likely that 3.7 will also be affected, hence the reason for upgrading to the Everest release. Does anyone know if Denali, Fuji or Gibraltar releases have this 16 ip helper address limit?

Giuseppe Larosa · ‎08-12-2019

Hello Vincent,

your customer is abusing of the ip helper-address feature.

Likely they have developed an in house application many years ago that sends out broadcast frames instead of using unicast IPv4 routing.

There is no other possible explanation for the need to have more then 16 helper-addresses under the same SVI.

A possible explanation for putting a limit of 16 is the following:

the device needs to convert each received broadcast frame that satisfies the ip forward-protocol settings (global command) in 16 different unicast versions to send to each of the configured helper addresses.

This requires processing overhead and you can say that this is done by the main cpu (process switched) and the limit has been placed to protect the switch main cpu from possible excessive load.

The only way to "summarize" IP helper addresses would be to use directed broadcast addresses that are still routable instead of conventional unicast IP addresses.

However, if all this has been triggered by a security audit the next audit will ask you to disable sending of directed broadcast out of every interface where servers are connected.

So you could end to fail the audit for this reason :)

Hope to help

Giuseppe

baronvongogo · ‎08-27-2019

Guiseppe,

Thanks for the reply. I didn't want to say our customer is abusing the ip helper-address feature but it is one way of putting it.

Using directed broadcast addresses is what I plan to do if I need to. Obviously, I'd be happier if the legacy system was replaced but I don't have much of a say in that. I don't actually know why the current IOS failed the audit but that's an interesting point you make about disabling directed broadcasts. It might be enough to convince them they need to do something about the legacy system.

Vincent

Giuseppe Larosa · ‎08-27-2019

Hello Vincent,

>> Using directed broadcast addresses is what I plan to do if I need to. Obviously, I'd be happier if the legacy system was replaced but I don't have much of a say in that. I don't actually know why the current IOS failed the audit but that's an interesting point you make about disabling directed broadcasts. It might be enough to convince them they need to do something about the legacy system.

Disabling the ip directed broadcast is considered a security best practice and I think it is even the default now in modern IOS versions.

I used the term abuse of ip helper-address feature from a technical point of view.

And yes it is high time for your customer to update their legacy application.

Hope to help

Giuseppe

vincent.morton · ‎08-12-2019

Martin,

The customer's reason for upgrading to Everest was that the current IOS failed a recent security audit. The End of Vulnerability/Security Support: OS SW for IOS-XE passed on May 1, 2018. Their current IOS didn't fail a previous audit so it looks like it's a relatively new vulnerability so it's likely that 3.7 will also be affected, hence the reason for upgrading to the Everest release.

Does anyone know if Denali, Fuji or Gibraltar releases have this 16 ip helper address limit?

Regards,

Vincent

Leo Laohoo · ‎08-12-2019

@vincent.morton wrote:

Does anyone know if Denali, Fuji or Gibraltar releases have this 16 ip helper address limit?

Either download each version and try or raise a TAC Case so TAC can determine if there is ever a version that can support 16 DHCP helper IP address.

If there is none, escalate with your Cisco AM/SE and see if they can raise a Performance Enhancement Request (PER) with the BU.