Monday , September 16 2024

routing policy configuration

Some time ago I wrote about local PBR and interface PBR.

It’s time to talk about routing policy, that is a different mechanism. Routing policy is applied to routing information and it is combined with routing protocols to form policies. PBR mechanism is applied to data flows and and packets are forwarded according to the configured policy.

Routing policy is a tool which can be used to filter routes and set route attributes, when importing routing information into OSPF, RIP, ISIS or BGP protocols. BGP can use routing policy to filter advertising routes as well. Routing policy defines which of the routes from the specific routing protocol are allowed to be imported into the target routing protocol. It can be also used to match routes or certain route attributes and to change these attributes when the matching rules are met.

Routing policy command syntax:
route-policy route-policy-name { permit | deny } node node

A route-policy may consists of multiple nodes, for example:

route-policy LABNARIO-POLICY permit node 10
route-policy LABNARIO-POLICY deny node 20

The relationship between the nodes of a route-policy is „OR”. This means that if a route matches the node 10 command, the route will not be matched against the node 20. If a route does not match any node, the route fails to match the route-policy. If two nodes are configured, a route is first matched with the node 10 command.

A node in a route-policy can use:

  • permit parameter – If a route matches the node, the router performs actions defined by the apply clauses and the matching is complete. Otherwise, the route continues to match the next node.
  • deny parameter – in this mode the apply clauses are not used. If a route entry matches all the if-match clauses of the node, the route is denied by the node and the next node is not matched. If the entry does not match all the clauses, the next node is matched.

It is important to note that:

  • by default, routes that are unmatched by the nodes, will be denied
  • if multiple nodes are defined, at least one of them should use permit parameter
  • if all the nodes are in deny mode, all the routes will be denied by the route-policy
  • if no if-match clause is defined, all the routes meet the matching rules

Each node can be classified into the following clauses:

  • if-match – match certain route attributes
  • apply – set certain route attributes

The relationship between the if-match clauses is “AND”. This means that a route must match all the if-match clauses.

If-match clauses can match the following:

acl                  Specify an ACL
as-path-filter       BGP AS path list
community-filter     Match BGP community filter
cost                 Match metric of route
extcommunity-filter  Match BGP/VPN extended community filter
interface            Specify the interface matching the first hop of routes
ip                   IP information
  group-address 		Match group address of route
  next-hop      		Match next-hop address of route
  route-source  		Match advertising source address of route
ip-prefix            Specify an address prefix-list
ipv6                 IPv6 Information
  group-address 		Match group address of route
  next-hop      		Match next-hop address of route
  route-source  		Match advertising source address of route
mpls-label           Give the Label
rd-filter            Route-distinguisher filter
route-type           Match route-type of route
  external-type1       OSPF External Type 1 routes
  external-type1or2    OSPF External routes (OSPF type 1/2)
  external-type2       OSPF External Type 2 routes
  internal             Internal route (including OSPF intra/inter area)
  is-is-level-1        IS-IS Level-1 routes
  is-is-level-2        IS-IS Level-2 routes
  nssa-external-type1  OSPF NSSA External Type1 routes
  nssa-external-type1or2  OSPF NSSA External Type1 and Type2 routes
  nssa-external-type2  OSPF NSSA External Type2 routes
tag                  Match tag of route

Apply clauses can set the following:

[Labnario-route-policy]apply ?
  as-path           BGP AS path list
  backup-interface  Backup outgoing interface
  backup-nexthop    Backup nexthop address
  behavior          Specify QoS policy as behavior
  comm-filter       Set BGP community filter (for deletion)
  community         BGP community attribute
  cost              Set metric of route
  cost-type         Type of metric for destination routing protocol
    external   IS-IS external metric
    internal   IS-IS internal metric/Set BGP MED to IGP metric of nexthop
    type-1     OSPF External Type 1 routes
    type-2     OSPF External Type 2 routes
  dampening         Set BGP route flap dampening parameters
  extcommunity      Set BGP/VPN extended community filter
  ip-address        IP information
    next-hop   Next hop address
  ip-precedence     Specify QoS policy as IP precedence
  ipv6              IPv6 Information
    next-hop   Next hop address
  isis              Where to import route
    level-1    Import into a level-1 area
    level-1-2  Import into level-1 and level-2
    level-2    Import into level-2 sub-domain
  local-preference  BGP local preference path attribute
  mpls-label        Give the Label
  origin            BGP origin code
    egp        Remote EGP
    igp        Local IGP
    incomplete Unknown heritage
  ospf              Where to import route
    backbone   Import into OSPF backbone area
    stub-area  Import into OSPF NSSA area  
  preference        Give the Preference  (Route Preference)
  preferred-value   BGP Preferred-value (weight) for routing table
  qos-local-id      Specify QoS policy as qos local id
  tag               Set tag of route
  traffic-index     Specify BGP Traffic Accounting Index

