The TCP/IP model

TCP/IP is based on a four-layer reference model. All protocols that belong to the TCP/IP protocol suite are located in the top three layers of this model.

The types of services performed and protocols used at each layer within the TCP/IP model are described in more detail in the following table.

 

Layer	Description	Protocols
Application	Defines TCP/IP application protocols and how host programs interface with transport layer services to use the network.	HTTP, Telnet, FTP, TFTP, SNMP, DNS, SMTP, X Windows, other application protocols
Transport	Provides communication session management between host computers. Defines the level of service and status of the connection used when transporting data.	TCP, UDP, RTP
Internet	Packages data into IP datagrams, which contain source and destination address information that is used to forward the datagrams between hosts and across networks. Performs routing of IP datagrams.	IP, ICMP, ARP, RARP
Network interface	Specifies details of how data is physically sent through the network, including how bits are electrically signaled by hardware devices that interface directly with a network medium, such as coaxial cable, optical fiber, or twisted-pair copper wire.	Ethernet, Token Ring, FDDI, X.25, Frame Relay, RS-232, v.35

BGP States

BGP cycles through five states as it runs:

• Idle— Searching for neighbors

• Connect— TCP three-way handshake complete with neighbor

• Open Sent— BGP Open message has been sent

• Open Confirm— Response received (otherwise go to Active state)

• Established— BGP neighborship is established

BGP States

BGP cycles through five states as it runs:

• Idle— Searching for neighbors

• Connect— TCP three-way handshake complete with neighbor

• Open Sent— BGP Open message has been sent

• Open Confirm— Response received (otherwise go to Active state)

• Established— BGP neighborship is established

OSPF States

The following list describes each possible state of a neighbor relationship:

• Down— This is the first OSPF neighbor state. It means that no information (hellos) has been received from this neighbor.

• Attempt— This state is only valid for manually configured neighbors in an NBMA environment. In Attempt state, the router sends unicast hello packets every poll interval to the neighbor from which hellos have not been received within the dead

interval.

• Init— This state indicates that the router has received a hello packet from its neighbor, but the receiving router's ID was not included in the hello packet.

• 2-Way— This state indicates that bi-directional communication has been established between two routers.

• Exstart— Once the DR and BDR are elected, the actual process of exchanging linkstate information can start between the routers and their DR and BDR.

• Exchange— In the exchange state, OSPF routers exchange database descriptor

(DBD) packets.

• Loading— In this state, the actual exchange of link-state information occurs.

• Full— In this state, routers are fully adjacent with each other. All the router and

network LSAs are exchanged and the router databases are fully synchronized.

OSPF LSA Types

The following are descriptions of each type of LSA.
Type 1
Every router generates router link advertisements for each area to which it belongs. A type 1 LSA describes the collective states of the directly connected links (interfaces) of the router. These LSAs are flooded only within the area in which they are originated.

Type 2
A type 2 LSA is generated for every transit broadcast and NBMA network within an area. A transit network has at least two directly attached OSPF routers. Ethernet is an example of a transit network.
The DR of the network is responsible for advertising the network LSA. A type 2 network LSA lists each of the attached routers that make up the transit network, including the DR itself, as well as the subnet mask used on the link. The type 2 LSA then floods to all routers within the transit network area. Type 2 LSAs never cross an area boundary. The link-state ID for a network LSA is the IP interface address of the DR that advertises it.

Type 3
The ABR sends type 3 summary LSAs. Type 3 LSAs advertise any networks owned by an area to the rest of the areas in the OSPF autonomous system, as shown in Figure.
The link-state ID is set to the network number; the mask is also advertised.
By default, OSPF does not automatically summarize groups of contiguous subnets or summarize a network to its classful boundary. The network operator uses configuration commands to specify how the summarization occurs. By default, a type 3 LSA is advertised into the backbone area for every subnet defined in the originating area, which can cause significant flooding problems. Consequently, you should always consider using manual route summarization at the ABR.
Summary LSAs are flooded throughout a single area only, but are regenerated by ABRs to flood into other areas.

Note By default, summary LSAs do not contain summarized routes.

Type 4
A type 4 summary LSA is generated by an ABR only when an ASBR exists within an area. A type 4 LSA identifies the ASBR and provides a route to it. The link-state ID is set to the ASBR router ID. All traffic destined to an external autonomous system requires routing table knowledge of the ASBR that originated the external routes.
In Figure, the ASBR sends a type 1 router LSA with an external bit (e bit) that is set to identify itself as an ASBR. When the ABR, which is identified with a border bit (b bit) in the router LSA, receives the type 1 LSA, it builds a type 4 LSA and floods it to the backbone (area 0). Subsequent ABRs regenerate a type 4 LSA to flood into their areas.

