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

[Peter Rathlev]

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

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?

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.)

Regards,
Peter