Examples:

Configure a route-policy to import into OSPF:

  • routes tagged with a value of 100
  • routes tagged with a value of 200
  • set them a tag 300
  • block any other routes

Configure a route-policy to import into RIP:

  • All the OSPF routes except the prefix 120.10.1.0/24, if it comes from the source of 150.100.1.5

routing policy

Config should be done on AR1 router, as this is a boundary router between OSPF and RIP domains:

#
route-policy RIP-2-OSPF permit node 10 
 if-match tag 100
 apply tag 300
#
route-policy RIP-2-OSPF permit node 20 
 if-match tag 200
 apply tag 300
#
ospf 1
 import-route rip 1 route-policy RIP-2-OSPF

#
route-policy OSPF-2-RIP deny node 10 
 if-match ip-prefix PREFIX1 
 if-match ip route-source acl 2001 
#
route-policy OSPF-2-RIP permit node 20 
#
ip ip-prefix PREFIX1 index 10 permit 120.10.1.0 24
#
acl number 2001
 rule 10 permit source 150.100.1.5 0 
#
rip 1
 import-route ospf 1 route-policy OSPF-2-RIP

Read More »

VPN FRR on Huawei routers

Last time IP FRR on Huawei routers was introduced. Let’s go on with VPN FRR today.

VPN FRR topology

 

  1. Configure IP addresses based on the topology (omitted)
  2. Configure ISIS on PE1, PE2 and PE3.
  3. Configure MPLS function on all PE routers and enable MPLS LDP to set up an LSP.
  4. Configure VPN instance on all PE devices.
  5. Configure MP-IBGP between PE routers.
  6. Configure EBGP between CE and PE2/PE3 routers.
  7. Configure VPN FRR policy on PE1.
  8. Configure BFD session between PE1 and PE2.

Configure ISIS and MPLS globally and on interfaces (PE1 as an example):

[PE1]isis
[PE1-isis-1]is-level level-2
[PE1-isis-1]network-entity 10.0010.0100.1001.00
[PE1-isis-1]
[PE1]mpls
[PE1-mpls]quit
[PE1]mpls ldp
[PE1-mpls-ldp]

[PE1]interface GigabitEthernet0/0/1
[PE1-GigabitEthernet0/0/1]isis enable
[PE1-GigabitEthernet0/0/1]mpls
[PE1-GigabitEthernet0/0/1] mpls ldp
[PE1-GigabitEthernet0/0/1]quit
[PE1]interface GigabitEthernet0/0/2
[PE1-GigabitEthernet0/0/2]isis enable
[PE1-GigabitEthernet0/0/2]mpls
[PE1-GigabitEthernet0/0/2] mpls ldp
[PE1-GigabitEthernet0/0/2]quit
[PE1]interface LoopBack0
[PE1-LoopBack0]isis enable

[PE1]dis isis peer
                          Peer information for ISIS(1)
  System Id     Interface          Circuit Id       State HoldTime Type     PRI
-------------------------------------------------------------------------------
0020.0200.2002  GE0/0/1            0020.0200.2002.01 Up   7s       L2       64 
0030.0300.3003  GE0/0/2            0030.0300.3003.01 Up   8s       L2       64 
Total Peer(s): 2

[PE1]dis mpls ldp peer
 LDP Peer Information in Public network
 A '*' before a peer means the peer is being deleted.
 ------------------------------------------------------------------------------
 PeerID                 TransportAddress   DiscoverySource
 ------------------------------------------------------------------------------
 2.2.2.2:0              2.2.2.2            GigabitEthernet0/0/1
 3.3.3.3:0              3.3.3.3            GigabitEthernet0/0/2
 ------------------------------------------------------------------------------
 TOTAL: 2 Peer(s) Found.

Configure VPN instance on all PE devices (PE1 as an example):

[PE1]ip vpn-instance labnario
[PE1-vpn-instance-labnario]route-distinguisher 200:1
[PE1-vpn-instance-labnario]vpn-target 200:200 both

