[c-nsp] Redirects / hair-pinning traffic vs. performance

[Rodney Dunn]

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
>