BigIron IronCore / JetCore

From FoundryWiki

Jump to: navigation, search

Contents

[edit] Main purpose

[edit] Available models


[edit] Main features

  • Full Layer 2/3/4
  • OSPF, OSPFv3 on software 08.0.1x and later
  • BGP4, IPv6 support on software 08.0.1x and later
  • sFlow support (Jetcore only)

[edit] Configuration hints and recommendations

[edit] IP route and cache

Especially when running BGP with a full internet route table, there are some system-max settings that need to be increased, leaving these default will result in packetloss, unreachable routes and the unit throwing packets over the CPU (a quality at which ironcore and jetcore units aren't very strong at), recommended are: 

system-max ip-cache 400000
system-max ip-route 400000

[edit] ICMP and SYN flooding

Foundry notes If someone tries to ping flood the router, this will handle it. If more than 4000 ICMP packets per second are received, the router will drop all ICMP for 60 seconds. If someone is pinging through the router, apply the command to an interface (e.g. int ve 2), or all of them. 

ip icmp burst-normal 1000 burst-max 4000 lockup 60

If someone tries to SYN flood the router (or through the router) the following line applied globally or to the interfaces will help: 

ip tcp burst-normal 10 burst-max 100 lockup 60

[edit] CAM partitioning

On combined BGP/OSPF setups with a lot of servers and destinations, CAM space for layer3 quickly can become a bottleneck, full CAM can result in IP's and VLAN's becoming unreachable and high CPU usage due to packets being thrown over the CPU.

CAM space can be 'moved' around using partitioning commands. You can 'shift' the available CAM space between L2/3/4 (note that L4 has a mandatory minimum 25% allocation of the available CAM space).

CAM space can be partitioned on a global level or on a per-blade level, example for a router-only setup where little L2 space is needed in config mode (note that you need to reload for this to become active): 

cam-partition l2 3 l3 72 l4 25

This will allocate 3% to Layer2, 72% to Layer3 and 25% to Layer4

Example result with above config on a J-BxG card (8 ports SFP gigabit card with 2x2Mbit CAM): 

==== SLOT 3 CAM PARTITION ====

IGC: 8 (0x08)
Number of CAM devices per IGC:  1
Number of hw entries per CAM:  0x08000
Total size of CAM = 2Mbits
complete CAM index range per IGC:
  (sw) 1 - 56319  (1 - 0x0dbff), total entries: 56319 (0x0dbff)
  (hw) 0 - 32767  (0 - 0x07fff), total entries: 32768 (0x08000)
Percentage of CAM hardware entries for each partition:
  Layer3 = 23552 (1.4375Mbits)  (71.875%)
      Level3 = 2047 (0.124938Mbits)     (6.246948%)
      Level2 = 2048 (0.125Mbits)        (6.25%)
  Layer2 = 1024 (0.0625Mbits)   (3.125%)
  Layer4 = 8192 (0.5Mbits)      (25%)


IGC: 9 (0x09)
Number of CAM devices per IGC:  1
Number of hw entries per CAM:  0x08000
Total size of CAM = 2Mbits
complete CAM index range per IGC:
  (sw) 1 - 56319  (1 - 0x0dbff), total entries: 56319 (0x0dbff)
  (hw) 0 - 32767  (0 - 0x07fff), total entries: 32768 (0x08000)
Percentage of CAM hardware entries for each partition:
  Layer3 = 23552 (1.4375Mbits)  (71.875%)
      Level3 = 2047 (0.124938Mbits)     (6.246948%)
      Level2 = 2048 (0.125Mbits)        (6.25%)
  Layer2 = 1024 (0.0625Mbits)   (3.125%)
  Layer4 = 8192 (0.5Mbits)      (25%)


[edit] net-aggregation

WARNING: Although many people have reported success using these features, on Full BGP table routers I've seen OSPF tables get corrupt and units rebooting at random after only a few days of usage

Also the aggregate features will cause a higher CPU usage due to compression of CAM tables at the configured interval.

Chassis Layer 3 Switches use Content Addressable Memory (CAM) as a fast lookup cache to optimize IP forwarding. The CAM contains an IP route's destination and the IP address of the next-hop gateway, as well as pointers to packet information in various system buffers. When the Layer 3 Switch is ready to forward a packet to its destination, the Layer 3 Switch checks the CAM for a forwarding entry for the packet.

By default, the CAM is optimized for environments with a lot of routes to different destination networks. Each CAM entry provides fast-path information for a different destination sub-net.

You can configure the following cache and CAM optimization options:

  • ip net-aggregate - Optimizes the CAM for devices that have very large IP route tables (100,000 or more), where most of those routes use the same next hops as the default route.
  • ip dr-aggregate - Optimizes the CAM for devices that have few explicit routes (about 30 or fewer) and use the default route for most of the traffic.

Regardless of whether one of the CAM optimization options described above is enabled, the Layer 3 Switch uses the IP cache to store forwarding information, then uses the forwarding information in the IP cache to program the CAM. The IP cache can contain host route entries, network route entries, and aggregate entries (aggregate routes of varying prefix lengths or fixed-size portions of the default route with 12-bit prefixes). However, regardless of the CAM optimization options, the show ip cache command displays only the host route entries. Disabling Unicast High-Performance Mode

By default, the unicast high-performance mode is enabled. This mode increases the device's capacity for unicast entries. To disable or re-enable the feature, use the following CLI method. NOTE: To place a change to the high-performance mode into effect, you must reload the software after saving the change to the startup-config file. NOTE: The feature is disabled by default in software releases earlier than 07.5.01.


[edit] Files and handy documents

Retrieved from "http://foundry.wikked.net/wiki/BigIron_IronCore_/_JetCore"
Personal tools