Bash Script to Gather All Your Cisco Serial Numbers via SNMP

Posted: by SamDobs in Labels:
0

Handy Script from Eric Flores @ Packetpushers.net.

Recently, I was doing a true up of our Cisco SmartNet contract, and had to get the serial numbers from all of the Cisco devices on the network. Rather than access each device manually, I wrote a bash script that would get the serial numbers via the SNMP ENTITY table.
To use the script, you will need:
  1. A Linux distro with net-snmp-utils installed.
  2. The ENTITY-MIB.
  3. The location of the ENTITY-MIB specified in the variable ENTITY on line 13 of the script.
The command syntax is (which you can also get from running “./getserial.sh -–help” ) –
./getserial.sh [community] [list] [report_file.csv]
Parameters are as follows-
community – RO community string for devices
list – text file with the list of DNS name or IP addresses for each device – one device per line
report_file.csv – the output CSV file for the report
The script -
#!/bin/bash
# Help prompt
if [ -n "$1" ] && [ $1 == "--help" ]; then
echo -e “\nCommand usage:”
echo -e “./getserial.sh [community] [list] [report_file.csv]\n”;
exit 1
fi
#Location of ENTITY-MIB
ENTITY=”/usr/share/snmp/mibs/ENTITY-MIB.txt”
# Set VARs
COMMUNITY=”$1″
LIST=`cat $2`
REPORT=”$3″
# Create CSV file and set header
echo -e “Device Description,Device Type,Serial Number,Model Number,Other\n” > $REPORT
# Loop through devices in list
for DEVICE in $LIST ; do {
# Get hostname from device
HOST=$(snmpget -v2c -c $COMMUNITY -Oqv $DEVICE SNMPv2-MIB::sysName.0)
# Add hostname and device name to csv
echo -e “$HOST,$DEVICE” >> $REPORT
# Echo status to stdout
echo -e “Querying device: $DEVICE – Hostname: $HOST”
# Querry ENTITY table on device cut only entPhysicalDescr, entPhysicalClass, entPhysicalSerialNum, entPhysicalModelName
# and entPhysicalAlias (entPhysicalAlias somtimes has serial number of chassis on router and model number on Nexus) colums
# and sed to remove top 3 lines of output. Input into a var TABLE
TABLE=$(snmptable -v2c -c $COMMUNITY -m +$ENTITY -Cf , $DEVICE 1.3.6.1.2.1.47.1.1.1 | cut -d “,” -f 1,4,10,12,13 | sed -n ’1,3d;p’)
# Get line numbers that only have an entry in entPhysicalSerialNum column and input into var LINES
LINES=$(echo -e “$TABLE” | cut -sd “,” -f 3 | grep -n . | cut -d : -f 1)
# Loop through line numbers in var LINES. Echo TABLE into sed and grab lines from var LINES.
# Append to csv file
for i in $LINES; do {
echo -e “$TABLE” | sed -n `echo -e “$i”`p >> $REPORT 2> /dev/null
}
done
# Add line between devices in csv
echo >> $REPORT
}
done
echo -e “\nSNMP Qeuries Completed.\n”
The output file will look like this (with serial numbers masked) -
Device Description,Device Type,Serial Number,Model Number,Other
firewall1.yourdomain.com
ASA 5520 Adaptive Security Appliance,chassis,JM#########,ASA5520,
ASA 5500 Series Security Services Module-20,module,JA########,ASA-SSM-20,
switch2.yourdomain.com
WS-C3750X-48,chassis,FD########,WS-C3750X-48T-S,
FRU Power Supply,powerSupply,LI########,C3KX-PWR-350WAC ,
WS-C3750X-48,chassis,FD#########,WS-C3750X-48T-S,
FRU Power Supply,powerSupply,LIT##########,C3KX-PWR-350WAC ,
router1.yourdomain.com
CISCO3925-CHASSIS,chassis, RELEASE SOFTWARE (fc1), RELEASE SOFTWARE (fc1),FTX########
Cisco Services Performance Engine 100 for Cisco 3900 ISR,module,FOC########,C3900-SPE100/K9,
8 Port GE Non-POE EHWIC Switch,module,FOC########,EHWIC-D-8ESG,
C3900 AC Power Supply 2,powerSupply,QC########,PWR-3900-AC,
1000BASE-LX SFP,module,FNS########,FTLF1318P2BCL-C3A,
C3900 AC Power Supply 1,powerSupply,QCS########,PWR-3900-AC,
nexusswitch1.yourdomain.com
Fabric [VPC domain:100],stack,FOX########, Inc.,N5K-C5596UP
48X10GE/Modular Supervisor in Fixed Module-1,module,JAF########, Inc.,N5K-C5596UP
16 port L3 GEM,module,JAF########, Inc.,N55-M160L3
Nexus5596 Chassis,chassis,FOX########, Inc.,N5K-C5596UP
PowerSupply-1 Fan-1,fan,POG########, Inc.,N55-PAC-1100W
PowerSupply-1 Fan-2,fan,POG########, Inc.,N55-PAC-1100W
PowerSupply-2 Fan-1,fan,POG########, Inc.,N55-PAC-1100W
PowerSupply-2 Fan-2,fan,POG########, Inc.,N55-PAC-1100W
You can then open the file up with any application that can parse a CSV, such as Microsoft Excel. For some reason, Cisco router chassis’, Nexus switches, and most SFPs don’t follow the MIB. Since they put serial and model numbers in the entPhysicalAlias column instead of entPhysicalSerialNum, you will find them in the “Other” field of the CSV.