Configure MP-IBGP between PE routers (PE1 as an example):

[PE1]bgp 200
[PE1-bgp]peer 2.2.2.2 as-number 200 
[PE1-bgp] peer 2.2.2.2 connect-interface LoopBack0
[PE1-bgp] peer 3.3.3.3 as-number 200 
[PE1-bgp] peer 3.3.3.3 connect-interface LoopBack0
[PE1-bgp]ipv4-family vpnv4
[PE1-bgp-af-vpnv4]policy vpn-target
[PE1-bgp-af-vpnv4]peer 2.2.2.2 enable
[PE1-bgp-af-vpnv4]peer 3.3.3.3 enable

[PE1]dis bgp vpnv4 all peer
 BGP local router ID : 10.0.0.2
 Local AS number : 200
 Total number of peers : 2		  Peers in established state : 2
  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State Pref Rcv

  2.2.2.2         4         200       20       19     0 00:15:03 Established     4
  3.3.3.3         4         200       20       18     0 00:15:17 Established     4

Configure EBGP between CE and PE2/PE3 routers:

[PE2]bgp 200
[PE2-bgp]ipv4-family vpn-instance labnario
[PE2-bgp-labnario]peer 200.0.0.1 as-number 65001
[PE2-bgp-labnario]import-route direct

[PE3]bgp 200
[PE3-bgp]ipv4-family vpn-instance labnario
[PE3-bgp-labnario]peer 200.0.1.1 as-number 65001
[PE3-bgp-labnario]import-route direct

[CE]bgp 65001
[CE-bgp]peer 200.0.0.2 as-number 200 
[CE-bgp] peer 200.0.1.2 as-number 200 
[CE-bgp]import-route direct

[CE]dis bgp peer
 BGP local router ID : 200.0.0.1
 Local AS number : 65001
 Total number of peers : 2		  Peers in established state : 2
  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State Pref Rcv

  200.0.0.2       4         200       26       31     0 00:22:35 Established     2
  200.0.1.2       4         200       26       31     0 00:22:35 Established     2

Let’s check IP routing table on PE1 router:

[PE1]dis ip rout vpn-instance labnario
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: labnario
         Destinations : 6        Routes : 6        

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

        4.4.4.4/32  IBGP    255  0          RD   2.2.2.2         GigabitEthernet0/0/1
   172.16.10.10/32  IBGP    255  0          RD   2.2.2.2         GigabitEthernet0/0/1
      200.0.0.0/24  IBGP    255  0          RD   2.2.2.2         GigabitEthernet0/0/1
      200.0.1.0/24  IBGP    255  0          RD   3.3.3.3         GigabitEthernet0/0/2
255.255.255.255/32  Direct  0    0           D   127.0.0.1       InLoopBack0

As we can see, a network 172.16.10.10/32, advertised by CE router, is available on PE1 in VPN instance labnario, with next hop 2.2.2.2 (PE2).

[PE1]dis ip routing-table vpn-instance labnario 172.16.10.10 verbose 
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : labnario
Summary Count : 1

Destination: 172.16.10.10/32
     Protocol: IBGP             Process ID: 0
   Preference: 255                    Cost: 0
      NextHop: 2.2.2.2           Neighbour: 2.2.2.2
        State: Active Adv Relied       Age: 00h00m43s
          Tag: 0                  Priority: low
        Label: 1026                QoSInfo: 0x0
   IndirectID: 0x6              
 RelayNextHop: 10.0.0.1          Interface: GigabitEthernet0/0/1
     TunnelID: 0x1                   Flags: RD

Based on the traditional BGP/MPLS VPN technology, both PE2 and PE3 advertise the routes destined for CE to PE1, and allocate private network labels. PE1 then selects a VPNv4 route from MP-BGP neighbors according to the policy. The preferred route, in this example, is the one advertised by PE2.

In case of a fault occurs on PE2, PE1 detects the fault of PE2, re-selects the route advertised by PE3, and updates the forwarding entry. This results in the interruption of end-to-end services due to long convergence time.

Configure VPN FRR policy:

[PE1]ip ip-prefix vpn_frr index 10 permit 2.2.2.2 32

[PE1]route-policy vpn_frr permit node 10 
Info: New Sequence of this List.
[PE1-route-policy] if-match ip next-hop ip-prefix vpn_frr 
[PE1-route-policy] apply backup-nexthop 3.3.3.3

