Thanks for all the replies. I definitely feel better reading that as the traffic patterns increase the "CPU should't" necessarily grow at the same rate. Here is the interface config for the WAN link
! interface GigabitEthernet0/3 description WAN LINK TO ASIA mtu 2000 ip address 10.12.188.102 255.255.255.252 ip mtu 1500 ip ospf network point-to-point ip ospf 1 area 1 load-interval 30 speed auto duplex auto negotiation auto mpls ip service-policy output SHAPE194MBPS ! ** yes I have tried removing the shaping and didn't notice a big difference in CPU utilization 2-3%. Here is the Port-Channel facing the switch stack: ! interface Port-channel10 description PortChannel Trunk To Core Switch mtu 2000 no ip address no negotiation auto ! ! interface Port-channel10.50 description L3 To Core Switch (VLAN50) encapsulation dot1Q 50 ip address 10.12.188.53 255.255.255.252 ip mtu 1500 ip ospf network point-to-point ip ospf 1 area 0 ! I did notice something very strange with another cluster of routers last night when I was commissioning them. Same setup, port-channel trunks to a core switch with sub-interfaces running over them. I was seeing some issues with bringing up an 3-way OSPF broadcast w/MPLS LDP. The OSPF would come up fine BUT, the LDP wouldn't come up for all 3 peers. Only 2 of them. It wasn't until I shut one of the physical interfaces on all the routers in the channel-group that it all started to work. I proceeded to un-shut the physicals and it continued to work. This was not a once off incident. I had the exact same issue 30 minutes later on another site. Which leads me to think that port-channels may behave strangely when being brought up initially on this instance. I'm going to try to bounce these boxes off peak and report back. Thanks for the assistance. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
