Netflow with tunnel interfaces

Hi I have a customer who is using tunnel interfaces with IPSEC on their WAN. They are collecting Netflow stats and exporting them to a server.Under the tunnel interface I have specified the bandwidth to be 1000.When I did not specify the bandwidth the tunnel speed came up on the management software as being 9kb. This was obviously not a true reflection when observing the data. The far end remote office is terminating via dsl and my question is should I specify the bandwidth under the tunnel interface to be closer to the dsl connection they have there ie 512k? There are many other tunnels coming from the main site and I have not configured Netflow on the this particular remote end.

Hi Justin,
If we would define bandwidth on tunnel interface it will manipulate routing decisions also and tunnel recursiuon issue could also occur where tunnel would see that the best way to reach teh destination is via tunnel itself. Beside taht the actual bandwidth used by the tunnel is based on the physical interface associated with it.

Similar Messages

  • Disappearing tunnel keepalives with tunnel interface in vrf

    Dear all
    I have an annoying problem with a gre tunnel using keepalives and the tunnel interface on the PE residing in a vrf.
    The background for my setup is an ethernet WAN link to our customer where the interface doesn't go down when the link fails.
    Therefore I want to use an gre tunnel with keepalive in order to use static routes.
    The tunnel setup is as follows:
    1. PE, 6509, Sup720, IOS 12.2(18)SXF7
    interface FastEthernet8/13
    ip address xx.yy.zz.241 255.255.255.252
    speed 10
    duplex full
    no mop enabled
    interface Tunnel813
    ip vrf forwarding CUSTOMER
    ip address 10.0.0.101 255.255.255.252
    keepalive 5 3
    tunnel source xx.yy.zz.241
    tunnel destination xx.yy.zz.242
    end
    2. CE, 1803, IOS 12.4(15)T8
    interface FastEthernet0
    bandwidth 5000
    ip address xx.yy.zz.242 255.255.255.252
    speed 10
    full-duplex
    interface Tunnel0
    ip address 10.0.0.102 255.255.255.252
    keepalive 5 3
    tunnel source xx.yy.zz.242
    tunnel destination xx.yy.zz.241
    The problem is PE sends and receives keepalives and brings up the tunnel. CE on the other hand sends but doesn't receive keepalives.
    As far as I have learned from former discussions the problem comes from tunnel and physical interface belonging to different routing instances. If I put the tunnel interface on PE into the global routing instance all the keepalives reach their destinations as expected.
    I read about a solution involving "tunnel vrf" on th etunnel configuration. This command is not present in my IOS version but AFAIK it is only necessary for having the underlying physical interface in a vrf as well.
    Furthermore I read about "mls mpls tunnel-recir" but I am not sure whether this might solve the issue here. And equally important: Can I safely turn on this feature on a running system with quite a lot of vrf customers without any trouble?
    Any hint and/or advise is greatly appreciated here.
    Thanks a lot in advance,
    Grischa

    Wow, this is old, but...
    While they may or may not be officially supported, GRE tunnels do work with vrf's if you both put the tunnel interface in the VRF AND the physical interface the tunnel runs over, AND use the tunnel vrf command.  Then everything is in the same routing table and it works.  For example:
    PE:
    vrf definition vrf1
    rd 1:1
    address-family ipv4
      route-target export 1:1
      route-target import 1:1
    exit-address-family
    interface Ethernet0/0
    vrf forwarding vrf1
    ip address 192.168.1.1 255.255.255.0
    interface Tunnel1
    vrf forwarding vrf1
    ip address 1.1.1.1 255.255.255.252
    keepalive 1 3
    tunnel source Ethernet0/0
    tunnel destination 192.168.1.2
    tunnel vrf vrf1
    router bgp 12345
    bgp log-neighbor-changes
    address-family vpnv4
    ! Provider stuff - i.e., route reflector for MPLS network
    exit-address-family
    address-family ipv4 vrf vrf1
      neighbor 1.1.1.2 remote-as 64512
      neighbor 1.1.1.2 activate
      neighbor 1.1.1.2 default-originate
    exit-address-family
    CE:
    interface Ethernet0/0
    ip address 192.168.1.2 255.255.255.0
    interface Tunnel1
    ip address 1.1.1.2 255.255.255.252
    keepalive 1 3
    tunnel source Ethernet0/0
    tunnel destination 192.168.1.1
    router bgp 64512
    bgp log-neighbor-changes
    ! network statements perhaps
    ! redistribute static perhaps
    neighbor 1.1.1.1 remote-as 12345
    neighbor 1.1.1.1 update-source Tunnel1
    neighbor 1.1.1.1 soft-reconfiguration inbound
    Of course you don't need to run BGP, but you can.

  • DLSW and Tunnel Interfaces problem

    We have a pair of routers with tunnel interfaces and DLSW between them.
    Some times the tunnel interface goes down thus loosing service trough DLSW.
    Is there any problem reported between DLSW and this kind of tunel interfaces ?

    Hi,
    i assume you are using dlsw tcp peers.
    In general dlsw does not know over what infrastucture the connection really runs. Dlsw gives data to tcp and tcp is responsible for doing the actual transmission.
    I dont know of any problems with dlsw and tunnel interfaces in general.
    Some more information might help to understand the problem.
    What type of tunnel are you using? GRE?
    What version of ios are you running?
    Do you use additional encapsulation overhead like ipsec ect?
    Does tcp on this router use path mtu discovery?
    thanks...
    Matthias

  • Netflow command and interface

    Hi,
    I have a few simple questions regarding netflow. Would anyone please clarify them for me?
    1. I usually configured netflow with "ip route-cache flow" command. Anyway, I have seen articles mentioning "ip flow ingress" and "ip flow egress" commands. What is different exactly i.e. ip route-cache flow and ip flow ingress|egress? Which one should be used?
    2. I understand netflow needs to be configured on every interface to export completely netflow data. Is it correct?
    3. If there are 2 physical and 2 logical i.e. tunnel interfaces, how many/which interfaces should netflow be configured? Are only physical interfaces enough?
    Please let me know if I misunderstand anything.
    Thank you very much,
    Nitass

    AFAIK:
    1. "ip route-cache flow" is deprecated starting in 12.2(18)SXD. See this URL for other IOS trains: http://www.cisco.com/en/US/docs/ios/netflow/command/reference/nf_01.html#wp1049320
    2. It's generally correct, due to the unidirectional nature of NetFlow records. Otherwise, you run the risks such as only seeing one direction of a given "conversation".
    3. My understanding was NetFlow cache could only be enabled on layer-3 interfaces. However, on the catalyst 6000s (and sup720?), you can get layer-2 bridged traffic between hosts in the same VLAN, using the following config:
    ip flow ingress layer2-switched vlan
    ip flow export layer2-switched vlan
    Then, there's this recent thread that makes it sound promising that layer-2 ports could become NetFlow-enabled, though it's not clear (to me) how it works out in practice:
    https://supportforums.cisco.com/message/678612#678612
    So YMMV. The best bet is to actually attempt configuring it. Odds are the physical interfaces won't accept the "ip route-cache flow" or "ip flow ingress/egress" config.

  • NetFlow on All Interfaces

    Hi All,
    We are using ManageEngine NetFlow Analyzer to monitor our network traffic.
    We have a few VLAN interfaces on the switch where we have enabled flow-export ingress and egress. We can see traffic that is passing between the VLANs on which flow-export has been configured. However, we have on interface that is connected to remote locations. We have not enabled flow-export on this interface. The idea was that, we have enabled ingress and egress flow-export, and the remote locations connect to VLANs where flow-export is already enabled, we must get all traffic from there. But we cannot see traffic from the remote locations, but we can see traffic from inside network to remote locations.
    After checking ManageEngine documentation, I see that we have to enable netflow on all interfaces to get accurate report. Can anyone let me know why this is required. We already have ingress and egress flow-export, and we must be getting all traffic. Please suggest.
    Thanks in advance,
    Faiz

    Hello Faiz,
    As you probably know, NetFlow by default is only collected ingress.  The ingress flows collected on all interfaces are used to display the outbound traffic on a selected interface.  I don't know about ManageEngine but, in some NetFlow solutions, interfaces without NetFlow/IPFIX enabled will not be displayed regardless of whethor or not flows are going out of it.
    Regarding ingress/egress being enabled on the same interface.  If you are using flexible NetFlow to configure the export, make sure the "flow direction" is exported in the template. The commands to export both look like this:
    ip flow monitor andrew-mon input
    ip flow monitor andrew-mon output
    Here is a good article on enabling ingress and egress NetFlow. Realize that just because you export both ingress and egress on a single interface and you export the direction, this doesn't mean the NetFlow solution will report on the data with a behavior that you would expect. 
    Ingress and egress flows are exported at the same time with only one difference "flow direction".  For this reason, this element must be included in the template to ensure that utilization isn't overstated in the flow report.  Again, this of course depends on your reporting solution.  
    Many vendors can't deal with a mixture of ingress and egress flows being enabled in a seemingly random fashion on the same device.  In other words, they expect all ingress or all egress.  Only a few vendors can handle a hybrid approach.
    I hope this helps. 
    Jake

  • 'no ip route-cache' on Tunnel interfaces

    Hi,
    A quick and hopefully simple question. Is there any reason why 'no ip route-cache' and 'no ip mroute-cache' should be configured on Tunnel interfaces?
    Generally, when should 'no ip route-cache' be configured on an interface?
    Many thanks,
    Andy

    Andy, no easy question, and prety much send some of us back to basics.. one have to take a deeper look at this command to barely get a good picture. See first link thread , good discussion on your question.. generaly no ip- route-catch improves performance for router forwarding processing desitions.
    http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=WAN%2C%20Routing%20and%20Switching&topicID=.ee71a06&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cbfa166
    You can find more details on three types of switching methods such as ( fast switching by ip route catch command ), I believe it helps understand better the commands.
    http://www.cisco.com/en/US/tech/tk827/tk831/technologies_white_paper09186a00800a62d9.shtml
    Another instance where you would have IP route catch enable on an interface would be for the use of netflow, IP route-cacth command on an interface is requirement for implementing netflow .
    Rgds
    -Jorge

  • Where did these tunnel interfaces come from?!?

    Hello,
    just wondering why one of our routers creates tunnel interfaces dynamically.
    I was setting up a GRE tunnel to transport multicast traffic over network. After I was done, I found two extra tunnel interfaces with command show ip interfaces brief and those extra interfaces uses my original tunnel interface as their IP addresses. There is no any configuration regarding to these extra interfaces in running config. How did this happen? Any explanations? Is it relating somehow to my multicast solution?
    If I got two dynamically created tunnels does that mean that I have at least two concurrent multicast groups on my router in active state?
    Sorry for dummy questions but I have almost zero experience what comes for multicast and last time I studied it in school about 8 year ago...
    -JJ

    Hi,
    These are created dynamically, one to encapsulate multicast packets and the other one to decapsulate. You can see them with the command < show ip pim tunnel > . You can find the description and purpose of these tunnels here:
    http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti/command/imc-cr-book/imc_s1.html#wp9533023710
    Hope this helps,
    Jose.

  • Odd Tunnel Interface behavior - one end requires "no keepalive"

    Where's the quick version.  Tunnel between sites A & B.  This is GRE o IPSEC, but I don't think that's the issue.  Tunnel comes up and works great when:  site A has no keepalives and site B has no keepalives,  and it works when Site A has keepalives turned on and Site B does not.  The moment I turn on keepalives on site B, the tunnel goes down.
    This isn't a simple config.  Site A is an MPLS PE, meaning the Tunnel interface is configured with an fVRF and iVRF.  Site B has no VRF's - it is the CE.
    Any ideas on how to fix?  I need Site B's Tunnel interface to go down when connectivity fails.  My current workaround is to use EIGRP to update the routing tables.  I need to be able to support redundant paths with static and floating routes.

    Like this;
    Core1-r1#sh access-list ironport2
    Extended IP access list ironport2
        10 deny tcp host 10.247.254.174 any
        20 deny tcp any 192.168.0.0 0.0.255.255
        30 deny tcp any 10.0.0.0 0.255.255.255
        40 deny tcp host 10.230.3.250 any
        50 permit tcp 10.139.60.0 0.0.0.255 any (119568304 matches)
        60 permit tcp 10.230.32.0 0.0.0.255 any (9290669 matches)
        70 permit tcp host 10.230.48.12 any (141403 matches)
        80 permit tcp host 10.230.36.62 any (1456 matches)
        90 permit tcp host 10.150.18.7 any (741 matches)
    Core1-r1#
    10= P1 interface
    20= network we don't want to be sent to ironport
    30= " "
    40= M1 interface
    50->90=All testing subnets to go to ironport
    Thanks for the feedback! jc

  • Monitoring tunnel interface traffic

    We've integrated WLSM with IDSM-2 and want to monitor wireless traffic terminating on tunnel interfaces. Can't find a way to configure SPAN or VACL on IOS 6500 to capture traffic. Any suggestions?

    Try this:
    http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a0080459221.html

  • Dynamic virtual tunnel interface on 2821

    I tried to configure a dynamic virtual tunnel interface on a Cisco 2821 with release 12.4(9)T1 advanced ip services, aiming to terminate VPN client ipsec tunnels on it.
    The feature is supported by this software release. Documentation says:
    - enter configuration
    - configure a virtual-template interface
    - type "tunnel mode <mode>"
    but the router does not accept this command.
    Any hint?
    Thank you in advance.
    Denis

    Try:
    just have to take a look at the concentrator's configuration.
    http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_configuration_example09186a00801ae24c.shtml
    and this one is an example with routers
    http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080143b0a.shtml

  • BW showing under Tunnel Interface

    Hi,
    I've been looking through our VPN Tunnel Interfaces and noticed all of them have the same BW of 9Kbit. Where is this figure derived from?
    sh int tu17
    Tunnel17 is up, line protocol is up
      Hardware is Tunnel
      Description: Tunnel to M
      Internet address is 172.27.240.61/30
      MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
         reliability 255/255, txload 180/255, rxload 110/255
      Encapsulation TUNNEL, loopback not set
      Keepalive not set
      Tunnel protocol/transport GRE/IP

    Disclaimer
    The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
    Liability Disclaimer
    In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
    Posting
    It's a platform/IOS default.  It can be changed using the interface bandwidth statement (on the tunnel interface).

  • Mystery Tunnel Interfaces on 2921 Router

    Hi All,
    I need some help.
    For some reason it seems we have 3 Tunnel interfaces on the router, not sure how it got there but we are unable to delete them or configure them.
    They seem to take the loopback ip as source and if I delete the loopback interface it chooses another IP.
    Output from sh ip int brief, not sure where it gets those IP's from as well.
    Tunnel0                    172.16.0.1      YES unset  up                    up     
    Tunnel1                    172.16.0.1      YES unset  up                    up     
    Tunnel2                    172.16.0.1      YES unset  up                    up    
    See below when I try to enter interface config mode:
    Router1(config)#int tunnel 0
    % This interface cannot be modified
    Any suggestions or help will be appreciated.
    Regards
    Z

    Hi Zubair,
    this is due to WCCP. You have WCCP for service 61 and 62 so my guess is you have an optimizer appliance (like WAAS) talking WCCP with this router. The tunnel interfaces are the result of WCCP using GRE encapsulation to redirect the traffic to the WAN optimizers.
    you can find more info here:
    https://supportforums.cisco.com/docs/DOC-15782
    thanks,
    Fabrizio

  • Overlapping Networks with Tunnel GRE/IPsec and NAT

    Has anyone experience with NATing on a GRE tunnel interface? I need to NAT between two private networks because they are overlapping. I tried to NAT directly on the tunnel interface.
    e.g.
    Ethernet 0/0
    ip nat inside
    Tunnel0 (GRE with CryptoMap)
    ip nat outside
    However I didn't succeed this way. What's the best way to achive my goal?

    Thanks. I already checked this paper. The problem is that it only talks about IPsec and not about GRE/Ipsec and nating on a Tunnel interface.
    However I made some tests in the lab and it worked fine. So I went back to the customer-site and I had to reboot the small 836 to get it working.
    What I learnedis : "ip nat outside" on a tunnel interface on a Cisco 836 is no problem. This is good news if you have to add partners companies with GRE/IPsec and they don't have IP ranges you like, so you just NAT them and give them IP addresses of your choice.

  • Dual stack on tunnel interface

    Is it possible to run dual stack IP schemes over an ipsec-protected tunnel interface on IOS? I am able to assign the IPv6 addresses like a normal interface on both ends however when i try to ping across the tunnel with IPv6 there is no response. Here is an example of my config:
    R1
    interface Tunnel0
     description Tunnel to R2
     ip address 172.30.1.237 255.255.255.252
     ip mtu 1400
     ip nat inside
     ip virtual-reassembly
     load-interval 30
     ipv6 address FE80::172:30:1:1 link-local
     ipv6 address 2001:1::172:30:1:1/126
     keepalive 5 4
     tunnel source GigabitEthernet0/1
     tunnel mode ipsec ipv4
     tunnel destination 1.2.3.4
     tunnel protection ipsec profile protect-gre
    R2
    interface Tunnel0
     description Tunnel to R1
     ip address 172.30.1.238 255.255.255.252
     ip mtu 1400
     ip nat inside
     ip virtual-reassembly
     load-interval 30
     ipv6 address 2001:1::172:30:1:2/126
     ipv6 address FE80::172:30:1:2 link-local
     keepalive 5 4
     tunnel source FastEthernet0/1
     tunnel destination 1.2.3.5
     tunnel mode ipsec ipv4
     tunnel protection ipsec profile protect-gre
    The only solution i can clearly see is running a separate tunnel, which i would like to avoid. Any assistance is greatly appreciated!

    Hello,
    In my System preferences the IPv6 settings are set to "automatic", my DSL router (Cisco 787) supports IPv6. When visiting sites like www.sixxs.net and www.apnic.org (which are reachable by both IPv6 and IPv4), some pages are reached by IPv6 and some by IP4. Even the same page may load in IPv6 first, but a second time via IPv4. This behaviour has changed since my upgrade to Leopard, under Tiger the behaviour was much more stable.
    Gerard

  • DMVPN + IPSec protected VRFs; IPSec SAs established only on one tunnel interface

    Hello folks!
    I have a setup between two Cisco ISR routers, running IOS 15.1(4)M3. I have tried to establish DMVPN connectivity with two VRFs (ie. two tunnel interfaces per router) between the routers and it mostly seems to be working as I expected. But... IPSec SAs seem to get tied to only one of the tunnel interface, not two (one per direction) per tunnel interface as they should. There's no MPLS backbone in between the routers, only "global VRF", routed IP network.
    Command "show crypto ipsec sa" or indirectly a missing OSPF neighborhood between the routers verifies the erroneuous situation. Occasionally, after an "interface tunnel[ 0 or 1] shut, no shut" or "clear crypto sa" command I seem to get it up and running, two SAs per tunnel interface, but if I reboot either one of the routers or just clear the IPSec SA, they most likely will appear under either one of two tunnel interfaces. So, what should I change to instruct the router setup SAs correctly, two SAs (one per direction) per tunnel interface?
    I'll enclose appropriate parts of the configurations and output of command "show crypto ipsec sa".

    I think I figured it out, for anyone who might stumble across this post in the future. It looks like you need to add the shared keyword to the tunnel protection command. ie...
    interface tunnel 0
     tunnel protection ipsec profile MyProfile shared
    end
    I should note that one of the first things I tried was to created a separate IPSec profile for each unique tunnel interface. It ended up not fixing the problem and I had to go with the solution above. 

Maybe you are looking for