cancel
Showing results for 
Search instead for 
Did you mean: 

Understanding hardware forwarding limitations (Release notes)

Understanding hardware forwarding limitations (Release notes)

EtherNation_Use
Contributor II
Create Date: Jan 19 2012 10:14AM

Hi,



I am planning on using a Summit X460 switch as a gateway in a dual stack environment. Before I go ahead and configure it for my "hundreds" of subnets, I need to know how many hosts it will support (hardware of course). I've read the Extreme XOS Release Notes (12.6.1), but I need some help interpreting the limitations part. E.g.: IPv6 host entries in hardware—maximum number of IPv6 neighbor entries in hardware.

And: IPv4 ARP entries in hardware with maximum LPM routes.



How many IPv4 and IPv6 hosts will a Summit X460 support in hardware? Also, what will happen when the hardware limit is exceeded? Will some connections bounce back and forth between hardware and software? The switches seem to have very limited software forwarding performance, so want to do anything to avoid forwarding in software. Thanks Kenneth

(from Kenneth_Oestrup)
4 REPLIES 4

EtherNation_Use
Contributor II
Create Date: Jan 31 2012 11:14AM

To check L3 forwarding table consumption use the following:

show iproute reserved-entries statistics

Enabling forwarding table compression will likely help utilization in your case as there are likely to be quite a lot of routes sharing paths. (from Ansley_Barnes)

EtherNation_Use
Contributor II
Create Date: Jan 20 2012 11:52AM

Do you know if there is any way to check the actual hardware L3 forwarding table consumption?

There are some debug commands to check the actual hardware entries but these commands are not RECOMMENDED in the live environment as it utilizes cpu a lot sometimes. You will have to call TAC for those commands.

How does the switch cope with, e.g. 5000 IPv4 ARP entries and 3000 IPv6 neighbors in hardware, at the same time?

The switch should cope fine unless you are lower than the values sepcified in the release notes and by lower i mean around 50%. This is more of a stress testing thing and you would probably get a better idea only if you test it.

(from Arpit_Bhatt)

EtherNation_Use
Contributor II
Create Date: Jan 19 2012 1:05PM

Hi Abhatt, thank you for your reply.

The switch will be used as a "router on a stick" in my scenario. It will be forwarding internet traffic between my BGP routers and my subnets.

Do you know if there is any way to check the actual hardware L3 forwarding table consumption? As I understand there is a way of tweaking how addresses are stored in the hardware, to adapt the network? then it wouldn't necessarily make sense just to count the ARP entries, IPv6 neighbors and LPM routes. Otherwise I could be just a couple of entries below a "catastrophic failure", without knowing it.

I think you may be right that the numbers are mainly from a marketing perspective. My understanding however, was that they were "safe limits" (i.e. the red-line on a tachometer).

The above examples in my original post (in bold) seems more like an elastic measurement, when you put them together. How does the switch cope with, e.g. 5000 IPv4 ARP entries and 3000 IPv6 neighbors in hardware, at the same time?

It's really important for me to know how the equipment will react to my network, as I am trying to replace existing software (x86) based routers, with Extreme Networks switches.

Best regards,

Kenneth

(from Kenneth_Oestrup)

EtherNation_Use
Contributor II
Create Date: Jan 19 2012 12:26PM

FDB (maximum L2 entries)—maximum number of MAC addresses as per the release notes is 32,768

It makes more sense to check the number of FDB entries in your case.

It is always recommended to avoid over-subsrcibing of your switches. These values are more for marketing purposes and hence 50-75% would be an ideallistic approach.

Anyways once done monitor your cpu-utilization using"show cpu-monitoring" or "top" and verify things work normall as they should

I believe exceeding the number of hosts can put load on the cpu and may crash the switch. Not a 100% on this one though.

(from Arpit_Bhatt)
GTM-P2G8KFN