Summary:
For ISP network engineers implementing QOS policy for rate limiting. That is metering and policing.
This will help you in determining the proper burst size; Normal burst (in bytes) or Extended Burst (in bytes). The higher the burst size, the better the quality of experience for your subscribers when the configured bandwidth is over-utilized.
This calculation is based on a formula provided by CISCO.
Credits: Brian
Problem or Goal:
Burst-size limit is very important while implementing QOS policy
A policer burst-size limit controls the number of bytes of traffic that can pass unrestricted through a policed interface when a burst of traffic pushes the average transmit or receive rate above the configured bandwidth limit. The actual number of bytes of bursty traffic allowed to pass through a policed interface can vary from zero to the configured burst-size limit, depending on the overall traffic load.
Cause:
Setting burst size helps to alleviate the aggressive bandwidth shaping caused by rate limiting configurations.
Solution:
Download Burst Size Calculator here
Download from my dropbox here
Problem Solved?
Yes
“It has become appallingly obvious that our technology has exceeded our humanity.” Albert Einstein
Showing posts with label ip. Show all posts
Showing posts with label ip. Show all posts
Thursday, February 15, 2018
Monday, August 14, 2017
Accton Edge Core Switch - CPU Utilization reaching 100% Causing Latency, Packet Loss and Jitter
Summary:
High CPU utilization on Accton Edge Core switch
Problem or Goal:
SW01-0#show process cpu
Process Name 5Sec(%%) 1Min(%%) 5Min(%%) 15Min(%%) Runtime(ms)
tRootTask 0.00 0.00 0.00 0.00 0
tExcTask 0.00 0.00 0.00 0.00 4450
tLogTask 0.00 0.00 0.00 0.00 0
bcmDPC 0.00 0.00 0.00 0.00 0
bcmCNTR.0 1.20 0.97 0.88 0.86 403860440
bcmTX 0.20 0.08 0.01 0.03 38288910
bcmXGS3AsyncTX 0.00 0.00 0.00 0.00 0
bcmCNTR.1 0.20 0.77 0.64 0.65 384888780
bcmLINK.0 0.20 0.25 0.30 0.44 207997140
bcmLINK.1 0.60 0.20 0.27 0.40 205123250
bcmRX 3.20 2.77 2.41 2.33 932885260
ipnetd 9.20 4.05 1.37 0.63 150098590
SYS_TIMER 0.00 0.00 0.00 0.00 30
TASK_MON 0.00 0.00 0.01 0.02 13190510
TPLG 0.00 0.00 0.00 0.00 2905040
STACK_CTRL 0.00 0.00 0.00 0.00 0
SWDRV_CACHE_TASK 0.00 0.00 0.00 0.00 570
SWDRV 11.60 12.60 12.57 12.51 2450845024
AMTRDRV_TASK 7.40 9.42 9.91 8.46 437234870
SWDRVL3_CACHE 0.00 0.00 0.00 0.00 723040
BSTM 2.40 2.40 2.21 2.18 867314220
ISC 0.00 0.00 0.00 0.00 772490
ISC_CALLBACK 0.00 0.00 0.00 0.00 458880
ISC_LOW_PRIORITY_CALLBACK 0.00 0.00 0.00 0.00 0
FS 0.00 0.00 0.00 0.00 0
SYSDRV 21.60 21.87 19.88 16.61 394608318
SWCTRL 0.00 0.00 0.00 0.00 1075650
NMTR 0.00 0.00 0.00 0.00 435680
LACP 0.00 0.02 0.03 0.04 39156480
AMTRL3 0.00 0.00 0.00 0.00 2383260
STA 4.80 6.15 6.22 6.26 3519756390
VLAN 0.00 0.00 0.00 0.00 109550
GARP 0.00 0.00 0.00 0.00 0
IGMP 0.60 1.25 1.15 1.24 436226180
RADIUS 0.00 0.00 0.00 0.00 0
DOT1X 0.00 0.02 0.00 0.00 383180
IMTR 0.00 0.05 0.04 0.05 24671280
IML_TASK 0.40 0.25 0.15 0.15 67940540
P2IP 2.20 1.37 1.21 1.26 583185760
VRRP 0.40 0.15 0.11 0.13 46062760
zNCFG 0.00 0.00 0.00 0.00 0
zNSM 0.00 0.00 0.00 0.00 17161360
zOSPF 0.00 0.00 0.00 0.00 100
zRIP 0.00 0.00 0.00 0.00 15570
SYSLOG 0.00 0.00 0.00 0.00 615010
SMTP 0.00 0.00 0.00 0.00 70630
DNS_RES 0.00 0.00 0.00 0.00 4623530
DNS_PROXY 0.00 0.00 0.00 0.01 4722020
KEYGEN 0.00 0.00 0.00 0.00 678350
HTTP 0.00 0.00 0.00 0.00 681710
TELNET_S 0.00 0.00 0.00 0.00 730
TELNET_D 0.00 0.00 0.00 0.00 469450
DNLD 0.00 0.00 0.00 0.00 0
FXFER 0.00 0.00 0.00 0.00 76520
DHCP 0.00 0.00 0.00 0.00 5536000
SNTP 0.00 0.00 0.00 0.00 1277890
SSHD_MAIN 0.00 0.02 0.01 0.01 4395100
LLDP 0.00 2.48 2.18 1.88 1093983890
SNMP 46.60 8.44 12.15 21.13 500340188
CLITASK0 0.00 0.00 0.01 0.02 11541680
KICK_NET 0.00 0.00 0.00 0.00 2170
TN12 1.00 1.44 0.37 0.12 1080
UI37 1.20 1.04 0.34 0.11 980
UI08 0.00 0.00 0.00 0.00 30770
===========================================================================
total = 100.00 78.06 74.43 77.53
SW01-0#show snmp
System Contact:
System Location:
SNMP Agent: enabled
SNMP traps:
Authentication: enabled
Link-up-down: enabled
Cause:
SNMP agent seems to be using most of the CPU resources.
Solution:
Disable the SNMP agent
SW01-0#configure
SW01-0(config)#no snmp-server ?
community Defines SNMP community access string
contact Sets the system contact string
enable Enables this device to send SNMP traps
engine-id Configure engine-id
group Configure group name
host Specifies SNMP notification operation recipients
location Sets the system location string
user Configure user name
view Configure view name
<cr>
SW01-0(config)#no snmp-server
SW01-0(config)#end
SW01-0#show snmp
System Contact:
System Location:
SNMP Agent: disabled
SNMP traps:
Authentication: enabled
Link-up-down: enabled
Yes
SW01-0#show process cpu
Process Name 5Sec(%%) 1Min(%%) 5Min(%%) 15Min(%%) Runtime(ms)
tRootTask 0.00 0.00 0.00 0.00 0
tExcTask 0.00 0.00 0.00 0.00 4450
tLogTask 0.00 0.00 0.00 0.00 0
bcmDPC 0.00 0.00 0.00 0.00 0
bcmCNTR.0 1.00 1.00 0.84 0.77 403865160
bcmTX 0.00 0.00 0.02 0.01 38289030
bcmXGS3AsyncTX 0.00 0.00 0.00 0.00 0
bcmCNTR.1 0.60 0.70 0.74 0.72 384893630
bcmLINK.0 0.20 0.10 0.12 0.30 207999140
bcmLINK.1 0.00 0.00 0.13 0.27 205125060
bcmRX 2.20 2.20 2.46 2.33 932899850
ipnetd 4.40 2.20 2.26 1.81 150110680
SYS_TIMER 0.00 0.00 0.00 0.00 30
TASK_MON 0.00 0.00 0.00 0.02 13190640
TPLG 0.00 0.00 0.00 0.00 2905080
STACK_CTRL 0.00 0.00 0.00 0.00 0
SWDRV_CACHE_TASK 0.00 0.00 0.00 0.00 570
SWDRV 13.60 13.00 12.80 12.67 2450925764
AMTRDRV_TASK 11.20 9.80 11.48 9.72 437295640
SWDRVL3_CACHE 0.00 0.00 0.00 0.00 723070
BSTM 1.80 2.10 2.35 2.24 867328350
ISC 0.00 0.00 0.00 0.00 772500
ISC_CALLBACK 0.00 0.00 0.00 0.00 458880
ISC_LOW_PRIORITY_CALLBACK 0.00 0.00 0.00 0.00 0
FS 0.00 0.00 0.00 0.00 0
SYSDRV 21.60 22.40 22.29 19.06 394725708
SWCTRL 0.00 0.00 0.00 0.00 1075650
NMTR 0.00 0.00 0.00 0.00 435690
LACP 0.00 0.00 0.02 0.05 39156940
AMTRL3 0.00 0.00 0.00 0.00 2383270
STA 7.20 6.66 6.30 6.26 3519796310
VLAN 0.00 0.00 0.00 0.00 109550
GARP 0.00 0.00 0.00 0.00 0
IGMP 1.60 1.86 1.34 1.26 436234430
RADIUS 0.00 0.00 0.00 0.00 0
DOT1X 0.00 0.00 0.00 0.00 383180
IMTR 0.00 0.00 0.03 0.04 24671570
IML_TASK 0.00 0.26 0.22 0.18 67941810
P2IP 3.80 2.80 1.80 1.49 583195950
VRRP 0.00 0.00 0.15 0.14 46063700
zNCFG 0.00 0.00 0.00 0.00 0
zNSM 0.00 0.00 0.00 0.00 17161360
zOSPF 0.00 0.00 0.00 0.00 100
zRIP 0.00 0.00 0.00 0.00 15570
SYSLOG 0.00 0.00 0.00 0.00 615010
SMTP 0.00 0.00 0.00 0.00 70630
DNS_RES 0.00 0.00 0.01 0.00 4623600
DNS_PROXY 0.00 0.00 0.00 0.00 4722040
KEYGEN 0.00 0.00 0.00 0.00 678360
HTTP 0.00 0.00 0.00 0.00 681710
TELNET_S 0.00 0.00 0.00 0.00 730
TELNET_D 0.00 0.00 0.00 0.00 469450
DNLD 0.00 0.00 0.00 0.00 0
FXFER 0.00 0.00 0.00 0.00 76520
DHCP 0.00 0.00 0.00 0.00 5536020
SNTP 0.00 0.00 0.00 0.00 1277890
SSHD_MAIN 0.00 0.06 0.00 0.01 4395160
LLDP 0.20 0.06 2.01 1.99 1093996020
SNMP 0.00 0.00 1.36 11.84 500418668
CLITASK0 0.00 0.00 0.01 0.02 11541830
KICK_NET 0.00 0.00 0.00 0.00 2170
TN12 4.20 1.66 0.72 0.50 4290
UI37 3.20 1.53 0.71 0.47 4100
UI08 0.00 0.00 0.00 0.00 30770
===========================================================================
total = 76.80 68.39 70.17 74.17
SW01-0#
Saturday, April 8, 2017
What are bogon routes & why should they be a concern to ISP network admins?
What are
bogon routes?
Bogons are martians
(private and reserved addresses defined by RFC1918, RFC5735 and RFC 6598) and net
blocks that have been allocated to a regional internet registry (RIR) by the
internet assigned numbers authority (IANA).
A bogon
prefix is a route that should never appear in the internet routing table
therefore packets routed over the public internet with a source address in a
bogon range should be discarded.
Why should
bogon prefixes be a concern to ISP network administrators?
Bogons are
used by malicious internet users and hackers to launch DDoS attacks and IP
address spoofing. In fact, most of the frequently attacked sites, 60% of the
naughty packets were obvious bogons.
What should
you do as an ISP network administrator to guard your network against bogons?
You need to
filter and reject or discard bogon routes at your BGP edge router so they don’t
enter your routing table as valid destinations. Filtering should be done on
both the ingress and egress direction because similarly you don’t want to
advertise bogon prefixes to your upstream provider.
However, if
you choose to filter bogons you need to have a plan to keep your filters update
because these lists change every day especially the full bogon list which has
significant changes every day.
Bogon
filtering is good and a wise decision but you have to be committed to
maintaining it every day, if you just download a full bogons list once and use
it to filter at your BGP router without updating it, it will become out of date
very quickly and you will end up blocking legitimate traffic.
A good idea
is to peer with bogon route servers, it’s a free service and you can apply here.
In this way, your bogon prefixes will be automatically
updated. Any changes in the full bogon prefixes will immediately be reflected
in your BGP router which saves you from what would otherwise be a rigorous
daily routine of downloading and updating your full bogon lists.
Credits: TEAM CYMRU
Thursday, January 21, 2016
Call Setup Failure "SIPoverIPsec" INVITE Message dropped at Tunnel Entrance
[Note: this is a draft]
We have for over one month been battling a major integration issue with one of our roaming partners.
This was a SIP integration and the idea was to send the signaling traffic over IPsec and the media traffic over public internet.
We hit a sag with the call setup after setting up the SIP trunk and when we took a trace, we realized that the INVITE message was being dropped by the firewall:
Model: srx240h2
JUNOS Software Release [12.1X46-D35.1]
Problem:
SIP over IPsec, call setup failure
Some Important Symptoms:
1. On the handset you would get the announcement; "The person you are calling is not answering"
2. Wireshark trace shows the INVITE message leaving the MSS
3. When you bypass the IPsec tunnel, call setup is successful
4. Firewall flow sessions show one way traffic
5. INVITE request is not received at the tunnel end point
6. SIP OPTIONS messages were OK and received well both ways
7. ICMP ping was OK
Today we had a major breakthrough regarding this issue, we were finally able to place a successful call through this SIP trunk.
Problem Cause:
The Packet size for the INVITE message from our MSS was abnormally big and had a DF bit set.
i would want to mention that our setup is kind of special, i will not dive into the details of our core network setup but what i can say is we are majorly a 4G (TDD) network with CSFB voice/sms/2g/3g services to a national roaming partner. so the SIP INVITE message is actually originated by our CSFB partner MSS and not our MSS.
Our MSS only acts as a proxy and relays the INVITE message to wherever it's supposed to go, which in this case was to our international roaming partner through this SIP trunk that we had setup over IPsec.
My reasoning to why the packet size was abnormally big, is that our MSS adds a layer of information onto the original packet making it bigger. for now i will not dive into the detailed analysis but i would be happy to share the knowledge in case you are interested (we can use the comment box below this article to carry on the discussion).
Solution:
Add this line of configuration to your VPN
set security ipsec vpn SIP_VPN df-bit copy
The default behavior of DF-bit, when the traffic goes to the IPSec tunnel, is to not change the DF-bit of the inner IP header and clear the DF-bit flag on the outer IP header. For more details on what this line of configuration does, please follow this link.
Results:
Call setup was successful and we were able to place a call through SIP over IPsec.
Thursday, December 17, 2015
Friday, November 13, 2015
Connected a firewall (SRX240) but i can't ping the Point to Point Interfaces
Problem:
Just completed connecting a firewall (SRX 240) to a switch.
The link is supposed to be a trunk carrying multiple VLANs, however, i couldn't ping the Point-to-Point IPs from the switch or the firewall yet the interfaces are UP.
Example Config:
On the Firewall:
set interfaces ge-0/0/13 description my_test_link
set interfaces ge-0/0/13 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/13 unit 0 family ethernet-switching vlan members TEST
set interfaces vlan unit 590 description my_test_vlan
set interfaces vlan unit 590 family inet address 10.0.90.5/30
set vlans TEST vlan-id 590
set vlans TEST l3-interface vlan.590
On the switch:
set interfaces ge-0/0/16 description my_test_link
set interfaces ge-0/0/16 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/16 unit 0 family ethernet-switching vlan members 590
set interfaces vlan unit 590 description my_test_vlan
set interfaces vlan unit 590 family inet address 10.0.90.6/30
set vlans TEST vlan-id 590
set vlans TEST l3-interface vlan.590
Normally, this would be enough to bring UP the point-to-point if this were a switch to switch connection. But because the default firewall behavoiur is to block all traffic, trying to ping the firewall interfaces from the switch or vice versa will fail.
solution:
Add this config
set security zones security-zone trust interfaces vlan.590
set security zones security-zone trust interfaces vlan.590 host-inbound-traffic system-services all
set security zones security-zone trust interfaces vlan.590 host-inbound-traffic protocols all
what this additional config does is to put the interface in a security zone and permit inbound traffic to that interface.
Just completed connecting a firewall (SRX 240) to a switch.
The link is supposed to be a trunk carrying multiple VLANs, however, i couldn't ping the Point-to-Point IPs from the switch or the firewall yet the interfaces are UP.
Example Config:
On the Firewall:
set interfaces ge-0/0/13 description my_test_link
set interfaces ge-0/0/13 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/13 unit 0 family ethernet-switching vlan members TEST
set interfaces vlan unit 590 description my_test_vlan
set interfaces vlan unit 590 family inet address 10.0.90.5/30
set vlans TEST vlan-id 590
set vlans TEST l3-interface vlan.590
On the switch:
set interfaces ge-0/0/16 description my_test_link
set interfaces ge-0/0/16 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/16 unit 0 family ethernet-switching vlan members 590
set interfaces vlan unit 590 description my_test_vlan
set interfaces vlan unit 590 family inet address 10.0.90.6/30
set vlans TEST vlan-id 590
set vlans TEST l3-interface vlan.590
Normally, this would be enough to bring UP the point-to-point if this were a switch to switch connection. But because the default firewall behavoiur is to block all traffic, trying to ping the firewall interfaces from the switch or vice versa will fail.
solution:
Add this config
set security zones security-zone trust interfaces vlan.590
set security zones security-zone trust interfaces vlan.590 host-inbound-traffic system-services all
set security zones security-zone trust interfaces vlan.590 host-inbound-traffic protocols all
what this additional config does is to put the interface in a security zone and permit inbound traffic to that interface.
Subscribe to:
Posts (Atom)