How to check MTU on Windows 7.

Posted: by SamDobs in Labels:
0

Handy Command to check MTU size as well as Connection Status of Interface.

H:\>netsh interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 15          25        1500  disconnected  Wireless Network Connection
 18          25        1500  disconnected  Wireless Network Connection 2
 14          20        1500  connected     Local Area Connection
538          10        1500  disconnected  Local Area Connection 3

HTH...

Sam

Setting DF Bit from Windows Machine

Posted: by SamDobs in Labels:
0

In this Post I will show you How to Set DF bit on a Windows Machine (Windows 7).

Below is the PING options output:

H:\>ping

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
            [-r count] [-s count] [[-j host-list] | [-k host-list]]
            [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name

Options:
    -t             Ping the specified host until stopped.
                   To see statistics and continue - type Control-Break;
                   To stop - type Control-C.
    -a             Resolve addresses to hostnames.
    -n count       Number of echo requests to send.
    -l size        Send buffer size.
    -f             Set Don't Fragment flag in packet (IPv4-only).
    -i TTL         Time To Live.
    -v TOS         Type Of Service (IPv4-only. This setting has been deprecated
                   and has no effect on the type of service field in the IP Head
er).
    -r count       Record route for count hops (IPv4-only).
    -s count       Timestamp for count hops (IPv4-only).
    -j host-list   Loose source route along host-list (IPv4-only).
    -k host-list   Strict source route along host-list (IPv4-only).
    -w timeout     Timeout in milliseconds to wait for each reply.
    -R             Use routing header to test reverse route also (IPv6-only).
    -S srcaddr     Source address to use.
    -4             Force using IPv4.
    -6             Force using IPv6.


Now let's do a Ping test to Yahoo with MTU Size 1470 with DF Bit set.

H:\>ping yahoo.com -f -l 1470

Pinging yahoo.com [98.138.253.109] with 1470 bytes of data:
Reply from 98.138.253.109: bytes=1470 time=352ms TTL=39
Reply from 98.138.253.109: bytes=1470 time=442ms TTL=39

Ok, that's working so now let's do another test with 1500.

H:\>ping yahoo.com -f -l 1500

Pinging yahoo.com [98.138.253.109] with 1500 bytes of data:
Reply from 135.75.222.106: Packet needs to be fragmented but DF set.
Reply from 135.75.222.106: Packet needs to be fragmented but DF set.
Reply from 135.75.222.106: Packet needs to be fragmented but DF set.
Reply from 135.75.222.106: Packet needs to be fragmented but DF set.

HTH...

Sam

OSPF Neighborship v/s Adjacency

Posted: by SamDobs in Labels:
0

Article by @ packetpushers explaining OSPF Neighborship v/s Adjacency.

OSPF Neighborship v/s Adjacency.

IPsec VPN connection models: Site-to-site and client-to-site

Posted: by SamDobs in Labels:
2

Article from www.searchenterprisewan.com

In the first article in this series on implementing VPN gateways using Cisco routers, we reviewed the basic protocols and process involved with establishing an IPsec connection between two peers. Now let's take a look at the basic IPsec VPN connection models. While the IOS supports a variety of IPsec implementations, essentially all IPsec VPNs are implemented using one of two basic forms: site-to-site and client-to-site VPNs.


Site-to-site VPN
In the site-to-site VPN configuration above, each node is connected to a discrete network, separated by other unsecured or public networks. Depending on the security requirements for these network segments, it could be the case that end nodes on the networks are not able to exchange data unless the VPN is in place. This type of VPN configuration is known as a "closed" site-to-site network topology. Alternatively, the end nodes connected to the segments could have the ability to freely exchange data, utilizing other networks to relay the data back and forth. This data exchange, however, is unsecured. In this kind of network environment, IPsec can be employed to secure some or all of these data exchanges. This type of VPN configuration is known as an "open" site-to-site network design. The key point is that in either case, IPsec is implemented using gateways that secure the data exchanges. And, more importantly, the securing of the data exchanges is done without any knowledge of the end nodes connected to the networks being secured.


Client-to-site VPN
In the case of a client-to-site topology, the models "open" and "closed" still hold true. Connectivity between nodes separated by (or adjacent to) the IPsec gateway may or may not be restricted. In an open client-to-site topology, the network path between the end node and the IPsec gateway is secured. In a closed client-to-site topology, the path between the end node and gateway is secure. But data exchanges between the client node and nodes adjacent to (i.e., behind) the IPsec gateway is only possible if a connection to the IPsec gateway exists.

In both topologies, the relationship between the client node and the IPsec gateway is architecturally similar to a traditional PSTN remote-access dial network. The end node establishes a connection to the gateway and the two communicate as IPsec peers. Additionally, the gateway provides the end node an IP identity that gives the client node IP network access to other end nodes directly connected (via VPN) and adjacent to the IPsec gateway. The communications between the client end node and the gateway is secured with IPsec. Communications between the client end node and other end nodes adjacent to the IPsec gateway, however, are not secured.
When developing IPsec solutions, it is important to keep in mind that the IPsec protocol suite is geared to secure IP communications. The construct of the VPN is commonly perceived today as the connecting of private (secured) networks using public (unsecured) ones as the connectivity substrate. That is not solely what IPsec was developed to support. IPsec can also be used to enhance the security within private networks, using many of the same solution strategies used to secure data over public networks. That's a thought to keep in mind as we examine different IOS IPsec configurations, all of which start with the configuration of the router's ISAKMP policy using IKE.

IPSec Protocol Details

Posted: by SamDobs in Labels:
0

Article from www.searchenterprisewan.com


This article is first in a series on implementing VPN gateways using Cisco routers. The Cisco IOS implementation of the IPSec (Internet Protocol Security) suite is an open-standards based framework that provides network administrators with a variety of options to deliver secure IP network communications.
The IPSec framework is a suite of IETF standards that provides for secure transmission of data over unsecured networks, for example the Internet. IPSec provides protocols to secure communications at the Network Layer along with a mechanism for exchanging identity and security protocol management information. The IPSec suite was developed to address some of the fundamental security flaws of IPv4. IP version 4 was built to share information between computers running both like and dislike operating systems over a packet switched network. It could be said that in the 1970s, when TCP/IP was developed, security was not as much of an issue as actually getting the packets to where they belonged. However, when TCP/IP grew from supporting data exchange between a couple hundred systems to a global network of millions of computers, these vulnerabilities became of some concern.
IPSec protects against security vulnerabilities
There are three major IP security vulnerabilities. Two of this circle around the fact that IP data transmissions between hosts are dependent on each host having a universally unique IP address.
The first is IP spoofing. In order to trust received information, the origin of the information must also be trusted. IP packet delivery is handled on a hop-by-hop basis. An attacker with knowledge of the network topology can disable a system and assume or "spoof" its identity. Since most IP security paradigms revolve around a host's IP address, IP spoofing is problematic for network administrators who need to exchange data securely.
Session hijacking is IP spoofing taken to the next level. Here the attacker disables the spoofed host and assumes active network sessions. This is a far more sophisticated attack than assuming a host's IP identity, as it also depends on software vulnerabilities in order to be successfully executed.
The third vulnerability, traffic sniffing, is endemic to packet switched networks, where the packets are visible to all the network nodes that are connected to the transport medium. Routers, switches, and firewalls all have visibility into packets that pass through these gateways, regardless of the transmission medium. While this makes these devices great for passively filtering IP traffic, it also makes them great places to collect IP packets and extract the data contents.
IPSec protocol details
To address these vulnerabilities, the IETF has developed different protocol standard definitions. These standards provide four basic services:

  1. Data transmission encryption: The originating host can encrypt packets prior to transmission
  2. Data integrity validation: The receiving host can authenticate each packet sent to ensure the original data that was transmitted was received.
  3. Data source authentication: The originating host can mark packets, so the receiver can authenticate them.
  4. Data state integrity: The originating and receiving hosts can mark packets, so any re-transmission of the data stream can be detected and rejected (also known as anti-replay).
IPSec implementations use a number of different security protocols to provide these services. From a not so high level, these protocols can be broken down into two different camps: packet protocols and service protocols. The packet protocols are used to provide data security services. There are two IPSec packet protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP). There are a number of service protocols, but the primary one is the Internet Key Exchange protocol (IKE). Below is a basic overview of the protocols in the IOS's IPSec implementation.
Authentication Header: AH, defined in IETF RFC 2402, supports IPSec data validation, authentication and integrity services. It does not support data encryption. AH is typically implemented by itself, but can be implemented alongside ESP. AH is used when we only need to ensure with whom we are exchanging data. You might ask why one would use AH, because it does not support data encryption. Look at it this way: If data encryption is supported by the application, there is no need for additional data encryption. AH is "lighter" in terms of processing overhead, compared to ESP, so it is easy to employ on lower end routers.
Additionally, in comparison to ESP, AH provides greater IP layer security. AH secures the IP packet by generating hash signature data for all of the IP packet information that is not modified in transit. The AH security data is stored in the 32-bit long AH header, which is installed between the IP datagram header and the Layer 4 header. Because AH works by "securing" the IP Packet, AH cannot be employed in network environments where Network Address Translation (NAT) is used. AH operates in either transport or tunnel mode. In most cases tunnel mode is employed and the original IP packet is encapsulated in a new AH secured IP packet. This new packet contains a new IP header (with the destination address of the remote IPSec peer gateway) and the AH header, followed by the original IP packet and Layer 4 datagram. IANA (Internet Assigned Numbers Authority) has assigned ESP the protocol ID of 51.
Encapsulating Security Payload: ESP, defined in IETF RFC 2406, supports IPSec data encryption, validation, authentication and integrity services. ESP can be implemented alone or with AH. While the AH header is pre-pended to the data payload portion of the IP packet, ESP encapsulates the entire data portion of the IP packet with a header and trailer. The ESP header contains the security and sequencing information. The ESP trailer contains variable padding and (if desired) authentication data. ESP's encapsulation of the original ULP data and its encryption requires more router processing resources than AH. Additionally, ESP processing also requires that 1500-byte Layer 4 datagrams be fragmented to support the additional security payload data. Like AH, ESP also supports transport and tunnel operational modes, but almost all vendor implementations implement ESP exclusively in tunnel mode. The ESP RFC does not define what protocols should be used to encrypt the data. Cisco IOS supports 56-DES, 3DES and AES. Other implementations have implemented Blowfish and IDEA as well. IANA has assigned ESP the protocol ID of 50.
Internet Security Association and Key Management Protocol (ISAKMP) and Internet Key Exchange: These provide the framework and processes for implementing IPSec VPN service negotiation. ISAKMP is defined in IETF RFC 2408. IKE is defined in IETF RFC 2409. ISAKMP defines the schemes, syntax and procedures for creating and deleting authentication keys and security associations (SAs). IPSec peers use SAs to keep track of the different aspects of the security services policies negotiated between different IPSec peers. This includes:


  • ESP encryption algorithm
  • Authentication protocol
  • Key information
  • Key lifetimes
  • SA lifetimes
  • AH authentication algorithm
