- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Multiple TCP connections for logging
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Multiple TCP connections for logging
We have a small problem Houston.
One of our gateways is located in the kingdom far far away with over 200ms latency to the log server. Lately we noticed that part of the logs started to be saved locally on the gateway.
Investigation proved that we have reached the "limit" of a single TCP pipe (latency plus window size) that's around 1.5Mbps. Other evidence includes the fact that 2GB log file on log server never fills faster than 1.5hrs (note though that includes 2 VS logs so technically rate there is 2x1.5=3Mbps) and TCP send queue is noticeable on the gateway.
Solutions could be:
- keep disabling logging for highly used rules - not ideal as we already have cut a lot of fat
- bring log server closer to gateway - can't really as we have MLM that serves many other kingdoms far away
- increase TCP window - not ideal to go any higher as re-transmission overhead would grow a lot
- transfer locally saved files with a script - but that potentially would introduce noticeable latency in log delivery
- add the second TCP connection for log transfer because that would double transfer rate capacity
Does anyone know if it's really possible - to have multiple TCP connections for log transfer. I did some digging in UC but did not find anything. I'm interested in VSX "version"
Or does anyone know if we can "split" MLM or have two MLMs?
- Tags:
- high latency
- log
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unless Check Point has a multi-threaded log transfer agents already, I suspect that you are limited to the choices you have described.
One exception, possibly, is the use of the bandwidth (or WAN) optimization appliances on both sides. You really would not know if this approach works until you try. Riverbed is probably one of the better known names in that market.
WAN Optimization – WAN technologies from Riverbed
You can give them a call and try to get their engineers' opinion on the subject and anticipated (or not) improvements.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hehe - we just ripped out all the WAN accelerators as all they did was cause headaches
Yeah - I'm bit curious about multi-threaded log transfer
Might migrate the secondary MDS to the kingdom far far away and use that as log server for local firewalls - seems like the most logical step with the least cost. Additionally it will make local FW admin much faster for local admins as SmartDashboard gets really slow with that sort of latency
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
...begs the obvious question: did you have these issues with log transfers when the WAN accelerators were in play?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
no, but we didn't as many logs either we have multiplied firewalls and logs ten-fold since then
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is also a possibility of the UDP log shipping with TCP error checks.
