Monitoring channel status by jitter / packet loss
Good afternoon, colleagues.
Having gathered my thoughts, I decided to properly draw up the solution that was born to me.
So, the statement of the problem :
There are two channels between points A and B, most often from different providers. It is necessary to ensure that the quality of service is accounted for on these channels, namely:
1. For losses> 0.5% on the channel, the channel should not be used.
2. When jitter> 10ms, the channel should not be used.
This problem arose at my work, because the two cities are connected by two channels through which a large number of voices run, which, as you know, is very moody in relation to the above indicators. Who cares - you are welcome under cat.
The original decision .
Initially, there were even two clumsy options. The first was to raise a pingovalka on tsiska, checking the survivability of the channel and switching over its death. The solution worked out until we had problems with jitter in the absence of losses.
The second solution was to create a monitor based on udp packets that mimic the G729 codec. The monitor showed losses and jitter, in case of communication problems, the admin climbed onto the cat, watched the current values of jitter and losses on it, and, according to the circumstances, made a decision to disable the channel. It worked, of course. But this is some kind of semi-automatic system turned out. Therefore, I pulled myself together and brought this situation to some final solution.
Current solution .
So, as in the second case, we create a channel quality udp monitor that imitates the G729a codec (the so-called SLA monitor). This monitor will send 1000 packets at intervals per minute to port 49333 at the destination, marking tos = 70 = 0x46 = EF. At the destination, it should be turned on. Next, we create a stab track (created specifically to control it using applets, rather than binding it tightly to the SLA monitor): Now our task is to remove the results from the SLA monitor and leave track 20 in their values UP state or put it on. This can be done, for example, using Cisco EEM (Embedded Event Manager), which allows you to monitor the current state of your hardware and perform certain actions.
To do this, create two applets. One will put the track in the Down state if at least one of the parameters (jitter or the number of losses) does not suit us. The second will raise it back if BOTH parameters are normal.
Configuration
1. We create the first applet:
We create two events based on SNMP OID for RTT and jitter From our SLA-monitor: Here the last digit 33 in SNMP OID is the SLA instance number. 10 - threshold for jitter (in ms), 994 - the minimum allowable number of returned packets out of a thousand sent (1000 - packet_loss). poll-interval - the interval at which the cat polls the state of values. Here 4s. We indicate that our applet should work with ANY of the events, i.e. logical OR is used. Further action:
Those. our track is in the Down state.
The second applet is similar: Only the applet is triggered by a logical AND between events. And the track is charged up. It can be seen that the survey takes place with an interval of 4 s and the current state of the track is not taken into account, i.e. ladders are triggered constantly, every 4s. I tried to fasten the monitoring of the state of the track itself, but it worked very buggy, it didn’t always work. So I donated a couple of percent and left it like that. In addition, there are applets, informing me about the problems on the channel and their disappearance: and in the variable $ _cli_result contains the result of the output of the last command that in our case, show ip sla stat 33.
In other words, we are sending ourselves a letter, in the body of which is the result of the last launch of the SLA monitor, which actually caused the switching of the track.
So, now actually how to take this into account . I see two ways:
1. a line in the route-map (as it works for me, actually, but it’s just a tricky scheme)
2. statics tracking, when we have a route of the form
With losses or jitter on the channel, this route will simply be removed from the table routing and traffic will go on an alternative path.
It may be clumsy, but I tormented myself for a week without thinking anything better. What is rich, as they say.
PS I mean that the reader is a little familiar with the basics of the Cisco
PPS console. The syntax of ip sla commands differs by 12.4T and 12.4, but the meaning is the same.
PPS If clarifications are required that do not go beyond the boundaries of several lines - write, I will add.
Sincerely,
Ilya Podkopaev
_________
UPD : regarding the CPU. In general, under load without applets, I have a router load (ISR 3845) of about 42% on average, with an applet - 43-44.
Having gathered my thoughts, I decided to properly draw up the solution that was born to me.
So, the statement of the problem :
There are two channels between points A and B, most often from different providers. It is necessary to ensure that the quality of service is accounted for on these channels, namely:
1. For losses> 0.5% on the channel, the channel should not be used.
2. When jitter> 10ms, the channel should not be used.
This problem arose at my work, because the two cities are connected by two channels through which a large number of voices run, which, as you know, is very moody in relation to the above indicators. Who cares - you are welcome under cat.
The original decision .
Initially, there were even two clumsy options. The first was to raise a pingovalka on tsiska, checking the survivability of the channel and switching over its death. The solution worked out until we had problems with jitter in the absence of losses.
The second solution was to create a monitor based on udp packets that mimic the G729 codec. The monitor showed losses and jitter, in case of communication problems, the admin climbed onto the cat, watched the current values of jitter and losses on it, and, according to the circumstances, made a decision to disable the channel. It worked, of course. But this is some kind of semi-automatic system turned out. Therefore, I pulled myself together and brought this situation to some final solution.
Current solution .
So, as in the second case, we create a channel quality udp monitor that imitates the G729a codec (the so-called SLA monitor). This monitor will send 1000 packets at intervals per minute to port 49333 at the destination, marking tos = 70 = 0x46 = EF. At the destination, it should be turned on. Next, we create a stab track (created specifically to control it using applets, rather than binding it tightly to the SLA monitor): Now our task is to remove the results from the SLA monitor and leave track 20 in their values UP state or put it on. This can be done, for example, using Cisco EEM (Embedded Event Manager), which allows you to monitor the current state of your hardware and perform certain actions.
ip sla 33
udp-jitter 172.16.1.66 49333 source-ip 172.16.1.65 codec g729a codec-size 20
tos 70
threshold 10ip sla respondertrack 20 stub-object
default-state upTo do this, create two applets. One will put the track in the Down state if at least one of the parameters (jitter or the number of losses) does not suit us. The second will raise it back if BOTH parameters are normal.
Configuration
1. We create the first applet:
event manager applet LB trapWe create two events based on SNMP OID for RTT and jitter From our SLA-monitor: Here the last digit 33 in SNMP OID is the SLA instance number. 10 - threshold for jitter (in ms), 994 - the minimum allowable number of returned packets out of a thousand sent (1000 - packet_loss). poll-interval - the interval at which the cat polls the state of values. Here 4s. We indicate that our applet should work with ANY of the events, i.e. logical OR is used. Further action:
event tag jitter snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.46.33 get-type exact entry-op ge entry-val "10" entry-type value poll-interval 4
event tag loss snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.1.33 get-type exact entry-op le entry-val "994" entry-type value poll-interval 4trigger
correlate event loss or event jitteraction 20 track set 20 state downThose. our track is in the Down state.
The second applet is similar: Only the applet is triggered by a logical AND between events. And the track is charged up. It can be seen that the survey takes place with an interval of 4 s and the current state of the track is not taken into account, i.e. ladders are triggered constantly, every 4s. I tried to fasten the monitoring of the state of the track itself, but it worked very buggy, it didn’t always work. So I donated a couple of percent and left it like that. In addition, there are applets, informing me about the problems on the channel and their disappearance: and in the variable $ _cli_result contains the result of the output of the last command that in our case, show ip sla stat 33.
event manager applet LB2 trap
event tag jitter snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.46.33 get-type exact entry-op lt entry-val "10" entry-type value poll-interval 4
event tag loss snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.1.33 get-type exact entry-op gt entry-val "994" entry-type value poll-interval 4
trigger
correlate event loss and event jitter
action 20 track set 20 state up
event manager applet LB_info
event syslog pattern "20 stub Up->Down"
action 10 syslog msg "applet works!"
action 11 cli command "enable"
action 12 cli command "show ip sla stat 33"
action 13 mail server "192.168.6.20" to "ilya@tut_domen.ru" from "alert@tut_domen.ru" subject "Frame loss or high jitter on NiS channel" body "$_cli_result"event manager applet LB2_info
event syslog pattern "20 stub Down->Up"
action 10 syslog msg "applet 2 works!"
action 11 cli command "enable"
action 12 cli command "show ip sla stat 33"
action 13 mail server "192.168.6.20" to "ilya@tut_domen.ru" from "alert@tut_domen.ru" subject "NiS channel is correct" body "$_cli_result"In other words, we are sending ourselves a letter, in the body of which is the result of the last launch of the SLA monitor, which actually caused the switching of the track.
So, now actually how to take this into account . I see two ways:
1. a line in the route-map (as it works for me, actually, but it’s just a tricky scheme)
set ip next-hop verify-availability 172.16.1.66 1 track 202. statics tracking, when we have a route of the form
ip route 172.16.0.0 255.255.255.0 192.168.1.1 track 20With losses or jitter on the channel, this route will simply be removed from the table routing and traffic will go on an alternative path.
It may be clumsy, but I tormented myself for a week without thinking anything better. What is rich, as they say.
PS I mean that the reader is a little familiar with the basics of the Cisco
PPS console. The syntax of ip sla commands differs by 12.4T and 12.4, but the meaning is the same.
PPS If clarifications are required that do not go beyond the boundaries of several lines - write, I will add.
Sincerely,
Ilya Podkopaev
_________
UPD : regarding the CPU. In general, under load without applets, I have a router load (ISR 3845) of about 42% on average, with an applet - 43-44.
