I am not clear whether you are asking to verify if UDP ports in general are able to reach the remote server or if you are interested in a specific port? If you are interested in UDP in general the easy way to test is to do traceroute on the router. The traceroute process on IOS routers sends UDP packets to the destination.
If you are interested in checking a particular UDP port then I am not sure that there is a good way to do that on the router. Are you asking in general or is there a particular connectivity problem that you are working with?
yeah I can't workout whether a server on the remote site (This is a VPN) can receive UDP 9996 for Netflow. i need this UDP port to go from this Cisco router over the VPN to a server.
I have an access-list 101 permit ip 172.19.10.0 0.0.0.0 any
and access-list 101 permit udp 172.19.10.0 0.0.0.0 any
the match address is 101 and put on the crypto map.
From this site I can access all our servers form my laptop and everything.
Edited my earlier post: What service in remote server running in UDP port? Syslog, DNS, what OS running in the server?
From other posts from Andy I am pretty sure that this is a Netflow collector and analysis service. Andy can you confirm that?
From the access list that you show part of I am pretty sure that UDP 9996 is going through the VPN tunnel. It might be helpful if you would post the config (or at least all of the parts that have to do with crypto and VPN.
Here is some of it:
crypto isakmp policy 1
crypto isakmp key ******* address 126.96.36.199
crypto ipsec transform-set vo_t_set esp-3des esp-md5-hmac
crypto map vo_t_set 10 ipsec-isakmp
set peer 188.8.131.52
set transform-set vo_t_set
match address 101
ip address negotiated
ip access-group inbound_acl in
no ip unreachables
dialer pool 1
ppp authentication chap pap callin
ppp chap hostname *****@hg57.btclick.com
ppp chap password 0 *****
ppp pap sent-username ******hg57.btclick.com password 0 *****
crypto map vo_t_set
ip route 0.0.0.0 0.0.0.0 Dialer1
ip access-list extended inbound_acl
permit udp any any eq isakmp
permit esp any any
deny icmp any any timestamp-request
deny icmp any any timestamp-reply
permit icmp any any
permit udp any any eq ntp
permit tcp 184.108.40.206 0.0.0.31 any eq telnet
permit tcp 81.*.*.* 0.0.0.31 any eq 22
permit tcp 81.*.*.* 0.0.0.31 any eq ftp-data
permit tcp 81.*.*.* 0.0.0.31 any eq ftp
permit tcp 81.*.*.* 0.0.0.31 any eq www
permit tcp 81.*.*.* 0.0.0.31 any eq 443
permit ip 192.168.21.0 0.0.0.255 172.19.10.0 0.0.0.255
access-list 101 permit ip 172.19.10.0 0.0.0.255 any
dialer-list 1 protocol ip permit
As long as the Netflow packet has a source address in subnet 172.19.10.0/24 then it sure looks like it would go through the VPN tunnel.
Does the server need configuration of its remote sources or does it just accept and process any traffic that it receives on UDP 9996?
Netflow tell me any UDP traffic from 9996 will be processed upon arrival.
this is what i have added:
router(config)#interface Ethernet 0
router(config-if)#ip route-cache flow
router(config)#ip flow-export destination 192.168.21.19 9996
router(config)#ip flow-export source Ethernet 0
routerconfig)#ip flow-export version 5
router(config)#ip flow-cache timeout active 1
router(config)#ip flow-cache timeout inactive 15
router(config)#snmp-server ifindex persist
router#show ip flow export
router#show ip cache flow
this looks good too:
sh ip flow export
Flow export v5 is enabled for main cache
Exporting flows to 192.168.21.19 (9996)
Exporting using source interface Ethernet0
Version 5 flow records
353 flows exported in 69 udp datagrams
0 flows failed due to lack of export packet
3 export packets were sent up to process level
0 export packets were dropped due to no fib
0 export packets were dropped due to adjacency issues
0 export packets were dropped due to fragmentation failures
0 export packets were dropped due to encapsulation fixup failures
Just to verify something: is the interface Ethernet 0 in subnet 172.19.10.0/24?
Would I be correct in assuming that other traffic is going through the VPN ok?
And would I be correct in assuming that a traceroute (or tracert) from a device connected on interface Ethernet 0 shows that it does go through the VPN and that the response from the device after the router is from the peer at 220.127.116.11?
Ethernet 0 is 172.19.10.1
All users and traffic are working fine.
the last part I'm 99% sure your are correct, I'd have to test, but I route all traffic through the VPN.
I'm wondering if it's the router. I might test on an 1841 ADSl tomorrow.
I would be surprised if it were the router - but it would not hurt to test with 1841 and see if it makes a difference.
I am wondering if it might be a packet size issue. Since you are sending the Netflow over the VPN tunnel the VPN will add extra header information to the packet. If the Netflow was already as large as the MTU adding the extra header info would make it too large. Do you know or can you find out what size the Netflow packets are that are sent from your router?
I will try and find out, this the first time I've tried NetFlow. I just what a way to see how are networks are being used especially when a user is slowing a VPN link down.
I actually thought the router cached the data then sent it to the NetFlow server.
It is true that the router does cache the NetFlow data for a bit and then sends it to the NetFlow server. If you want to see it you can use the command show ip cache flow. You will find that the flows on the router expire fairly quickly so you can not go very far back on the router. That is one of the advantages of the NetFlow server is that is maintains historical data. And you may find that interpreting the information about source and destination port is difficult since that information is presented in hex not decimal. But if you are mostly interested in understanding source addresses then looking on the router may be quite satisfactory.
I have done some searching and it looks like there are a couple of bugs that have been filed about problems sending NetFlow through VPN tunnels. You can take a look at these (assuming that you have the right privileges on CCO) CSCsk25481 and CSCef28662
I wonder if anyone has got Netflow working over a VPN then? Are they saying is a bug or that it can't be done as it says no workaround?
At first I thought could the cache get cleared before it's sent?
Should I repost to see if anyone is using it over a VPN?
I'd love to get this working, unless there are other web tools I could use to see this data?
Spooky! Just look at the Netflow website and there it is the router showing up. However not much data and the alert is saying it has only received one flow from the router in the last 10 minutes. Seems like something somehow is getting there, shame I am a novice to work out why.
I am encouraged that some data has shown up on the NetFlow website.
I would suggest that it might not be a bad idea to start another thread on the forum asking if anyone has experience (or has suggestions) with running NetFlow over VPN.
Will do, I'm not sure which interface to really monitor. I have an Ethernet cable from one of the four LAN ports on the back of the Cisco 837 into a 24 port switch. I have Ethernet 0 which assume is live a VLAN across the four ports being monitored. Not sure if it should be this or ATM 0 or dialer 1?
I ran up an 1841 ADSL in a VPN mode, and had the same issues. So I installed the Netflow application onto a laptop on the side of the VPN, and it all instantly worked. So it must be a VPN issue.
Shame about this, are there other tools I could test. Then again I could install the free version (2 interfaces) on a PC at every site.
Thanks for confirming your additional testing and it looks like it is a bug with NetFlow over VPN. I would hope that Cisco would address this and provide a fix but I have no idea how long we will wait to see this.
What a Cisco pro like you do to check who's doing what over a VPN when things go slow on the bandwidth? Just those console ip flow and cache export commands?