[j-nsp] M20 SSB/IP2 CPU usage on IPv6 forwarding

Kevin Day toasty at dragondata.com
Fri Feb 22 01:13:28 EST 2008


Hey, J-NSPers!

I'm nearly ready to launch what's probably going to be the largest  
public use of IPv6 so far[*]. The end result is that we're going to be  
shoving many gigabits of v6 traffic through our M20. In preparation  
for the real deployment, I've been doing some internal testing and  
simulations to make sure all of my infrastructure can handle this.

When pushing about 4gbps of v6 traffic through our router (between  
several directly connected hosts, nothing targeting the RE or router  
interfaces), the SSB starts using 100% CPU:

SSB status:
Slot 0 information:
   State                                 Master
   Temperature                        40 degrees C / 104 degrees F
   CPU utilization                     99 percent
   Interrupt utilization               0 percent


Doing a "start shell pfe network ssb" took about 30 seconds for it to  
actually log me in. I typed "show threads" to see if I could figure  
out what it was doing. It took about a minute for that command to even  
echo back to me. After another few minutes of waiting for a reply it  
dumped me back to the RE without responding.

The only log messages I got were some:

ssb CM(0): received message error, subtype=11, op=169

and a few:

pfe_send_failed(index 2, type 3), err=32

And finally when I stopped everything, I got this before it all came  
back up:

rdp keepalive expired, connection dropped - src 1:1020 dest 19:34816
pfe_listener_disconnect: conn dropped: listener idx=3, tnpaddr=0x13,  
reason: reconnect timeout


Running the exact same test over v4 caused no problems at all. Does  
anyone know what gets dumped to the SSB CPU while forwarding v6  
packets? Is there any kind of document that shows what gets done on  
the CPU on the v6 side? We also had an offer that we previously turned  
down to borrow a M160 from someone - is there any reason to believe it  
would be any better at v6 forwarding?

Because of the affect this had on our production v4 network I wasn't  
able to experiment much with trying to narrow down the cause, so I  
apologize for the vagueness of this post. :) I'll try to repeat this  
if I have a better idea of what to be looking at while it's going wrong.

-- Kevin


[*] http://www.ipv6experiment.com if you're curious



More information about the juniper-nsp mailing list