Forum Discussion
0_48485
Nimbostratus
Nimbostratusirule for port translation
All -
I'm trying to write an IRULE to send SIP SUBSCRIBE requests to a different port (5050) on my servers since i need to handle those requests differently. I put in the following as an IRULE:
when SIP_REQUEST {
if {[SIP::method] == "SUBSCRIBE"} {
node 1.2.3.4 5050
}
}
i know the method is matching, but i never see a packet arrive on 5050. it still maintains the original destination port of 5060. even tried a pool statement instead on a node statement. my 5050 pool/node is up and monitors are green. do i need to rewrite the packet with a new destination port somehow? any ideas? if it matters, i'm currently running ltm 9.4.1...
Thanks in advance!
-John
5 Replies
0_48485referencing the previous codeblock i changed:
node 1.2.3.4 5050
to
SIP::Respond 404 "unsupported method"
and i saw the packet come back as expected, so i know it's matching the method and my logic is correct. i can't understand why it's still not translating the port on the SIP packet. i might try upgrading to the latest version of the ltm software - unless of course someone already has the latest load and can test it out for me...
hoolioCirrostratus
I wonder if there is still an issue (routing?) for the BIG-IP sending load balanced (as opposed to monitor traffic) to the node. If you set the pool on a VIP to that IP/port, do requests make it to the server? If you add a log entry to LB_FAILED, does it get triggered?
Aaron- 0_48485if i attach that pool to a test VIP and send a generic udp packet to 5050 it goes through fine.
in the logs i did see the following:
May 22 12:34:25 tmm tmm[7595]: 01220001:3: TCL error: Rule SIP_INTERCEPT_SUBSCRIBE - Address in use (line 13) invoked from within "pool sip_udp_5050_pool member 1.2.3.4 5050"
(yes i replaced the real ip with 1.2.3.4)
any idea what that means? I've never seen that before when using a node/pool function. - hoolioThe TCL error would explain why no packet is sent to the server. I haven't run into the address in use error before either. There have been a few posts on it, but nothing very conclusive.
cmbhatt suggested using LB::detach (Click here). Other workarounds have included moving the pool command from CLIENT_DATA to CLIENT_ACCEPTED. That's not very relevant here though.
Anyone else have ideas?
Aaron - 0_48485tried adding LB::detach before the pool/node function. it did absolutely nothing.
