Forum Discussion
epaalx
Cirrus
CirrusHSL iRule is failing
I'm using BIG-IP VE 11.6.0HF4.
I cannot get HSL to work.
My syslog_server_pool is fine - I can see its UDP probes'
default send stringWhen I send traffic, /var/log/ltm shows:
Aug 10 17:25:49 BigIP-A info tmm[15093]: Rule /Common/hsl_SERVER_CONNECTED : Active members: 1, HSL handle is 'MDS:/Common/syslog_server_pool:UDP'; send result is '0'
Aug 10 17:25:49 BigIP-A info tmm[15093]: Rule /Common/hsl_SERVER_CONNECTED : 99.99.99.2:59012 -> 66.66.66.2:80 ::: 88.88.88.2:59012 -> 99.99.99.2:80
but no
Test0R's, Alex
root@(BigIP-A)(cfg-sync Standalone)(Active)(/Common)(tmos.ltm.virtual) list v.Client1.http
ltm virtual v.Client1.http {
destination 66.66.66.2:http
ip-protocol tcp
mask 255.255.255.255
pool c.Client1.http
profiles {
http { }
tcp { }
}
rules {
hsl_SERVER_CONNECTED
}
source 0.0.0.0/0
source-address-translation { type automap }
vs-index 3
}
root@(BigIP-A)(cfg-sync Standalone)(Active)(/Common)(tmos.ltm.rule) list hsl_SERVER_CONNECTED
ltm rule hsl_SERVER_CONNECTED {
when SERVER_CONNECTED {
set pool syslog_server_pool
set hsl [HSL::open -proto UDP -pool $pool]
set res [HSL::send $hsl "Test\n"]
log local0. "Active members: [active_members $pool], HSL handle is '$hsl'; send result is '$res'"
log local0. "[IP::client_addr]:[TCP::client_port] -> [clientside {IP::local_addr}]:[clientside {TCP::local_port}] ::: [serverside {IP::local_addr}]:[serverside {TCP::local_port}] -> [IP::server_addr]:[serverside {TCP::remote_port}]"
}
}
root@(BigIP-A)(cfg-sync Standalone)(Active)(/Common)(tmos.ltm.pool) list syslog_server_pool
ltm pool syslog_server_pool {
members {
loghost1-net:514 {
address XX.XX.XX.XX
session monitor-enabled
state up
}
}
monitor udp
}
root@(BigIP-A)(cfg-sync Standalone)(Active)(/Common)(tmos.ltm.pool) show syslog_server_pool
---------------------------------------------------------------------
Ltm::Pool: syslog_server_pool
---------------------------------------------------------------------
Status
Availability : available
State : enabled
Reason : The pool is available
Monitor : udp
Minimum Active Members : 0
Current Active Members : 1
Total Requests : 0
Current Sessions : 0
Traffic ServerSide
Bits In 0
Bits Out 0
Packets In 0
Packets Out 0
Current Connections 0
Maximum Connections 0
Total Connections 0
Connection Queue Pool Pool and members
Number of connections queued now 0 0
Number of connections serviced 0 0
Queue head entry age (ms) 0 0
Maximum queue entry age ever (ms) 0 0
Maximum queue entry age recently (ms) 0 0
Average queue entry age (ms) 0 0
HamishCirrocumulus
Is the route to the server in syslog_server_pool setup to go via a TMM interface and not the management interface? HSL only works on TMM interfaces.
H
- Stewart
Altostratus
Hello,
In your rule you don't actually tell HSL to send anything.
Try putting this into your iRule
HSL::send $hsl "<190> Test\n"
You should then get a message sent to your syslog server. The <190> refers to syslog facility and severity local7.info
Thanks, Stewart.
epaalxThank you Hamish - the outgoing interface was indeed management interface - problem fixed once I defined appropriate route.
I fail to understand
- why F5 has not documented this in High Speed Logging description;
- how it makes sense for monitors to use the management interface but not HSL;
- why HSL should not be considered management-type traffic and be out-of-band capable.
mm_pen_242283Nimbostratus
Hi epaalx.
Where exactly did you manage to add that route? Is the route towards the log publisher pointing to external TMM interface now?
- Hamish
- I think it's documented somewhere... Or maybe I remember that from when I first used it in v10 (And had the same issue BTW). Check the LTM docs. It's probably in there. I've taken the liberty of editing the HSL Wiki page for you with a note about routing an the use of management/switchport interfaces.
- It makes sense for monitors to use mgmt interface because they run under the host OS itself. And are part of the management. HSL never leaves the TMM so they literally only have access to switch port interfaces. if they had to leave via the management interfaces they'd no longer be HighSpeed...
- Because it's not management type. It's accessible from iRules. Therefore should NEVER have access to any management routes. It would possibly be a potential security hole if it were possible to access management interfaces from iRules. (Yeah I know the logging does, but that's a bit more tied down).