Enable VPN FRR:

[PE1]ip vpn-instance labnario
[PE1-vpn-instance-labnario]vpn frr route-policy vpn_frr

Configure BFD multi-hop detection between PE1 and PE2 (PE1 as an example):

[PE1]bfd to_pe2 bind peer-ip 2.2.2.2
[PE1-bfd-session-to_pe2] discriminator local 100
[PE1-bfd-session-to_pe2] discriminator remote 200
[PE1-bfd-session-to_pe2] commit

[PE1]dis bfd session all
--------------------------------------------------------------------------------
Local Remote     PeerIpAddr      State     Type        InterfaceName            
--------------------------------------------------------------------------------
100   200        2.2.2.2         Up        S_IP_PEER         -                  
--------------------------------------------------------------------------------
     Total UP/DOWN Session Number : 1/0

Let’s check IP routing table in VRF once again:

[PE1]dis ip routing-table vpn-instance labnario 172.16.10.10 verbose 
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : labnario
Summary Count : 1

Destination: 172.16.10.10/32
     Protocol: IBGP             Process ID: 0
   Preference: 255                    Cost: 0
      NextHop: 2.2.2.2           Neighbour: 2.2.2.2
        State: Active Adv Relied       Age: 00h05m54s
          Tag: 0                  Priority: low
        Label: 1026                QoSInfo: 0x0
   IndirectID: 0x6              
 RelayNextHop: 10.0.0.1          Interface: GigabitEthernet0/0/1
     TunnelID: 0x1                   Flags: RD
    BkNextHop: 3.3.3.3         BkInterface: GigabitEthernet0/0/2
      BkLabel: 1024            SecTunnelID: 0x0              
 BkPETunnelID: 0x3         BkPESecTunnelID: 0x0  
 BkIndirectID: 0x3

Check a backup next hop address. As you can see, loopback IP address of PE3 has been set as the backup next hop. Additionally a backup label has been specified.

VPN FRR ensures fast end-to-end convergence of services, in a VPN where CEs are dual-homed to a PE, in the case of a PE fault. VPN FRR technology is an improvement of the traditional technology. With VPN FRR, PE1 can select the appropriate VPNv4 routes according to the matching rules. For these routes, in addition to information about the preferred routes advertised by PE2, information about the second-best route advertised by PE3 is filled in the forwarding entry. When a fault occures on PE2, BFD session between PE1 and PE2 is going down. Next PE1 router detects that the outer tunnel between PE1 and PE2 is unavailable. If the LSP is unavailable, the forwarding engine uses the forwarding information of the second best route carried in the local forwarding entry to forward packets. This is how VPN FRR works.

Read More »

Huawei eNSP – news

Modified features:

  • Fixed incorrect VRRP state of Switch while using MD5 authentication mode.
  • Fixed loopback detection problem of Switch.
  • Fixed IPSEC issue of AR while using ah-esp or esp protocol if no authentication mode is on.
  • Fixed policy router+NAT issue of AR.
  • Enhanced eNSP Client stability.

A new Huawei eNSP has been released:

huawei-ensp-1-2-00-350

 

Read More »

IP FRR on Huawei routers

What do we have in traditional IP networks?

Let’s assume that there is a fault at the physical or data link layers. Router sees that a physical interface becomes DOWN. After the router detects this fault, it informs upper layer routing system to update routing information. The convergence time is several seconds, what is critical for sensitive services.

That’s why IP FRR has been developed. After we configure IP FRR, a router doesn’t wait for network convergence but a backup link is immediately used to forward packets.

We have 2 scenarios of using IP FRR:

  1. To protect routers in public networks.
  2. To protect CE routers in private networks.

Let’s focus on the first one.

IP FRR topology

 

I am using OSPF protocol to allow routers to learn routes from each other. Because of greater OSPF cost on POS links, traffic from AR1 to AR4 is forwarding through AR2:

