Cisco 7600 and 6500

[Antonio_1_2]

Hello,

I have a question regarding performances of Cisco 7600 or Cisco 6500 routers.
In documentation accessible on Cisco web site it can be seen that all normal traffic forwarding is handled in hardware.CEF is in hardware and even it is downloaded to linerads if there is DFC available on them.So theoraticaly if Cisco 7609 is full packed with Gigabitethernet modules, TenGigabitEthernet modules etc (i.e. one supervisor 720 BXL and 8 linecards all up and runnig) it would handle it in hardware and it woudn't be any degradation in performance,As I understood Its matrix is not oversubscribed.

Question is in what situations I can experience performace degreadation for this series of routers (regaridng traffic forwarding)? sholudn't it work even if all its interfaces are 100% utilized?

And regarding its CPU (on MSFC) if it is used i.e  for BGP internet routing isn't it more question of memory capacity? I know that controll or dynamic routing protocols like BGP are handled by CPU (not in hardware). Regarding BGP the most significan't factor is how big routing table is
(and in Internet it is more all less 200.000 routes) due to scanner process. Is it also important how much BGP session (BGP peers)
router handles? As I understood it is not so much intensive as BGP scanner.

Thanks in advance,
A.

[Jon Marshall]

Antonio_1 wrote:
Hello,
I have a question regarding performances of Cisco 7600 or Cisco 6500 routers.
In documentation accessible on Cisco web site it can be seen that all normal traffic forwarding is handled in hardware.CEF is in hardware and even it is downloaded to linerads if there is DFC available on them.So theoraticaly if Cisco 7609 is full packed with Gigabitethernet modules, TenGigabitEthernet modules etc (i.e. one supervisor 720 BXL and 8 linecards all up and runnig) it would handle it in hardware and it woudn't be any degradation in performance,As I understood Its matrix is not oversubscribed.
Question is in what situations I can experience performace degreadation for this series of routers (regaridng traffic forwarding)? sholudn't it work even if all its interfaces are 100% utilized?

And regarding its CPU (on MSFC) if it is used i.e  for BGP internet routing isn't it more question of memory capacity? I know that controll or dynamic routing protocols like BGP are handled by CPU (not in hardware). Regarding BGP the most significan't factor is how big routing table is 
(and in Internet it is more all less 200.000 routes) due to scanner process. Is it also important how much BGP session (BGP peers) 
router handles? As I understood it is not so much intensive as BGP scanner.
Thanks in advance,
A.

A

You need to look at the connection between the module and the switch fabric to see if you can get oversubscription. For example if you have a WS-X6748-GE-TX module in one of the slots, this module has a 40Gbps connection to the switch fabric. But it can support 48 ports running at 1Gbps so if all 48 interfaces were 100% utilised then you would get oversubscription. If only 40 interfaces had connections then you wouldn't.

Similarly the 8 port 10Gbps module has a 40Gbps connection to the switch fabric so obviously running 8 ports at 10Gbps would produce an oversubscription of 2:1.

So most of the cards do have some level of oversubscription and this is where you could experience performance degradation. I say could because it is not very likely for example that you would see all 48 ports on a WS-6748-GE-TX running at full capacity. You need to always look at connection the module has to the switch fabric compared with how many ports and what speed it can support.

For BGP routing ie. full internet tables, yes the memory is the key thing rather than the CPU usage.

Jon

[Antonio_1_2]

Thanks Jon,

But in all cases it would be handled by hardware (it wouldn't go to MSFC CPU)?

Is the case with oversubscribtion that DFC jumps in (so that traffic doen't need to leave linecard if traffic is local on card?

What is the purpose of DFC if generally all traffic is in hardware anyway? (It seems I don't get any benefit with or withouth DFCs)

And Regarding BGP peers, how much is significant for CPU if I have 10 or 100 BGP peers? (it is only keepalives)

Thanks

[Jon Marshall]

Antonio_1 wrote:
Thanks Jon,
But in all cases it would be handled by hardware (it wouldn't go to MSFC CPU)?
Is the case with oversubscribtion that DFC jumps in (so that traffic doen't need to leave linecard if traffic is local on card?
What is the purpose of DFC if generally all traffic is in hardware anyway? (It seems I don't get any benefit with or withouth DFCs)
And Regarding BGP peers, how much is significant for CPU if I have 10 or 100 BGP peers? (it is only keepalives)
Thanks

Generally speaking yes it would be handled by hardware. There are exceptions to this where packets are sent to the MSFC but they are exceptions and not the norm.

DFC and oversubscription are 2 different things. A module has a fixed connection to the switch fabric whether or not DFC is enabled. So from previous post WS-X6748-GE-TX can be DFC enabled. But whether it is or it isn't the module still only has 40Gbps connection to the switch fabric.

You get a huge increase in performance with DFC on your line cards. Have a look at this link rather than me write them all out -

http://www.cisco.com/en/US/products/hw/switches/ps708/products_qanda_item09186a00809a7673.shtml#qa4

Key point to note is that with no DFC the overall forwarding capacity of the switch is 30Mpps (Million packets per second). With all DFC enabled cards you can get up to 400Mpps. So there is definitely a benefit.

BGP peer, can't really say. I have never run more than one peer on a 6500. Obviously the more peers the more memory and CPU in use but i can't give you any definitive statistcis.

Jon

[Antonio_1_2]

Please just one more question Jon.

What would happen if, for instance, traffic reach 30Mpps which is forwarding capacity of the switch (and there is no DFCs)?

Will the switch start to drop packets, or the traffic will not be forwarded in hardware and instead will be handled by MSFC CPU?

regards,
A

[Jon Marshall · Accepted solution]

Antonio

Port buffers etc. on the linecards are hardware based so as far as i know packets will be queued and then potentially dropped if the forwarding capacity is reached. Again this is not directly related to DFC/CFC.

Jon

[Giuseppe Larosa]

Hello Antonio,

the DFC hosts a complete copy of the CEF  table if possible in order to move to distributed CEF forwarding.

For a device used for BGP it is very important to choice the right PFC and DFC: only PFC 3BXL or PFC 3CXL are suitable for handling a full internet table.

A full internet table is now around 308,000 -310,000 routes.

Also DFCs have to be of XL series: for example we had a failure on a WS 6708 in a C7600 chassis with SUP 3BXL the replacement linecard had the wrong DFC  DFC3C instead of DFC 3CXL the result was that not all IP prefixes could fit in the DFC and the system was doing process switching for some prefixes with cpu usage at 100%!

We had to shut all the ports and to use only the companion node.

>> And Regarding BGP peers, how much is significant for CPU if I have 10 or  100 BGP peers? (it is only keepalives)

Not only keepalives, there are also updates. What really counts is the number of update-groups: each update-group is made by those peers that share the same outbound routing policy (that receive the same updates over time).

The  router prepares the updates once and send them to all members of an update-group over the corresponding TCP sessions.

Update-groups have been added for BGP improvement, previously only way to create an update-group was to configure peer-groups.

Peer-groups are still useful to improve configuration readibility but don't provide that performance gain over not using them.

So cpu power has still some effects in the time it takes to load the BGP sessions.

To be noted that RSP 720 processor for C7600 has a newer and more powerful MSFC the MSFC4 so this can be the right supervisor for this application.

Hope to help

Giuseppe

[Antonio_1_2]

Thanks Giuseppe.