SAs are negotiated between peers when the peer connection is first established. During the establishment (and subsequent re-establishment), each peer assigns the SA it has negotiated with the other its own security parameter index (SPI) number. SPIs are exchanged between peers and used to identify packets. When a peer receives an IPSec packet, it examines the SPI, looks it up in the SPI database, finds the corresponding SA, and then processes the packet according to the rules in the SA. A key point to remember about ISAKMP is that it is independent of the key management protocol, the encryption and authentication used to implement IPSec. It just defines the rules it does not execute them. That is what IKE is for.
IKE is a hybrid of the Oakley key determination protocol and SKEME key exchange protocol. The IKE protocol manages the IPSec security associations within the ISAKMP of IPsec peers. IKE is a protocol available to ISAKMP; they are not one and the same. IKE is the mechanism that establishes the IPSec "connection" between IPSec peers. This requires the negotiation of:

  • Authentication algorithms: IKE uses Diffie-Hellman to establish shared secret session keys over the unsecured network transport.
  • Confidentiality algorithms: IKE manages the negotiation of the security protocols the peers will use, be they AH, ESP, or AH and ESP in combination.
  • Hash algorithms: IKE uses hash algorithms to authenticate packet data.
  • Identification keys: IKE supports the use of pre-shared keys, RSA keys (or nonces), digital certificates and Extended Authentication (Xauth) to support identity management.
