cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
865
Views
5
Helpful
1
Replies

Policy Based Routing missed packets

tamimkushjar
Level 1
Level 1

Hi Guys,

This is my first post and I hope it's posted in the right directory.

I have a problem with Policy Based Routing on my router.

It's a configuration which is working for a very long time.

Recently I have add some additional rules to make use of the policy based routing.

This seems to work since I see the ACL counters increase, however I also have noticed that not all packets are being picked!

Which just goes over de standard WAN interface!

                                            WAN ----------MPLS-------------

PBR LAN port Remote router<

                                            PBR out---------ISP TUNNEL------

################PBR configuration##############

interface FastEthernet0/0

description LAN interface

ip address 172.26.32.1 255.255.240.0

ip access-group VPNLANin in

no ip proxy-arp

ip policy route-map traffic-offload

!

!

route-map traffic-offload permit 20

description Offloadingv2-via-Nijmegen

match ip address traffic-offload-acl

set ip next-hop recursive 172.25.100.209

!

Extended IP access list traffic-offload-acl

283 permit tcp any gt 0 host 172.25.16.11 gt 0 (251864 matches)  <==Notice the matches are increasing for PBR

285 permit ip any host 172.25.16.11 (817 matches)

!

!

################################################

#############WAN Interface test####################

interface Serial0/0/0:0

description WAN INTERFACE

bandwidth 1024

ip address x.x.x.x 255.255.255.252

ip access-group VPNWANin in

ip access-group TEST out

ip flow ingress

ip flow egress

!

!

!

Extended IP access list TEST

    10 permit tcp any gt 0 host 172.25.16.11 gt 0 log (59807 matches)  <==Still packets which don't seem to be matched in the ACL above!

    20 permit ip any any (414136 matches)

Prove of packets being sent towards de default WAN link

Jul  5 12:06:17 UTC: %SEC-6-IPACCESSLOGRL: access-list logging rate-limited or missed 265 packets

Jul  5 12:06:20 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.32.19(52860) -> 172.25.16.11(111), 1 packet

Jul  5 12:06:22 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.32.200(443) -> 172.25.16.11(52431), 1 packet

Jul  5 12:06:24 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.32.19(52096) -> 172.25.16.11(6504), 1 packet

Jul  5 12:06:26 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.32.19(52882) -> 172.25.16.11(111), 1 packet

Jul  5 12:06:28 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.32.19(52900) -> 172.25.16.11(111), 1 packet

Jul  5 12:06:47 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.32.19(52953) -> 172.25.16.11(60217), 1 packet

Jul  5 12:06:49 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.32.10(6050) -> 172.25.16.11(52445), 1 packet

Jul  5 12:06:50 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.32.10(62031) -> 172.25.16.11(6504), 1 packet

Jul  5 12:06:51 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.32.19(53029) -> 172.25.16.11(111), 1 packet

Jul  5 12:06:53 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.32.200(443) -> 172.25.16.11(52431), 1 packet

Jul  5 12:06:56 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.32.19(59866) -> 172.25.16.11(6502), 1 packet

Jul  5 12:06:57 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.32.19(53055) -> 172.25.16.11(111), 1 packet

Jul  5 12:07:00 UTC: %SEC-6-IPACCESSLOGP: list TEST permitted tcp 172.26.35.200(2463) -> 172.25.16.11(52518), 1 packet

########################################################################

Personally I am think maybe some buffer is overloaded however I don't see any counters increased!

Also de CPU is at a acceptable level!

FastEthernet0/0 is up, line protocol is up

  Hardware is Gt96k FE, address is 0022.559b.de42 (bia 0022.559b.de42)

  Description: LAN interface

  Internet address is 172.26.32.1/20

  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 100Mb/s, 100BaseTX/FX

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input 00:00:00, output 00:00:00, output hang never

  Last clearing of "show interface" counters 01:16:50

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  30 second input rate 363000 bits/sec, 171 packets/sec

  30 second output rate 410000 bits/sec, 155 packets/sec

     635605 packets input, 219515361 bytes

     Received 20422 broadcasts, 0 runts, 0 giants, 0 throttles

     214 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog

     0 input packets with dribble condition detected

     573762 packets output, 299583341 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 babbles, 0 late collision, 0 deferred

     0 lost carrier, 0 no carrier

     0 output buffer failures, 0 output buffers swapped out

li01-lgqy# sh route-map traffic-offload

route-map traffic-offload, permit, sequence 20

  Match clauses:

    ip address (access-lists): traffic-offload-acl

  Set clauses:

    ip next-hop recursive 172.25.100.209

  Policy routing matches: 350236 packets, 139030057 bytes

route-map traffic-offload, permit, sequence 30

  Match clauses:

    ip address (access-lists): traffic-offload-acl

  Set clauses:

    ip next-hop recursive 172.25.100.217

  Policy routing matches: 0 packets, 0 bytes

li01-lgqy   12:10:42 PM Friday Jul 5 2013 UTC

    8222222132111111111222255222211111    11111322328422221 1   1  1 1122222

    697785175598767979973850844309803289895213514413404351884987288593920584

100

90 *

80 *                                               *

70 *                                               *

60 *                       *                       *

50 *                      **                       *

40 *       *              **                       **

30 ******  **         * ****                  *  * **  *                **

20 *******************************       *   *************        *  ******

10 ######***********#############*************###########*************#####

   0....5....1....1....2....2....3....3....4....4....5....5....6....6....7..

             0    5    0    5    0    5    0    5    0    5    0    5    0

                   CPU% per hour (last 72 hours)

                  * = maximum CPU%   # = average CPU%

So as you can see I don't see any abnormalities maybe someone have any suggestions or ideas?

1 Reply 1

tamimkushjar
Level 1
Level 1

The problem is solved! The reason was that the recursive route was not stable!

With implementation of proper route-maps to block the recursive routes.

Which was being resent back over the the MPLS cloud.