On Sun, Jun 21, 2009 at 11:05:55PM +0200, Peter Rathlev wrote: > On Thu, 2009-06-18 at 14:34 -0400, Rodney Dunn wrote: > > Curious..I don't know that platform forwarding architecture. > > > > But what does 'sh int stat' give you? > > We've begun running some production traffic through the box now and it > doesn't seem to be overly loaded by more flows, but maybe it really has > to process switch "first packets". I thought the TCAM thingy was able to > do a hashed lookup based on source and destination IP and thus no need > to "install" flows. > > Interface stats for the two relevant interfaces (policy map attached to > Vlan2176, policy routed traffic exits via Vlan507, non policy routed > exist via next hop on same interface as it arrived): > > Vlan507 > Switching path Pkts In Chars In Pkts Out Chars Out > Processor 73750 4426830 314407 20751714 > Route cache 1 90 0 0 > Total 73751 4426920 314407 20751714 > Vlan2176 > Switching path Pkts In Chars In Pkts Out Chars Out > Processor 210884 13340863 323420 21776624 > Route cache 23 5081 24 5267 > Total 210907 13345944 323444 21781891
I thought the newew sup/rp's would show a distributed cache line that would show the hw forwarded counters. > > And "show interfaces accounting": > > Vlan507 XXX Internet > Protocol Pkts In Chars In Pkts Out Chars Out > IP 41 3546 315061 19534782 > ARP 73840 4431144 74 4440 > Vlan2176 YYY Internet > Protocol Pkts In Chars In Pkts Out Chars Out > IP 211382 13383337 324400 20584065 > ARP 571 34260 131 7860 > > The processor switched "Pkts In" from Vlan507 are mostly ARP. The unit > has been live for a couple of days with light production traffic. > > And the route-map: > > route-map Inet_PBR, permit, sequence 10 > Match clauses: > ip address (access-lists): RMIT_XXX_sources > Set clauses: > ip next-hop A.B.C.D > Policy routing matches: 0 packets, 0 bytes > route-map Inet_PBR, permit, sequence 20 > Match clauses: > ip address (access-lists): RMIT_YYY_sources > Set clauses: > ip next-hop A.B.C.E > Policy routing matches: 3 packets, 216 bytes > > > > Also, sh ip traffic a couple times once you start the traffic. > > The "show ip traffic" seems only to show traffic received. Should it > also show policy routed traffic? No. I was looking to see if there were a bunch of ICMP generated frames. > > IP statistics: > Rcvd: 211589 total, 211565 local destination > 0 format errors, 0 checksum errors, 24 bad hop count > 0 unknown protocol, 0 not a gateway > 0 security failures, 0 bad options, 0 with options > Opts: 0 end, 0 nop, 0 basic security, 0 loose source route > 0 timestamp, 0 extended security, 0 record route > 0 stream ID, 0 strict source route, 0 alert, 0 cipso, 0 ump > 0 other > Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble > 0 fragmented, 0 couldn't fragment > Bcast: 0 received, 0 sent > Mcast: 201383 received, 630608 sent > Sent: 639832 generated, 255251197 forwarded > Drop: 0 encapsulation failed, 0 unresolved, 0 no adjacency > 0 no route, 0 unicast RPF, 0 forced drop > 0 options denied, 0 source IP address zero > > ICMP statistics: > Rcvd: 0 format errors, 0 checksum errors, 1 redirects, 0 unreachable > 144 echo, 24 echo reply, 0 mask requests, 0 mask replies, 0 > quench > 0 parameter, 0 timestamp, 0 info request, 0 other > 0 irdp solicitations, 0 irdp advertisements > Sent: 0 redirects, 108 unreachable, 25 echo, 144 echo reply > 0 mask requests, 0 mask replies, 0 quench, 0 timestamp > 0 info reply, 386 time exceeded, 0 parameter problem > 0 irdp solicitations, 0 irdp advertisements > > TCP statistics: > Rcvd: 6307 total, 26 checksum errors, 30 no port > Sent: 4655 total > > UDP statistics: > Rcvd: 205062 total, 0 checksum errors, 117 no port > Sent: 634518 total, 0 forwarded broadcasts > > (... snipped irrelevant protocol counters, all zero ...) > > ARP statistics: > Rcvd: 74386 requests, 60 replies, 0 reverse, 0 other > Sent: 68 requests, 152 replies (60 proxy), 0 reverse > Drop due to input queue full: 0 > > > The number of ARP requests is relatively high (considering it has been > live for about a day connected a /20 prefix. This might explain the non > interrupt CPU load (~5-10% most of the time) and is due to a > semi-retarded legacy setup on one of the legs. That's actually the > reason we needed the PBR: transitioning away from that. > > (And why does it say "(60 proxy)" in sent ARP statistics? We have "no ip > proxy-arp" on all interfaces of course.) Don't know. Rodney > > Regards, > Peter > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
