Network Ready for Use Testing (NFRU)

NRFU testing is often a mandatory, final step in certifying that a new network infrastructure has been implemented correctly and is ready to carry production traffic. During NRFU testing, every device is methodically checked to ensure that it has been implemented according to the design specifications and is operating error-free. Network services are verified, devices are added as elements into NMS and Operational Support Systems (OSS) systems, and a baseline of application performance is recorded.

The testing was broken into four separate phases:

• Phase I: During this phase, device-level verification was done. This phase included activities such as serial number verification, line card checks, Cisco IOS level confirmation, and power checks.

• Phase II: This phase included logical configuration and connectivity verification. In this phase, actions such as circuit connectivity verifications, routing protocol checks, and traceroutes were performed. Multicast and QoS configurations were checked.

• Phase III: This included service verification and traffic testing. Service verification included features such as IP telephony, video, wireless, and common IP services (DHCP, DNS, NTP).

• Phase IV: This was the application testing phase. Production applications and network and security management were tested during this phase.

The tests performed in each phase were further broken into three different types:

• Tests that were performed on all Cisco routers and switches installed

• Platform/role-specific tests:

• Access layer switches

• Core layer switches

• Distribution layer switches

• Video distribution switches

• Server farm switches

• Service-specific tests

I will share reset details soon. 

 

Cisco Nexus : Executive Multiple Commands in one Go

Executing multiple CLI's in one go
CLI stands for Command line Interface

N7k-LabSW# show clock ; show switchname ; show license host-id
19:10:59.016 UTC Mon Apr 04 2016
N7k-LabSW
License hostid: VDH=TBM14354170

 # Works for configuration too:

N7k-LabSW# conf t ; hostname N7k-LabSW-DEFAULT ; end
Enter configuration commands, one per line.  End with CNTL/Z.
N7k-LabSW-DEFAULT#

How to router prevent from ARP Strom?

 How to Router Prevent from ARP Strom?
Why some ARP entry will showing in ARP Table after respective time expires?


The extra time is the jitter added to each dynamic ARP entry when it is created. Random jitter is added to the ARP cache timeout in order to avoid synchronous expiration of the ARP entries, which might trigger an ARP storm. Jitter should be a random number between 0 seconds and 30 minutes, with a maximum jitter of 30 minutes.

Bursty Traffic Identification on Switch port

Traffic bursts can cause output drops even when the interface output rate is significantly lower than the maximum interface capacity. By default, the output rates in the show interface command are averaged over five minutes, which is not adequate to capture any short-lived bursts. It is best to average them over 30 seconds. In this case, you can use Wireshark in order to capture egress traffic with the Switched Port Analyzer (SPAN), which is analyzed in order to identify the bursts.

HP 5412R Switch basic configuration - VLAN, SVI, OOBM Management Interface

OSPF Prefix Suppression

OSPF prefix-suppression is a useful feature in order to reduce the number of Link State Advertisement (LSA) that are flooded within an area. In an OSPF area which has multiple transit links between hosts and actual communication is between the hosts. There is no need to advertise the transit link LSAs to all the routers. You can only advertise the LSAs related to end hosts. By default, OSPF advertises all the LSAs that include the transit link LSAs.

OSPF prefix-suppression feature helps to overcome this behavior and reduces the number of Type 1(router) and Type 2(network) LSAs advertised.

This feature can be enabled globally on a router or on per interfaces basis.

OSPF prefix-suppression helps in faster Shortest Path First (SPF) calculation due to less number of prefixes in the database (DB). OSPF Type 3, Type 4, Type 5, or Type 7 LSAs are not suppressed.

Jitter timer in HSRP Protocol

 Jitter timers HSRP Protocol

Jitter timers are used in HSRP. They are recommended for timers running on services that work realtime and scale. Jitter timers are intended to significantly improve the reliability of HSRP, and other FHRP protocols, by reducing the chance of bunching of HSRP groups operations, and thus help reduce CPU and network traffic spikes. In the case of HSRP, a given device may have up to 4000 operational groups configured. In order to distribute the load on the device and network, the HSRP timers use a jitter. A given timer instance may take up to 20% more than the configured value. For example, for a hold time set to 15 seconds, the actual hold time may take 18 seconds.

In HSRP, the Hello timer (which sends the Hello Packet) has a negative Jitter, while the Holddown timer (which checks for failure of a peer) has a positive jitter.