Forum Discussion
Chris_Phillips
Nimbostratus
Nimbostratusconverting UDP connections to TCP
I'm going out on a limb in the way i'm asking this... but how can I convert UDP packet payloads into TCP connections on the server side?
i'm aware this is normally a really stupid thoughtless question showing i don't understand TCP/IP any more than my cat. but my situation is that i have a bunch of Cisco Catalyst switches which only send syslog data as UDP packets. these packets are (to my knowledge) only ever one packet long, and just hit the remote syslog server and get logged. i'm wanting to put a virtual server infront of my syslog servers, to provide a better architecture, and would really like to be able to somehow craft an irule to take the UDP payload content and convert it to a TCP connection to whichever backend server i'm currently connected to. this should then be able to provide a more scalable and reliable architecture for otherwise unreliable traffic. any clues which way iRules would do this?
As i can take a UDP::payload or TCP::payload and do whatever i want with that raw data in an iRule i'm trusting you guys and girls can tell me how to put that payload into TCP onwards...
Thanks
Chris
hoolioCirrostratus
I'm going to go out on a limb here and say this isn't possible. When you define a virtual server, you need to specify a protocol of UDP or TCP. The clientside and serverside profiles have to be the same protocol. I don't know of anyway to work around this. But if someone else has ideas, I'd like to see.
And I'm not sure about the utility of this even if it were possible. There isn't a mechanism in UDP or syslog for the BIG-IP to tell the Catalyst that it needs to resend a dropped or corrupt packet.
If you want more intelligent checks, couldn't you use an SNMP monitoring station to poll the catalysts? The SNMP station would be able to retry the polling if it didn't get an answer from the destination host.
Aaron
Chris_Phillipsno, there's no mechanism on the client side, but i can say that if a switch can get a syslog message in UDP to one of my two pairs of LTM 6400's then from that point on i can guarantee that it will reach one of the 4 members of the syslog server pool via tcp, which can't give me that level of assurance / resilience from a single IP address.
i guess that what i could do is log the udp payload to the LTM itself and then let the underlying syslog-ng instance on the LTM's forward that log on as a seperate thing with TCP, but i don't like the idea of tinkering under the hood. everything thing like that i do is yet another thing that i have to manually redo each time i upgrade the software etc...
we use a combination of snmp and syslog here, generally favouring syslog over snmp traps, but then snmp traps are UDP too. and we can't poll for an interface bouncing over a few seconds, that's for a log message.- JRahm
Admin
You could use BEEP depending on your Cisco OS level
http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a00807883c3.html
Also, you could write syslog to flash locally on your catalysts and then ftp them off occasionally.
http://www.cisco.com/en/US/products/ps6566/products_feature_guide09186a0080611212.htmlwp1057595 - Chris_PhillipsIOS for our catalyst switches (2950, 2960, 3750 etc...) only go up to 12.2, not sure why cisco haven't released 12.4 or even 12.3 for them, but that's life. if they did then they'd be able to use TCP syslog in the first place and i wouldn't be writing this thread...
as for periodic this or that, that's the point really... need to timeliness of instant logging and notification, not an occasional poll. - Chris_Phillipssaw this thread just now, and maybe this is more of a tanglible approach to take.... just in my situation i'd want to use the udp payload as the log message itself and never forward to a pool.
http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&forumid=5&postid=8888
that would give me a tcp connection on the server side at least, and apaprently syslog-ng.conf changes do persist an upgrade too. one other thing this raises to complete the solution is that i would like to be able to forward to a vip, not an end server. but am i right in believing it's impossible for an LTM to connect to a vip it hosts? never been able to so far... - hoolioThat's an interesting approach. In 9.4 you can access a VIP from the command line of the BIG-IP itself. You might be able to configure syslog-ng to use a VIP as the destination for messages. I haven't tested it and I assume it's not something F5 would necessarily support, but it might work.
Aaron - Chris_Phillipswell it's totally syslog centric, but i wouldn't be suprised if there are few other angles for doing something like this. i guess this raises issues about what an LTM is used for and how is it considered by the given end user... may well be a bastardisation / misuse of the system... mind you we're using our LTM's as NTP servers, which is probably about as bad!
do you know of more info about this VIP change in 9.4? any reason why thigns are the way they are previously? - hoolioI'm not sure what the logic was in previous versions or why it was changed in 9.4. However, it's handy being able to test the VIP directly from the BIG-IP. You can also reference a VIP from a rule. However, for reasons unknown, I don't think you can add a VIP as a node in a pool (yet?).
Aaron
