möglicherweise gibt es Problem mit dem SIP-ALG in Verbindung mit DSCP-Tag.
Im konkreten Szenario ist ein QoS-Schema (angelehnt an Cisco Medianet) durchgängig auf Switches und Routern implementiert. Dabei ist CS1 als "low priority data" definiert.
Über einen WLC-4006+ (9.10.0356) als Gateway-Router mit SIP-ALG sind zwei SIP-PBX-Leitungen (aus 1723/1823) über VPN gekoppelt. Nun ist es so, dass die mit CS3 vom SIP-ALG empfangenen Daten (CS3 = voice/video signalling) nach der Überarbeitung durch das SIP-ALG mit CS1 weitergeschickt werden.
Das ist, soweit ich sehen kann, nicht einstellbar und führt bei hoher Last mit einem Protokollmix zu Drops in der Klasse CS1. Dabei gehen die SIP-PBX-Leitungen offline.
Frage: Gibt es einen Weg, dem SIP-ALG beizubringen, mit welchem DSCSP-Tag es Pakete weiterschicken soll oder bestehende Tags nicht anzufassen?
Trace:
Code: Alles auswählen
[Firewall] 2015/09/01 18:21:32,341
Packet matched rule 1-RT-HE-IN
DstIP: 10.10.35.141, SrcIP: 10.10.31.1, Len: 444, DSCP: CS3 (0x18), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 27727, SrcPort: 5060
[IP-Router] 2015/09/01 18:21:32,341
IP-Router Rx (HE00R001, RtgTag: 1):
DstIP: 10.10.35.141, SrcIP: 10.10.31.1, Len: 444, DSCP: CS3 (0x18), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 27727, SrcPort: 5060
Filter (Forwarded to SIP-ALG)
[SIP-ALG] 2015/09/01 18:21:32,342 [AlTask] : cAlTask::processUdpRx 1 Src:10.10.31.1:5060, Dst:10.10.35.141:27727
[SIP-ALG] 2015/09/01 18:21:32,342 [AlTask] : cAlTask::processUdpRx 2 PayloadSize:416
[SIP-ALG] 2015/09/01 18:21:32,342 [AlTask] : cAlTask::processUdpRx 4 ComChan:c
[SIP-ALG] 2015/09/01 18:21:32,342 [AlTask] : cAlTask::processUdpRx 4.2 ComChan:c
[SIP-ALG] 2015/09/01 18:21:32,342 [AlTask] : cAlgSipTransportRegistry::GetTransport addr:10.10.31.1, locPort:0, remPort:0, DscrAddr:0.0.0.0, DscrLocPort:0, DscrRemPort:0, Application:00000000
[SIP-ALG] 2015/09/01 18:21:32,342 [AlTask] : cAlgSipTransportRegistry::GetTransport addr:10.10.31.1, locPort:0, remPort:0, DscrAddr:10.10.35.130, DscrLocPort:0, DscrRemPort:5060, Application:00000000
[SIP-ALG] 2015/09/01 18:21:32,342 [AlTask] : cAlgSipTransportRegistry::GetTransport addr:10.10.31.1, locPort:0, remPort:0, DscrAddr:213.166.61.156, DscrLocPort:11381, DscrRemPort:5060, Application:02ffb700
[SIP-ALG] 2015/09/01 18:21:32,342 [AlTask] : cAlgSipTransportRegistry::GetTransport addr:10.10.31.1, locPort:0, remPort:0, DscrAddr:10.10.35.141, DscrLocPort:0, DscrRemPort:14546, Application:00000000
[SIP-ALG] 2015/09/01 18:21:32,342 [AlTask] : cAlgSipTransportRegistry::GetTransport addr:10.10.31.1, locPort:0, remPort:0, DscrAddr:10.10.31.1, DscrLocPort:0, DscrRemPort:5060, Application:030d28a0
[SIP-ALG] 2015/09/01 18:21:32,342 [Sip-UA] : DISPATCH_UDP SrcAddr: 10.10.31.1:5060, DstAddr: 10.10.35.141:27727, ComChan: c, TxChan: 80000000, RtgTag: 1
[SIP-ALG] 2015/09/01 18:21:32,342 [SIP] : DecodeDatagram 1 MessageBufferLength:416
[SIP-ALG] 2015/09/01 18:21:32,342 [SIP] : Response: 200
[SIP-ALG] 2015/09/01 18:21:32,342 [SIP] : DecodeDatagram 2 MessageBufferLength:0
[SIP-ALG] 2015/09/01 18:21:32,342 [SipUa] : cAlgSipUa:SipResponseHndl
[SIP-ALG] 2015/09/01 18:21:32,342 [Sip-CallDb] : cAlgSipCallDb::FindCall 1 CallId:698404721@00a057123b7b, IP:10.10.35.141
[SIP-ALG] 2015/09/01 18:21:32,342 [Sip-CallDb] : cAlgSipCallDb::FindCall 2 pCall-CallId:4cdbc00140fa4cd9443ced6878c5a58a@[::1], pCall-IP:10.10.35.130
[SIP-ALG] 2015/09/01 18:21:32,342 [Sip-CallDb] : cAlgSipCallDb::FindCall 2 pCall-CallId:698404721@00a057123b7b, pCall-IP:10.10.35.141
[SIP-ALG] 2015/09/01 18:21:32,342 [SIP-CALL] : StartAging Call-Id: 698404721@00a057123b7b, Aufrufer: 012fa088, timeout:0
[SIP-ALG] 2015/09/01 18:21:32,342 [SIP-Binding] : - info : SetExpirationTime, ExpirationTime:600, Port:0
[SIP-ALG] 2015/09/01 18:21:32,342 [SIP-Binding] : - info : UpdateStatus Name:
[SIP-ALG] 2015/09/01 18:21:32,343 [ALG] : - info : FORWARD_MESSAGE
[SIP-ALG] 2015/09/01 18:21:32,343 [ALG] : - info : FIND_DESTINATION Entity for Transport: Src: 10.10.31.1:5060, Dst: 10.10.35.141:27727, ComChan: c, TxChan: 80000000
[SIP-ALG] 2015/09/01 18:21:32,343 [ALG] : - info : FIND_DESTINATION 9 User.Src:10.10.31.1:5060, User.Dst:10.10.35.141:27727, Ext:10.10.35.1:0, TxChan:80000000, ComChan:80000000, Name:
[SIP-ALG] 2015/09/01 18:21:32,343 [ALG] : - info : FIND_DESTINATION 9.10
[SIP-ALG] 2015/09/01 18:21:32,343 [ALG] : - info : FORWARD_MESSAGE Entity Dst:10.10.35.141:27727, Src:10.10.31.1:5060, Ext:10.10.35.1:0, ComChan: 80000000, Name:
[SIP-ALG] 2015/09/01 18:21:32,343 [SIP-Binding] : - info : USER::INITIATE_CALL
[SIP-ALG] 2015/09/01 18:21:32,343 [SIP-Binding] : - info : USER::TRIGGER_PENDING_MSG
[SIP-ALG] 2015/09/01 18:21:32,343 [SIP-Binding] : - info : USER::GENERATE_SIP_MSG
[SIP-ALG] 2015/09/01 18:21:32,343 [SIP-Binding] : - info : cAlgUser::SipResponseMessageAppendSipFields DstIp:10.10.35.141
[SIP-ALG] 2015/09/01 18:21:32,343 [SIP-Binding] : - info : USER::CHANGE_VIA_ADDRESS 1
[SIP-ALG] 2015/09/01 18:21:32,343 [SIP-Binding] : - info : cAlgUser::changeViaAddress 2 Key:Via, Row1:SIP/2.0/UDP, ip:10.10.35.141, port:27727, Row2:branch=z9hG4bK-297a2fe0-08e223df
[SIP-ALG] 2015/09/01 18:21:32,343 [ALG] : - info : FORWARD_MESSAGE Ende
[IP-Router] 2015/09/01 18:21:32,343
IP-Router Rx (intern, RtgTag: 1):
DstIP: 10.10.35.141, SrcIP: 10.10.31.1, Len: 444, DSCP: CS1 (0x08), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 27727, SrcPort: 5060
Route: BRG-1 Tx (VOIP):
DSCP-Tag wurde von SIP-ALG verändert! Das sollte nicht oder einstellbar sein, weil eine vorhandene QoS-Priorisierung (z. B. CS3 für SIP) durcheinangergerät, wenn das SIP-ALG daraus CS1 macht.
CS1 wird oft für niedrigste Priorität und höchste Drops gewählt.
Bei hohem restlichem Datendurchsatz kann es vorkommen, dass SIP-PBX-Leitungen dadurch als nicht erreichbar ausfallen, weil die SIP OPTIONS-Pakete gedroppt wurden.
Gruß,
Rougu