irlue to send the logs to remote server using port number will use which protocol by default TCP/UDP

It is UDP by default.

https://devcentral.f5.com/wiki/iRules.log.ashx

thanks for the reply .

One more doubt , so its doesnt matter if the VIP uses TCP protocol .

https://devcentral.f5.com/wiki/iRules.LogHttpTcpUdpToSyslogng.ashx

No, it doesn't matter which protocol the VIP is listening on.

So using this rule if remote server not receiving any logs what all things need to be checked.

Right now the remote server is not receiving logs .

I'd check a few things:

1. The default syslog port is 514, so make sure the remote syslog server is indeed listening on port 518.

    

2. Ensure that the F5 can reach this device. Try pinging it.

    

3. Run a tcpdump capture on the appropriate VLAN to see if there are any syslog messages leaving the box.

    

syslog server is listenting on port 518 and its pinging from F5 .

Also the irule is configured to send logs to two remote servers , one will use the default port and to the other server using 518 . below is the irule

when SERVER_CONNECTED { log x.x.x.x local0.info "client: [IP::client_addr]:[TCP::client_port] -> VIP: [clientside {IP::local_addr}]:[clientside {TCP::local_port}] -> Node: [IP::server_addr]:[TCP::server_port]" log x.x.x.x:518 local0.info "client: [IP::client_addr]:[TCP::client_port] -> VIP: [clientside {IP::local_addr}]:[clientside {TCP::local_port}] -> Node: [IP::server_addr]:[TCP::server_port]" }

Remote logging happening to first server using the default port . But to 2nd server logs are not reaching

So do we need to check the remote syslog server to see syslog service is running fine .

So just to clarify, the syslog server listening on port 514 is receiving logs, while the port 518 server is not. Correct? That would suggest the problem is either the server itself or something potentially blocking the traffic. With a tcpdump capture, do you see the port 518 traffic leave the F5?

Port 518 traffic leaving F5 .

Below is the output .

tcpdump -i 0.0 udp and host x.x.x.x and port 518 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on 0.0, link-type EN10MB (Ethernet), capture size 108 bytes 07:36:08.604991 IP x.x.x.x.59295 > .ntalk: UDP, length 144 07:36:25.769255 IP x.x.x.x.59187 > .ntalk: UDP, length 144 07:36:25.820978 IP x.x.x.x.42418 > .ntalk: UDP, length 144

Below is the o/p using port 514

tcpdump -i 0.0 udp and host x.x.x.x and port 514 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on 0.0, link-type EN10MB (Ethernet), capture size 108 bytes 07:36:25.510570 IP x.x.x.x.12255 > .syslog: SYSLOG local0.info, length: 144 07:36:25.769255 IP x.x.x.x.59187 > .syslog: SYSLOG local0.info, length: 144 07:36:25.820978 IP x.x.x.x.42418 > .syslog: SYSLOG local0.info, length: 143

That's right syslog server listening on port 514 is receiving logs .

The difference between "ntalk" and "syslog" in the captures is based on tcpdump's internal understanding of specific port-protocol mappings. You can disable that visual mapping with the following:

tcpdump -lnni 0.0 udp and host x.x.x.x and port 518

In any case, it does look like the port 518 traffic is leaving the box. The next step might be to ensure the remote port 518 syslog server is receiving it. If you can do a tcpdump on that server, look for the packets from the F5.