I have 2 data sources with UDP 514, I use the "Only accept word connection" field to split into 2 sources but when I split, there is no data about Splunk. I try to put it together in one source, there is data.
While this may or may not answer your problem specifically, it answers your problem generically.
Do not have Splunk listen on network ports, at least for traffic that's syslog or any other well-known standard protocol with a zillion awesome apps built specifically to listen on those ports. Just because you can do this doesn't mean that you should.
Instead, install syslog-ng (for Linux, or the free edition of Kiwi Syslog Daemon for Windows, or even run a tiny VM with Linux and syslog-ng on it) and have it listen for syslog and write it to file. Then have Splunk pick up the files from that location.
The biggest two problems this solves are that Splunk needs restarting often, and takes forever and a half to do so. UDP doesn't care that the packet doesn't make it and nothing was listening, UDP is a "fling it and hope" protocol so when Splunk is restarting those just get lost. Conversely, syslog-ng restarts in the blink of an eye, and frankly almost never even needs restarting anyway. the second problem is that, as you noticed, routing issues can occur because you are mixing all those inputs on 514 with each other. A syslog receiver can handle that easily, dropping files into separate folders based on ... well, almost anything - hostname, IP, content, facility ... whatever it is. Then Splunk can use the folder name as the hostname if you want, when you read it.
The interwebs are full of setting this sort of solution up - the tiniest amount of digging will turn up all sorts of guides for a simple solution, and Answers here also has some help.
While this may or may not answer your problem specifically, it answers your problem generically.
Do not have Splunk listen on network ports, at least for traffic that's syslog or any other well-known standard protocol with a zillion awesome apps built specifically to listen on those ports. Just because you can do this doesn't mean that you should.
Instead, install syslog-ng (for Linux, or the free edition of Kiwi Syslog Daemon for Windows, or even run a tiny VM with Linux and syslog-ng on it) and have it listen for syslog and write it to file. Then have Splunk pick up the files from that location.
The biggest two problems this solves are that Splunk needs restarting often, and takes forever and a half to do so. UDP doesn't care that the packet doesn't make it and nothing was listening, UDP is a "fling it and hope" protocol so when Splunk is restarting those just get lost. Conversely, syslog-ng restarts in the blink of an eye, and frankly almost never even needs restarting anyway. the second problem is that, as you noticed, routing issues can occur because you are mixing all those inputs on 514 with each other. A syslog receiver can handle that easily, dropping files into separate folders based on ... well, almost anything - hostname, IP, content, facility ... whatever it is. Then Splunk can use the folder name as the hostname if you want, when you read it.
The interwebs are full of setting this sort of solution up - the tiniest amount of digging will turn up all sorts of guides for a simple solution, and Answers here also has some help.
Thanks for the answer. I think it is a great idea
i am user cluster mode, every configure monitor added by master note. Monitor sample like:
[udp://10.48.255.4, 10.48.15.50:514]
connection_host = ip
index = nw_cisco
sourcetype = cisco:ios
[udp://10.6.20.24, 10.6.20.25:514]
connection_host = ip
sourcetype = tippingpoint:syslog
index=nw_ips