[AR1]dis ip rout
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
         Destinations : 15       Routes : 15       

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

       10.0.0.0/24  Direct  0    0           D   10.0.0.1        GigabitEthernet0/0/1
       10.0.0.1/32  Direct  0    0           D   127.0.0.1       GigabitEthernet0/0/1
     10.0.0.255/32  Direct  0    0           D   127.0.0.1       GigabitEthernet0/0/1
       10.0.1.0/24  OSPF    10   2           D   10.0.0.2        GigabitEthernet0/0/1
       10.0.2.0/24  Direct  0    0           D   10.0.2.1        Pos2/0/0
       10.0.2.1/32  Direct  0    0           D   127.0.0.1       Pos2/0/0
       10.0.2.2/32  Direct  0    0           D   10.0.2.2        Pos2/0/0
     10.0.2.255/32  Direct  0    0           D   127.0.0.1       Pos2/0/0
       10.0.3.0/24  OSPF    10   101         D   10.0.2.2        Pos2/0/0
      127.0.0.0/8   Direct  0    0           D   127.0.0.1       InLoopBack0
      127.0.0.1/32  Direct  0    0           D   127.0.0.1       InLoopBack0
127.255.255.255/32  Direct  0    0           D   127.0.0.1       InLoopBack0
     172.16.1.1/32  OSPF    10   2           D   10.0.0.2        GigabitEthernet0/0/1
    192.168.1.1/32  Direct  0    0           D   127.0.0.1       LoopBack0
255.255.255.255/32  Direct  0    0           D   127.0.0.1       InLoopBack0

[AR1]dis ip rout 172.16.1.1 verbose 
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1

Destination: 172.16.1.1/32
     Protocol: OSPF             Process ID: 1
   Preference: 10                     Cost: 2
      NextHop: 10.0.0.2          Neighbour: 0.0.0.0
        State: Active Adv              Age: 00h00m18s
          Tag: 0                  Priority: medium
        Label: NULL                QoSInfo: 0x0
   IndirectID: 0x0              
 RelayNextHop: 0.0.0.0           Interface: GigabitEthernet0/0/1
     TunnelID: 0x0                   Flags:  D

What we want to do in this lab is to force AR1 router to forward traffic through POS interface, not waiting for control plane convergence.

We can accomplish this by configuring route policy on AR1 as follows:

[AR1]ip ip-prefix ipfrr index 10 permit 172.16.1.1 32

[AR1]route-policy ipfrr permit node 10
Info: New Sequence of this List.
[AR1-route-policy] if-match ip-prefix ipfrr 
[AR1-route-policy] apply backup-nexthop 10.0.2.2
[AR1-route-policy] apply backup-interface Pos2/0/0

Now it is enough to enable IP FRR on the public network:

[AR1]ip frr route-policy ipfrr

We can check what has changed:

[AR1]dis ip rout 172.16.1.1 verbose
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1

Destination: 172.16.1.1/32
     Protocol: OSPF             Process ID: 1
   Preference: 10                     Cost: 2
      NextHop: 10.0.0.2          Neighbour: 0.0.0.0
        State: Active Adv              Age: 00h00m06s
          Tag: 0                  Priority: medium
        Label: NULL                QoSInfo: 0x0
   IndirectID: 0x0              
 RelayNextHop: 0.0.0.0           Interface: GigabitEthernet0/0/1
     TunnelID: 0x0                   Flags:  D
    BkNextHop: 10.0.2.2        BkInterface: Pos2/0/0
      BkLabel: NULL            SecTunnelID: 0x0              
 BkPETunnelID: 0x0         BkPESecTunnelID: 0x0              
 BkIndirectID: 0x0

Read More »

configuring SNMPv3 on Huawei devices

SNMPv1 and SNMPv2c protocols security model uses the community-based pseudo-authentication. That means that a password (called a community string) is sent in a clear text between a network management station and managed devices. Both SNMPv1 and v2c are subject to packet sniffing because they do not implement encryption. Security has been the biggest weakness of the SNMP since the beginning. More about SNMPv2c concepts, operation and configuration you can find at “SNMPv2c configuration on Huawei devices“.

What if we want SNMP to be used over a public network?

SNMPv3 can be implemented. It provides important security features, which are not available in both SNMPv1 and v2c:

  • Confidentiality – encryption of packets to prevent snooping by an unauthorized source
  • Integrity – to ensure that a packet has not been tampered while in transit using optional packet reply protection
  • Authentication – to verify that a packet comes from a valid source.

SNMPv3 defines some new concepts: security level, user and group. The following security levels exists:

  • Authentication without encryption – authentication keyword in CLI – only the authenticated administrators can access the managed device.
  • No authentication and no encryption – noauth keyword in CLI – this security level can be used only in secure networks
  • Authentication and encryption – privacy keyword in CLI – only authenticated administrators can access the managed device and transmitted data is encrypted preventing interception or data leaking. This level should be used over the networks vulnerable to attacks.

