Maipu Supported SNMP Traps

Hi , In this section. I will share the information of SNMP traps supported by Maipu Routers. Many times we require traps information for notification and monitoring. 


Maipu Routers support below SNMP traps:

snmp-server start

snmp-server view default 1.0.8802 include

snmp-server view default 1.1.2 include

snmp-server view default 1.3.111 include

snmp-server view default 1.3.6.1 include

snmp-server community public view default ro

snmp-server enable traps alarm

snmp-server enable traps bgp established

snmp-server enable traps bgp backward-transition

snmp-server enable traps frame-relay dlci-status-change

snmp-server enable traps frame-relay pvc-connect-status-change

snmp-server enable traps frame-relay pvc-connect-status-notify

snmp-server enable traps ospf if-authen-failure

snmp-server enable traps ospf virtif-authen-failure

snmp-server enable traps ospf if-config-error

snmp-server enable traps ospf virtif-config-error

snmp-server enable traps ospf if-state-change

snmp-server enable traps ospf virtif-state-change

snmp-server enable traps ospf nbr-state-change

snmp-server enable traps ospf virtnbr-state-change

snmp-server enable traps ospf if-rx-bad-packet

snmp-server enable traps ospf virtif-rx-bad-packet

snmp-server enable traps ospf tx-retransmit

snmp-server enable traps ospf virtif-tx-retransmit

snmp-server enable traps ospf originate-lsa

snmp-server enable traps ospf max-age-lsa

snmp-server enable traps ospf lsdb-approaching-overflow

snmp-server enable traps ospf lsdb-overflow

snmp-server enable traps snmp authentication

snmp-server enable traps snmp coldstart

snmp-server enable traps snmp warmstart

snmp-server enable traps snmp linkdown

snmp-server enable traps snmp linkup

snmp-server enable traps snmp enterprise snmp-agent-up

snmp-server enable traps snmp enterprise snmp-agent-down

snmp-server enable traps snmp enterprise rmon-rising

snmp-server enable traps snmp enterprise rmon-falling

snmp-server enable traps veth remote-status

snmp-server enable traps isis

snmp-server enable traps remote-ping probe-failed

snmp-server enable traps remote-ping test-failed

snmp-server enable traps remote-ping test-complete

snmp-server enable traps port-shutdown

snmp-server enable traps vlan

snmp-server enable traps ip-sla

snmp-server enable traps cellular insert

snmp-server enable traps cellular pullout

snmp-server enable traps cellular pin-invalid

snmp-server enable traps cellular pin-changed

snmp-server enable traps cellular wan-media-change

snmp-server enable traps cellular dial-fail

snmp-server enable traps cellular uim-no-exist

snmp-server enable traps vrf

snmp-server enable traps spanning-tree topology-change

snmp-server enable traps spanning-tree new-root-port

snmp-server enable traps spanning-tree new-root-bridge

You can enable any traps as per your requirements. 

Hope this information will help you in SNMP configuration. 

Thanks for reading...

For any questions, Plz comment with your Name and Mail ID. 

IPSLA - Maipu and Cisco with ICMPEcho

As we discussed in last post about Managed services, Let’s see everything in action with Maipu Routers and Cisco Routers for ICMPEcho. 

In this section, we will see IPSLA - ICMPEcho working flow and  Maipu and Cisco Router configuration example. Which will help us to understand Maipu RTR (IPSLA) for ICMPEcho. Before we see about Maipu IPSLA. Let’s understand some terms related to IPSLA.

SLA Terms

SLA stands for Service Level Agreements; sending the packets of the specified protocol to detect and monitor the network communication.

RTR stands for Response Time Reporter. SLA calculates and outputs the report according to the packet transmission, so it is also called RTR (Response Time Reporter) in Maipu router.

RTR ENTITY -  RTR entity is one common concept; different application detection corresponds with the specified RTR entity. Currently, the RTR entities include MACSLA, ICMPECHO, JITTER, UDPECHO, ICMP-PATH-ECHO, ICMP-PATH-JITTER, and FLOW-STATISTICS. We can monitor above mentioned features using Maipu RTR (IPSLA).