Type 5
Type 5 external LSAs describe routes to networks outside the OSPF autonomous system. Type 5 LSAs are originated by the ASBR and are flooded to the entire autonomous system.
The link-state ID is the external network number. Because of the flooding scope, and depending on the number of external networks, the default lack of route summarization can be a major issue with external LSAs. Therefore, you should summarize blocks of external network numbers at the ASBR to reduce flooding problems.

Type 6
Type 6 LSAs are specialized LSAs that are used in multicast OSPF applications.

Type 7
Type 7 is an LSA type that is used in not-so-stubby areas (NSSAs). They are originated by ASBRs within NSSAs and are flooded only within the NSSA in which they originated.

Type 8
Type 8 is a specialized LSA that is used in internetworking OSPF and Border Gateway Protocol (BGP).

Types 9, 10, and 11
The opaque LSAs, types 9, 10, and 11, are designated for future upgrades to OSPF for application-specific purposes. For example, Cisco Systems uses opaque LSAs for Multiprotocol Label Switching (MPLS) with OSPF. Opaque LSAs are distributed using standard LSDB flooding mechanisms. Each type has a different flooding scope.  

OSPF LSA Types

The following are descriptions of each type of LSA.
Type 1
Every router generates router link advertisements for each area to which it belongs. A type 1 LSA describes the collective states of the directly connected links (interfaces) of the router. These LSAs are flooded only within the area in which they are originated.

Type 2
A type 2 LSA is generated for every transit broadcast and NBMA network within an area. A transit network has at least two directly attached OSPF routers. Ethernet is an example of a transit network.
The DR of the network is responsible for advertising the network LSA. A type 2 network LSA lists each of the attached routers that make up the transit network, including the DR itself, as well as the subnet mask used on the link. The type 2 LSA then floods to all routers within the transit network area. Type 2 LSAs never cross an area boundary. The link-state ID for a network LSA is the IP interface address of the DR that advertises it.

Type 3
The ABR sends type 3 summary LSAs. Type 3 LSAs advertise any networks owned by an area to the rest of the areas in the OSPF autonomous system, as shown in Figure.
The link-state ID is set to the network number; the mask is also advertised.
By default, OSPF does not automatically summarize groups of contiguous subnets or summarize a network to its classful boundary. The network operator uses configuration commands to specify how the summarization occurs. By default, a type 3 LSA is advertised into the backbone area for every subnet defined in the originating area, which can cause significant flooding problems. Consequently, you should always consider using manual route summarization at the ABR.
Summary LSAs are flooded throughout a single area only, but are regenerated by ABRs to flood into other areas.

Note By default, summary LSAs do not contain summarized routes.

Type 4
A type 4 summary LSA is generated by an ABR only when an ASBR exists within an area. A type 4 LSA identifies the ASBR and provides a route to it. The link-state ID is set to the ASBR router ID. All traffic destined to an external autonomous system requires routing table knowledge of the ASBR that originated the external routes.
In Figure, the ASBR sends a type 1 router LSA with an external bit (e bit) that is set to identify itself as an ASBR. When the ABR, which is identified with a border bit (b bit) in the router LSA, receives the type 1 LSA, it builds a type 4 LSA and floods it to the backbone (area 0). Subsequent ABRs regenerate a type 4 LSA to flood into their areas.

Type 5
Type 5 external LSAs describe routes to networks outside the OSPF autonomous system. Type 5 LSAs are originated by the ASBR and are flooded to the entire autonomous system.
The link-state ID is the external network number. Because of the flooding scope, and depending on the number of external networks, the default lack of route summarization can be a major issue with external LSAs. Therefore, you should summarize blocks of external network numbers at the ASBR to reduce flooding problems.

Type 6
Type 6 LSAs are specialized LSAs that are used in multicast OSPF applications.

Type 7
Type 7 is an LSA type that is used in not-so-stubby areas (NSSAs). They are originated by ASBRs within NSSAs and are flooded only within the NSSA in which they originated.

Type 8
Type 8 is a specialized LSA that is used in internetworking OSPF and Border Gateway Protocol (BGP).

Types 9, 10, and 11
The opaque LSAs, types 9, 10, and 11, are designated for future upgrades to OSPF for application-specific purposes. For example, Cisco Systems uses opaque LSAs for Multiprotocol Label Switching (MPLS) with OSPF. Opaque LSAs are distributed using standard LSDB flooding mechanisms. Each type has a different flooding scope.  

AS-path prepending (BGP)

AS-path prepending is the manipulation of the BGP AS-path attribute beyond the insertion of local AS number on outgoing EBGP updates. Extra AS-numbers are inserted (prepended) at the beginning of AS-path, just after the local AS-number.
Cisco IOS supports inbound and outbound AS-path prepending on EBGP sessions. AS-path prepending does not work on IBGP sessions.
Outbound AS-path prepending can be used as the last-resort mechanism to influence global BGP routing policies in BGP multi-homing scenarios where all other methods (Multi-exit Discriminator or Local preference manipulation through BGP communities) don’t work due to lack of upstream ISP’s support or due to the wide difference in upstream ISP’s connectivity to the internet core.