A group defines the access policy for a user. Access policy defines which SNMP objects can be accessed or which SNMP objects can generate notifications to the members of a group. If the authentication and encryption mode are not specified, a user can only access views in non-authentication and non-encryption mode.

When using SNMPv3, system firstly verifies a user based on the configured authentication and encryption mode. After the user passes the authentication, the system verifies which SNMP views that user can access, based on the group to which the user was assigned.

A group can be configured using command syntax:

snmp-agent group v3 group-name { authentication | noauth | privacy } [ read-view read-view | write-view write-view | notify-view notify-view | acl acl-number ]

An SNMPv3 user can be assigned to the group using the following command syntax:

snmp-agent usm-user v3 user-name group-name [ authentication-mode { md5 | sha } authkey [ privacy-mode { aes128 | des56 } prikey | plain-text ] ] [ acl standard-acl ]

After an SNMPv3 group is configured, the system can effectively control the access rights of all users in the group, using the group settings. User access can be encrypted and authenticated, authenticated but not encrypted, or neither authenticated nor encrypted. If the access level of a user is lower than the security level of the specified group, the access fails. When the group, to which a user belongs, has multiple security levels, the user can select the group with the highest security level, among the groups that can be accessed, and access the view of the group.

Let’s configure SNMPv3 read access for NMS1 IP: 150.100.12.1. In order to do that, NMS1 user will be configured and added to the GROUP1. NMS1 user will use SHA algorithm with AUTHKEY1 key for authentication and AES128 with ENCRYPTKEY1 key for encryption. Access to the group GROUP1 will be allowed for NMS1 only. ACL 2001 will be configured for that restriction.

[LabnarioR1]snmp-agent
[LabnarioR1]snmp-agent sys-info version v3
[LabnarioR1]snmp-agent group v3 GROUP1 privacy acl 2001

[LabnarioR1]acl 2001
[LabnarioR1-acl-basic-2001]rule 10 permit source 150.100.12.1 0.0.0.0 
 
[LabnarioR1]snmp-agent usm-user v3 NMS1 GROUP1 authentication-mode sha AUTHKEY1 privacy-mode aes128 ENCRYPTKEY1

As a next step let’s configure trap messages to be sent from our LabnarioR1 router to the NMS1, using traps parameter sending list name NMSTRAPS1:

[LabnarioR1]snmp-agent trap enable

[LabnarioR1]snmp-agent target-host trap-hostname NMS1 address 150.100.12.1 trap-paramsname NMS1TRAPS

Traps will be authenticated at the receive end and encrypted at the transmit end (privacy keyword). Transmission protocol will be SNMPv3. Let’s configure traps parameter sending list NMS1TRAPS:

[LabnarioR1]snmp-agent target-host trap-paramsname NMS1TRAPS v3 securityname NMS1 privacy

As a source IP of traps generated, loopback1 address will be used:

[LabnarioR1]snmp-agent trap source LoopBack1

Equipment administrator’s contact information allows the NMS administrator to call equipment administrator in case of a failure:

[LabnarioR1]snmp-agent sys-info contact CALL 0800-123456789

For verification use the commands as below:

[LabnarioR1]dis snmp-agent group GROUP1

   Group name: GROUP1 
   Security model: v3 AuthPriv
   Readview: ViewDefault 
   Writeview:  
   Notifyview:  
   Storage type: nonVolatile 
   Acl: 2001

[LabnarioR1]dis snmp-agent usm-user 
   User name: NMS1 
   Engine ID: 800007DB03000000000000 
   Group name: GROUP1 
   Authentication mode: sha, Privacy mode: aes128 
   Storage type: nonVolatile 
   User status: active 
   Acl: 2001

   Total number is 1 

[LabnarioR1]dis snmp-agent target-host 
   Traphost list:
   Target host name: NMS1 
   Traphost address: 150.100.12.1 
   Traphost portnumber: 162   
   Target host parameter: NMS1TRAPS 

   Total number is 1 

   Parameter list trap target host:
   Parameter name of the target host: NMS1TRAPS 
   Message mode of the target host: SNMPV3 
   Trap version of the target host: v3 
   Security name of the target host: NMS1 
   Security level of the target host: privacy 

   Total number is 1 

[LabnarioR1]display snmp-agent sys-info contact 
   The contact person for this managed node: 
           CALL 0800-123456789

Read More »