Let’s understand ICMPECHO (IPSLA entity) -

It is the RTR entity that sends the ICMP PING packet to detect the network communication, it help to measure end to end response time between routers. Response time is calculated by measuring the time taken between sending an ICMP Echo request message to the destination and receiving an ICMP Echo reply.

With the rich schedule policies and log recording function, the network administrator can get to know the network communication and history information, as well as it is reducing the work of inputting the common PING commands to check the reachable status of destination device. 

Let’s see a  configuration example for Maipu IPSLA – ICMPEcho

MAIPU ICMPECHO EXAMPLE -

ICMP entity checking network

The configuration of router 1:

Command	Description
router1# configure terminal
router1 (config)# rtr enable	Enable the SLA (RTR) module
router1 (config)# rtr 1 icmpecho	Create the icmpecho entity with ID as 1 and enter the icmpecho configuration mode
router1 (config-rtr-icmpecho)# set 3.3.3.2 5 80 5 5000 extend 3.3.3.1 0 false false	Set the checking attributes of rtr1; the destination address is 3.3.3.2; send five packets in one scheduling; the length of each packet is 80 bytes; the timeout time is 5s; the scheduling interval is 5000s; enable the extend option; the source address is 3.3.3.1; tos field is 0; the DF bit is FALSE; the data parity is FALSE.
router1 (config-rtr-icmpecho)#alarm-type log	Set the alarm type of rtr1 as log, that is, give the user prompt only on shell.
router1 (config-rtr-icmpecho)# periods 2	After two rtr1 entity scheduling, save one history record.
router1 (config-rtr-icmpecho)# number-of-history-kept 200	The number of the history records of rtr1 entity is 200. Note: if exceeding 200, the records cover the old records.
router1 (config-rtr-icmpecho)# threshold-pktLoss 2 direction be	Configure the packet loss threshold of rtr1 entity as 2; in one detection, if the number of the lost packets is larger than 2, give the alarm according to the alarm type configured by the user.
router1 (config-rtr-icmpecho)# threshold-rtt 2 direction be	Configure the come-and-go delay threshold of rtr1 entity as 2; in one detection, if the come-and-go delay is larger than or equal to 2, give the alarm according to the alarm type configured by the user.
router1 (config-rtr-icmpecho)#exit	Exit the configure mode
router1 (config)#rtr schedule 1 entity 1 start now ageout 300 life 700 repeat 3	Initiate schedule 1 to schedule rtr entity 1; start to schedule at once; the ageout is 300s; the life time is 700s; repeat scheduling for three times.

Device used – MP1800

IOS – rp10-i-6.2.8.pck

After the above configuration, router 1 performs the icmpecho check for network communication. After checking, use the command show rtr history to view the checking result.

Execute the command show rtr entitycand show rtr history 1 on router 1

Outputs : 

Router1#show rtr entity 1

--------------------------------------------------------------

ID:1            name:IcmpEcho1          Created:TRUE

****************type:ICMPECHO****************

CreatedTime:THU JAN 01 00:41:53 1970

LatestModifiedTime:THU JAN 01 01:05:39 1970

TargetIp:3.3.3.2

Transmit-packets:1

Totally-send-packets:4

Packet-size:80

Timeout:5(s)

Alarm-type:log

Threshold-of-rtt:2 (direction be)

Threshold-of-pktLoss:2 (direction be)

Number-of-history-kept:200

Periods:2

Extend parameters:

sourceIp:3.3.3.1  tos:0   DF(DON'T FRAG):FALSE    Verify-data:FALSE

In-scheduling:FALSE

Schedule frequency:10(s)

Status:REACHABLE

--------------------------------------------------------------

Router1#show rtr history 1

--------------------------------------------------------------

ID:1    Name:IcmpEcho1  CurHistorySize:10       MaxHistorysize:200

History recorded as following:

THU JAN 01 01:06:18 1970

        Rtt:1(ms)     PktLoss:0

THU JAN 01 01:06:38 1970

        Rtt: 1(ms)     PktLoss:0

THU JAN 01 01:06:58 1970

        Rtt: 2(ms)     PktLoss:0

THU JAN 01 01:07:18 1970

        Rtt: 1(ms)     PktLoss:0

THU JAN 01 01:07:38 1970

        Rtt: 1(ms)     PktLoss:0

THU JAN 01 01:07:58 1970

        Rtt: 2(ms)     PktLoss:0

THU JAN 01 01:08:18 1970

        Rtt: 1(ms)     PktLoss:0

THU JAN 01 01:08:38 1970

        Rtt: 1(ms)     PktLoss:0

THU JAN 01 01:08:58 1970

        Rtt: 1(ms)     PktLoss:0

THU JAN 01 01:09:18 1970

        Rtt: 1(ms)     PktLoss:0

Same time have a look on Maipu command reference  for ICMPEcho–

Command	Description	Configuration Mode
rtr entity-id icmpecho	*Create one icmpecho entity and enter its configuration mode; or enter the configuration mode of one existing entity	config
set {vrf vrf-name targetIp| targetIp}[npackets|CR data-size|CR time-out|CR] [extend sourceIp|CR tos|CR setDF|CR verify-data|CR]	*Configure the checking attributes of the icmpecho entity. vrf-name: The vrf name of the icmpecho entity destination address; targetIp: the destination address of the icmpecho entity; npackets: The number of the ping packets sent during one detection schedule of the icmpecho entity; the default value is 5; data-size: The size of the ping packet sent by the icmpecho entity; the default value is 70bytes; time-out: The timeout of waiting for response after the icmpecho entity sends the packet; extend: The icmpecho entity adds the related extended detection attribute tag; sourceIp: The source address of the icmpecho entity detection; tos: The tod value when the icmpecho entity sends the detection PING packet; setDF: The option when the icmpecho entity sends the detection PING packet, whether to set the DF (DON’T FRAG); verify-data: Whether to verify the data when the icmpecho entity receives the response packet sent from the peer end;	config-rtr-icmpecho

Now Let’s see Cisco IPSLA configuration template –

Device used – Cisco 1841

IOS - c1841-advsecurityk9-mz[1].124-12c.bin

Configuration Template -

ip sla monitor 1

 type echo protocol ipIcmpEcho 4.2.2.2 source-ipaddr 203.123.140.68

exit

ip sla monitor schedule 1 life forever start-time now ageout 6000

Show Commands

show ip sla monitor collection-statistics

show ip sla monitor configuration

Another test –

IOS - 12.2(31)SB2  and 12.2(33)SRB1 

Configuration Template -

ip sla 1

 icmp-echo 192.168.1.2 source-ip 172.16.1.2

 frequency 300

 request-data-size 28

 timeout 2000

ip sla schedule 6 life forever start-time now

In this post I tried to provide details about Cisco IPSLA and Maipu IPSLA , majorly about ICMPEcho.

You can check the show output in routers and all network devices. But majorly the output from IPSLA configuration is used by NMS to generate various reports.

Hope this post will help you to understand more about  Maipu IPSLA  and Cisco IPSLA.

For likes and any queries, Plz put comment with your mail id…

Your comments will help me to improve my posts…

Managed Services using SNMP

As nowadays in India Every ISP is talking about Manage services, What exactly is manage services ? Which protocol is responsible for this.  How any one do this ? In this section we will discuss about all this...

ISP are the service providers which offers many interactive services to customers, Customers stands for any enterprises or any Big companies in any domain. Every customer  has their own domain and business, as they have huge presence for own business. To manage this, they take links from service providers. But if sometime the links goes down or if they want to check the link quality / utilization. For all this information, they need to maintain own network team to do it and using any NMS. 

                           

NMS stands for Network Monitoring system. This system will monitor your whole network (Initially you need to configure and setup) as per your requirement.This will provide you interactive reports about Link availability/ Utilization/ etc   , But to maintain all this. It will some cost which is incurred by customers. Now ISP’s are offering these services along with link.

                ISP will monitor everything for customer, as per requirement and provide report to customer. Which will help customer to focus on own business and to avoid resources for this work.

Till now we had discussed, how real time market is accepting Manage services .. Let’s see technically what is manage services how this works...

SNMP is very important protocol for this service. Let’s see what is SNMP

SNMP means Simple Network Management Protocol. For better understanding we can divide it into 3 components –

Managed devices

Agents

Network Management System/Network Monitoring System (NMS)

  A managed device is a node that will have a SNMP agent installed or configured or it will support SNMP protocol, which needs to be enabled for this operations. The network devices can be Routers, Switches, etc.  An agent is software process/module with in network device. This provides SNMP information to NMS.

                Then major job of SNMP agent is collect all the required information from network device and send it to NMS in suitable format. This is only possible by SNMP. The NMS is application; It will process the received data from SNMP and provide interactive reports to Users.

But to get detailed information about any network device we should have MIB for that device.

Let’s see something about MIB:

MIB means  Management Information Base. It is a collection of information of network device organized hierarchically. MIB is used to manage a network device remotely with full flexibility. It will help you to provide more information about the device functionality and real time information.

This information is accessed using a SNMP protocol.

OIDs means Object Identifiers. It is used uniquely to identify and managed objects in a MIB hierarchy. We can say, MIB is collection of OID(information) for device, which will help SNMP protocol to get particular information in detail from concern network device. As you check the OIDs in MIB, you can see detail description of that OID in MIB. It will help you to know more about that OID. Every vendor has own MIBs to manage own products.

How this works  –

SNMP works with NMS. NMS send out a request to managed devices , in return a it will receive a response message. In this 4 steps are involved – Get, GerNext, Set and Trap. SNMP header consists of a header and PDU (protocol Dataunits). In that header it will contain – SNMP version information and community string. The community name is used for security reasons, To access data from network device community name should match.

The PDU depends on the type of message that is being sent. The Get, GetNext, and Set, as well as the response PDU, consist of PDU type, Request ID, Error status, Error index and Object/variable fields. The Trap consist of Enterprise, Agent, Agent address, Generic trap type, Specific trap code, Timestamp and Object/Value fields.

After collection of all information NMS process the received data and provide customized reports.

SNMP is very important for Managed services .

Some well known NMS –

Orion Solarwinds

Manage Engine Netflow

CA – Ehealth

IPSwitch – WhatsupGold

HP Openview

IBM – Tivoli

Hope this information is useful for you. For likes and any queries, Plz comment with your mail id...

Maipu - SNMP Configuration

In this section, we will see how to enable Maipu router for SNMP configuration. It will enable Maipu devices (Router/Switch) to monitor (Poll) remotely.  This configuration will enable Maipu router to send traps to NMS server.

Let’s see about SNMP, SNMP (Simple Network Management Protocol) is a standard protocol to manage network remotely and collect the information.  SNMP is responsible to send all information to NMS server from Network devices ( Router/Switch).

                After this NMS server will generate the reports as per user requirements.

 Let’s see, how to start SNMP service on Maipu Router. By default it is stopped.

 Configuration Template :

snmp-server start

snmp-server view default 1.3.6.1 include

snmp-server community public view default ro

after this configuration you can discover Maipu router, If you want to monitor Maipu router for manage services. Then you need to integrate Maipu MIBs in your NMS.

Basic Commands:

To activate the SNMP network-

• snmp-server start 

To set the SNMP community -

• snmp-server community - community-name [view viewname] {ro | rw} [access-list] -  name

To enable SNMP traps -

• snmp-server enable traps snmp [authentication |coldstart | warmstart | linkup

| linkdown | [enterprise [rmon-falling | rmon-rising |snmp-agent-up | snmp-agentdown

] ] ]

 To set the network management view -

• snmp-server view view-name oid-string {include|exclude}'

To enable collection of data for CPU Utilization - 

• check cpu enable 

Hope this information will help you..

If you like the post and for any queries, Plz put comment with your mail id...