router bgp 65000

no synchronization

bgp log-neighbor-changes

network 10.7.1.0 mask 255.255.255.0

neighbor 10.0.1.2 remote-as 64800

neighbor 10.0.1.6 remote-as 64800

neighbor 10.0.1.6 route-map prepend out

!

route-map prepend permit 10

 set as-path prepend 65000 65000 65000

router bgp 64800

no synchronization

bgp log-neighbor-changes

neighbor 10.0.1.1 remote-as 65000

neighbor 10.0.1.1 route-map prependIn in

neighbor 10.2.0.2 remote-as 64800

!

route-map prependIn permit 10

set as-path prepend last-as 2

DHCP snooping

DHCP snooping is a DHCP security feature that provides security by filtering untrusted DHCP messages and by building and maintaining a DHCP snooping binding table. An untrusted message is a message that is received from outside the network or firewall and that can cause traffic attacks within your network.

The DHCP snooping binding table contains the MAC address, IP address, lease time, binding type, VLAN number, and interface information that corresponds to the local untrusted interfaces of a switch; it does not contain information regarding hosts interconnected with a trusted interface. An untrusted interface is an interface that is configured to receive messages from outside the network or firewall. A trusted interface is an interface that is configured to receive only messages from within the network.

DHCP snooping acts like a firewall between untrusted hosts and DHCP servers. It also gives you a way to differentiate between untrusted interfaces connected to the end-user and trusted interfaces connected to the DHCP server or another switch

ARP throttling

ARP throttling is a feature that prevents ARP-based DoS attacks on Catalyst switches. The feature works by installing a throttling adjacency in the hardware CEF table such that hardware-switching drops subsequent identical ARP requests for a specific time period until the respective ARP response is received

Copy IOS from PC to Router

Install a TFTP software on PC(Eg: 3cdemon,ciscotftp,solarwings) Rouer and PC are connected through LAN/WAN check connectvity between PC and Router Router#show flash               // check necessary space is available at flash Rouer# copy tftp: Flash: give the ip of tftp server source ios name destination name (optional) after completing  Router#show flash             give bootsysystem flash:<name of ios>    // for booting this ios at next restart Router# delete flash:<ios name> If your Cisco router experiences difficulties and no longer contains a valid Cisco IOS software image in flash memory, you can download a new Cisco IOS image using one of the following ROM monitor commands: xmodem—(All Cisco 2600 series routers) Use this command to copy a Cisco IOS image from the console, if the computer attached to your console has a terminal emulator with Xmodem capability Downloading a Cisco IOS image from a console is very slow rommon 1 > xmodem -c c2600-is-mz.122-10a.bin tftpdnld—(Except Cisco 2691) Use this command to copy a Cisco IOS image from a TFTP server that is accessible through the FastEthernet 0/0, Ethernet 0/0, or Token Ring 0/0 port rommon 3 > set  rommon 4 > IP_ADDRESS=171.68.171.0      rommon 17 > IP_SUBNET_MASK=255.255.254.0      rommon 18 > DEFAULT_GATEWAY=171.68.170.3      rommon 19 > TFTP_SERVER=171.69.1.129      rommon 20 > TFTP_FILE=c2600-is-mz.113-2.0.3.Q      rommon 21 > tftpdnld Copy IOS from router to router first set the one router as tftp server     Router(Config)#tftp-server flash:ios name in the next router router#copy tftp flash:

DHCP Configuration

ip dhcp excluded-address 192.168.0.1 192.168.0.10

ip dhcp excluded-address 192.168.0.245 192.168.0.254

ip dhcp pool QSI-Data

network 192.168.0.0 255.255.255.0

default-router 192.168.0.1

dns-server 212.77.192.60

DHCP Configuration

ip dhcp excluded-address 192.168.0.1 192.168.0.10

ip dhcp excluded-address 192.168.0.245 192.168.0.254

ip dhcp pool QSI-Data

network 192.168.0.0 255.255.255.0

default-router 192.168.0.1

dns-server 212.77.192.60

Vlan configuration

Switch(Config)# Vlan 2

Switch(Config-vlan)# name sales

Switch(Config-vlan)# exit

Switch(Config)# interface fastethernet0/5

Switch(Config-if)# switchport mode access

Switch(Config-if)# switchport access vlan 2

Switch(Config-if)# exit Switch(Config)#interface vlan 2 Switch(Config-if)#ip address 192.168.10.2 255.255.255.0 Switch#show vlan Switch#show  interface fastethernet0/5 switchport Switch# show interfaces swaitchport

Cisco Certification

CCNA R&S
CCNP R&S
CCIE R&S

CCNA Security
CCNP Security
CCIE Security

CCNA Voice

 CCNP Voice
CCIE Voice

CCIP