IKE operates in three modes: main, aggressive, and quick. The main and aggressive modes both achieve the same end, establishing the initial phase or phase 1 IKE SAs. The phase 1 SA bootstraps the IKE process. Once the phase 1 negotiation is completed, quick mode can be used for phase 2 IKE operations that allow for the full SA negotiation and refreshing of SA information when the SA has expired.
The differences between main, aggressive, and quick modes have to do with the degree of security needed and the number of messages exchanged. Main mode uses six (three from the initiator and three from the responder) message exchanges. Main mode commences with the connection initiator proposing a negotiation SA to secure the Diffie-Hellman key exchange. Once the negotiation SA has been established, the Diffie-Hellman keys for quick mode authentication, IKE authentication and SA encryption are generated and exchanged and identity management is completed.
Aggressive mode starts with the initiator generating a Diffie-Hellman key, purposing a phase 1 SA and the peer's identity. Then the responder replies with an SA and identity data, with the initiator completing the process with verification data. The entire aggressive mode exchange is done without a negotiation SA, leaving all data exchanged unencrypted. So although the same information is exchanged with both phase 1 modes, one is more secure and the other faster. And although quick mode utilizes the same number of message exchanges as aggressive mode, quick mode does rely on the identity and security integrity established during the phase 1 negotiation.
By now it should be clear that with IPSec everything is negotiated. The security services supported between IPSec peers are negotiated between the two peers when communication is initiated. Depending on the type of peer (i.e., gateway vs. host), there may be a number of IKE policies supported or only one. When a session is initiated, the connecting peer will send all of its supported IKE policies. The remote peer will then respond with a match by comparing the purposed policy with its highest priority policy and subsequent policies in descending order. Only the IPSec services that can be supported by both peers are utilized.
For example, peer Alpha can support data encryption and integrity validation services, but peer Zeta only supports data encryption services. Both Alpha and Zeta need to have a common IKE policy. In this case, Alpha would need to have two different IKE policies: a policy that supports data and integrity services and another policy that supports only data services. In order for Alpha and Zeta to communicate, only data encryption services will be utilized. If Alpha only has a single IKE policy that supports data and integrity, then IKE will terminate the negotiation and the peers will not establish an IPSec connection.

Definition : IPSec (Internet Protocol Security)

Posted: by SamDobs in Labels:
0

IPSec (Internet Protocol Security) is a framework for a set of protocols for security at the network or packet processing layer of network communication. Earlier security approaches have inserted security at the Application layer of the communications model. IPsec is said to be especially useful for implementing virtual private networks and for remote user access through dial-up connection to private networks. A big advantage of IPsec is that security arrangements can be handled without requiring changes to individual user computers. Cisco has been a leader in proposing IPsec as a standard (or combination of standards and technologies) and has included support for it in its network routers. IPsec provides two choices of security service: Authentication Header (AH), which essentially allows authentication of the sender of data, and Encapsulating Security Payload (ESP), which supports both authentication of the sender and encryption of data as well. The specific information associated with each of these services is inserted into the packet in a header that follows the IP packet header. Separate key protocols can be selected, such as the ISAKMP/Oakley protocol.