6 Replies Latest reply on Nov 17, 2009 1:05 PM by Andy McBride

    capturing netflow data

      Hello,

      i have 4 cisco 2620 routers which i just upgraded to ios c2600-is-mz.123026.

      i was wondering if someone can help me with the correct way to configure netflow data on my router.

      here is my current config.  all my routers have the same basic config aside from ip address and hostname changes

      AUGUSTA#sh run
      Building configuration...

      Current configuration : 3512 bytes
      !
      version 12.3
      service timestamps debug uptime
      service timestamps log uptime
      service password-encryption
      !
      hostname AUGUSTA
      !
      boot-start-marker
      boot-end-marker
      !
      logging buffered 4096 debugging
      enable secret 5
      !
      clock timezone EDT -5
      clock summer-time EDT recurring
      no aaa new-model
      ip subnet-zero
      ip cef
      !
      !
      no ip domain lookup
      !
      isdn switch-type basic-dms100
      !
      !
      !
      !
      !
      !
      !
      !
      !
      !
      !
      !
      !
      ip tcp synwait-time 5
      !
      class-map match-all Voice
        match ip dscp ef
      !
      !
      policy-map Policy1
        class Voice
         priority 500
        class class-default
         fair-queue
      !
      buffers middle permanent 200
      buffers middle max-free 300
      buffers middle min-free 100
      bridge crb
      !
      !
      !
      interface Loopback1
       description LoopBack for Augusta
       ip address 10.254.12.1 255.255.255.224
      !
      interface FastEthernet0/0
       description AUGUSTA Local Area Network
       no ip address
       ip route-cache flow
       speed 100
       full-duplex
      !
      interface FastEthernet0/0.1
       description Data
       encapsulation dot1Q 1
       ip address 10.42.32.1 255.255.240.0
       bridge-group 1
      !
      interface FastEthernet0/0.100
       description Voice
       encapsulation dot1Q 100
       ip address 192.168.5.1 255.255.255.0
      !
      interface FastEthernet0/0.999
       description Just to match Native
       encapsulation dot1Q 999 native
      !
      interface Serial0/0
       description T1 to RANDOLPH
       bandwidth 1536
       ip address 10.252.4.250 255.255.255.252
       encapsulation ppp
       ip route-cache flow
       no ip mroute-cache
       service-module t1 timeslots 1-24
       bridge-group 1
       service-policy output Policy1
      !
      interface BRI0/0
       description Backup ISDN to RANDOLPH
       no ip address
       encapsulation ppp
       dialer hold-queue 10
       dialer load-threshold 1 outbound
       isdn switch-type basic-dms100
      !
      router eigrp 1
       redistribute static metric 1000 1500 100 100 1500
       passive-interface Loopback1
       offset-list 28 in 15000000 FastEthernet0/0.1
       network 10.0.0.0
       network 192.168.5.0
       no auto-summary
      !
      no ip http server
      ip flow-export source Serial0/0
      ip flow-export destination 10.43.144.95 2055
      ip flow-export destination 10.43.144.95 2056
      ip classless
      ip route 0.0.0.0 0.0.0.0 10.42.32.85 201
      ip route 10.33.144.0 255.255.240.0 10.42.32.85 150
      ip route 10.40.32.0 255.255.240.0 10.42.32.85 150
      ip route 10.43.80.0 255.255.240.0 10.42.32.85 150
      ip route 10.43.144.0 255.255.240.0 10.42.32.85 150
      ip route 192.168.1.0 255.255.255.0 10.42.32.85 150
      ip route 192.168.2.0 255.255.255.0 10.42.32.85 150
      ip route 192.168.4.0 255.255.255.0 10.42.32.85 150
      ip route 192.168.6.0 255.255.255.0 10.42.32.85 150
      ip route 192.168.101.0 255.255.255.0 10.42.32.85
      !
      !
      logging history debugging
      logging trap debugging
      access-list 28 permit 10.28.0.0 0.0.255.255
      access-list 28 permit 10.225.0.0 0.0.255.255
      access-list 28 permit 10.27.0.0 0.0.255.255
      access-list 28 permit 10.227.0.0 0.0.255.255
      !
      snmp-server community Nagio5 RW
      snmp-server community cisco RW
      snmp-server chassis-id AUGUSTA
      !        
      bridge 1 protocol ieee
      bridge 1 route ip
      !
      !
      !
      !
      dial-peer cor custom
      !
      !
      !
      banner login ^C

      *************************************************************
      *      Unauthorized Access is Prohibited                    *
      *      Access is restricted to authorized Personel ONLY     *
      *      Unauthorized access is Punishable by LAW             *
      *************************************************************
      ^C
      !
      line con 0
       exec-timeout 5 0
       password 7 
       logging synchronous
       login
      line aux 0
       password 7 
       login
      line vty 0 4
       exec-timeout 240 0
       password 7 
       logging synchronous level all
       login
       terminal-type moni
      !
      !
      end

      AUGUSTA#

       

      i am looking to capture ingress and egress (if possible) or traffic going and coming from my serial and voic and data lan interfaces.

      Thanks in advance

        • Re: capturing netflow data
          dhardy

          I've found there's a couple ways to do that. This is the way I decided on.

          You will want to turn on ip route-cache flow on your physical WAN and Inside interfaces. That will cover all ingress and egress traffic for the whole interface (including all subinterfaces).

          ip flow-export source loopback #

          ip flow-export version 5

          ip flow-cache timeout active 1

          ip flow-export destination #.#.#.# port

          snmp-server ifindex persist

          • Re: capturing netflow data
            Andy McBride

            Make sure you config has

            (config) # ip flow-export version 5|9 (Choose v5 or v9)

            (config) # ip flow-export destination xxx.xxx.xxx.xxx 2055

            (no need to increment port number as in your config unless you have two collectors at the same IP destination address

            and for each interface

            (config-if) #ip flow ingress

            (config-if) #ip flow egress

              • Re: capturing netflow data
                dhardy

                I've found it's better to use ip flow ingress on individual interfaces only when you don't want to see all the traffic going in or out of the interface. That is, you're only interested in specific subinterfaces. If you want to see all data in or out on an interface for all subinterface I suggest using ip route-cache flow on the physical interface.

                Also, I think ip flow egress only works if you use ip flow-export version 9.

                  • Re: capturing netflow data
                    Andy McBride

                    ip route cache flow is only valid on the main interface and was superseded by the ip flow ingress|egress commands to allow v5 directional exports and sub interface specific exports. v9 marks the export PDUs with a direction indicator, v5 does not but it still exports ingress and egress.

                      • Re: capturing netflow data
                        dhardy

                        Agreed. Let me just clear up what I'm trying to say.

                        ip route-cache flow = ip flow ingress

                        the ip route-cache flow command is actually just remapped to the ip flow ingress command... only you cant use ip route-cache flow on the subinterfaces, but you can just use ip flow ingress to choose which subinterfaces you want. I just used that instead of applying ip flow ingress to all my subinterfaces because I wanted to include them all. So applying ip route-cache flow to the physical interface is the same thing as putting ip flow ingress on all my subinterfaces.

                        I've also found in the past that applying ip flow ingress and ip flow egress to the same interface can cause duplicate data to show up. You should really just configure egress on your outside exit interface and ingress on all other interfaces.

                        It's been awhile since I've messed with it though.

                          • Re: capturing netflow data
                            Andy McBride

                            You are correct that ip route-cache flow is a much more simple implementation. Some folks use egress on a single router connected to several other routers to keep the config in one place. I like your method of egress on the exit and ingress on the others. Makes sense and keeps it simple. There is a lot to be said for not overdeploying exporters.