DHCP(Dynamic Host Configuration Protocol) Notes

DHCP

=====

Extension to BOOTP for automatic host configuration

-provides IP addressing, netmask, default gw, bootfile, etc

Broadcasts UDP packets

-source port BOOTPC 68

-Destination port BOOTPS 67

Server should be in the same broadcast domain. When dhcp server and client are not in the same broadcast domain, relays are used.

-dhcp relays must be used otherwise.

IOS supports the following

-DHCP server

-DHCP client

-DHCP proxy (used in PPP interfaces)

. translate IPCP request into DHCP

-DHCP relaying (is configured with ip-helper address)

Server configured using DHCP pools

-each pool has an IP subnet for allocation

-host pools are supported

DHCP Pool Selection

===============

Server may have multiple address pools

Pool is selected based on :

-DHCP client ID (could be any string. )

 . Supplied by windows clients but not Linux

-DHCP hardware address if ID is missing

-Relaying gateway IP address

-Receiving interface IP subnet if no matching pool found and no relay IP address present.

DHCP relaying:

==========

Broadcast can be relayed to unicast destination

-ip helper-address interface commands

In case of DHCP, relaying router inserts interface IP address

-known as “giaddr” or gateway address

-other options could be inserted, eg. Information Option

DHCP server matches pool based on giaddr

DNS

====

IOS has DNS client enabled by default

-configure servers with ip name-server

-broadcast if no server configured

-no ip domain-lookup to disable

IOS can be configured as DNS server

-ip dns server to enable

-ip host for local DNS entries

-ip name-server to relay request

what is alternative of DHCP

An alternative to DHCP (Dynamic Host Configuration Protocol) is the Stateless Address Autoconfiguration (SLAAC) protocol, commonly used with IPv6 networks. While SLAAC and DHCP serve similar purposes of assigning IP addresses to devices on a network, they operate differently. Here's an overview of SLAAC as an alternative to DHCP:

1. **Stateless Address Autoconfiguration (SLAAC)**:

   - SLAAC is a protocol used to automatically configure IPv6 addresses on devices within a network without the need for a central server.

   - In SLAAC, devices generate their own IPv6 addresses based on network prefixes advertised by routers. Routers periodically send Router Advertisement (RA) messages containing network prefix information.

   - Devices use the network prefix information from RA messages to form their IPv6 addresses by combining the prefix with an interface identifier. The interface identifier can be derived from the device's MAC address or generated using other methods.

   - SLAAC does not involve a central server assigning IP addresses or maintaining state information about address leases, making it a stateless protocol.

Advantages of SLAAC compared to DHCP include:

- **Simplicity**: SLAAC eliminates the need for a central DHCP server, simplifying network configuration and management.

- **Efficiency**: SLAAC requires fewer network messages and reduces network traffic compared to DHCP, as there is no need for address assignment or lease renewal negotiations.

- **Scalability**: SLAAC is highly scalable and suitable for large networks with many devices, as address assignment is distributed across routers rather than relying on a central server.

While SLAAC is suitable for automatically configuring IPv6 addresses in many network environments, it does not provide some of the features offered by DHCP, such as assigning additional configuration parameters (e.g., DNS server addresses, domain names, and network settings). In some cases, a combination of SLAAC and DHCPv6 may be used to provide both address assignment and additional configuration options in IPv6 networks.

Netflow Notes

Netflow

=============

Collects information on traffic flows

-flow is unidirectional stream sharing src/dst IPs, TCP/UDP ports, and TOS byte

-Exports information to collector device suing UDP

Configured per-interface/sub-interface

-ip flow ingress

-ip flow egress

If we want to collect usage statistics of how much BW is used, what are the different applications that are used, how much is web or ftp traffic)

Then we need to collect this information from some collector called export collector and mentioned whether to collect statistics at the inbound or outbound interface. What is the version collection station supports?

Export configuration

-ip flow-export destination

-ip flow-export source | version

Class-based Netflow Sampling

-flow sampler: flow-sampler-map

-MQC class: netflow-sample

Most commonly used versions are 5 and 9

Flow data can be viewed locally

Eg Top Talkers.

We can have ingress and egress flow.

We can also track traffic based on BGP AS.

Config:

Int s0/0

Ip flow egress

Ip flow ingress

Ip flow-top-talkers

Top 10

Note: Netflow is developed by cisco. Netflow is enabled per-interface and sends “,meta-data” about the traffic flowing through that interface

. input/output interface

. Source/Destination ip

. tcp headers

. tos information

Netflow flows are sent to a Netflow collector for data analysis. Netflow by default used UDP with a user-defines port.

SNMP Notes

SNMP:

======

Simple network management protocol

-runs over UDP ports 161/162

Management Information Base (MIB)

-used to read/write a variable in the device configuration

Network management station(NMS) asks managed device(can be router or switch) the status of a MIB

-called  SNMP polling

Managed devices(ie agents) may also report unsolicited events

-called SNMP Traps or Informs(informs are acknowledged but traps are not, traps are unreliable)

MIB is platform and version specific. Snmpwalk is used by NMS to poll every variable in MIB to verify what version and platform it supports. Once all the MIBS are known, u can poll for whatever u want.

SNMP versions

===========

Three main versions

-V1: supports only community authentication

-V2c: support community authentication and views(ie what management station can view which MIB)

-V3: supports users/groups, encryption, and secure authentication. (can assign views to different users and apply users to groups) then we can apply permission to see/change the specific value of MIB on the router.

SNMP V1/V2c Polling

====================

Configured as snmp-server community

[string ] [ro | rw] [acl]

Community string

-clear-text password for NMS to poll device

Two types of community stringd

-read only

-read/write (configuration changes remotely or reloading router remotely)

ACL defines who can poll device

SNMP Traps

=============

Device  reports unsolicited events to NMS

Reports could be

-unreliable: traps (configure in cases when CPU threshold exceeded, network interface goes down)

-reliable: informs. Informs are acknowledged.

-Both are sent using UDP to port 162.

SNMP v1/v2c Traps

=============

Define events to trap

-All traps

Snmp-server enable traps

-Specific Traps

Snmp-server enable traps [notification-type]

Now define to which all NMS these traps are sent to

Define host to send traps to

-All enabled traps

. snmp-server host host-addr community-string

-Subset of enabled traps

. snmp-server host host-addr community-string [notification-type]

Note: all these commands are executed in agents (router or switches).

SNMPv3

===========

Three main entities

-Users

. Define operators accessing the routers

-Groups

. Group users, access privileges assigned to groups

-         - Views

. Define subsets of MIB visible to groups (like only allowed to see system MIB, or interface MIB or CPU MIB)

SNMP v3 Security

============

Access to MIB is either

-          Unauthenitcated/Unencrypted

. NoauthNo Priv

-          Authenticated only

. AuthNoPriv

-          Authenticated and encrypted

. AuthPriv

SNMP v3 Traps

=============

Supports Traps/Informs

Authentication model is different

Trap needs to have a user associated

User’s credentials are used to authenticate

The NMS needs to implement authentication

SNMP v3 configuration

==================

View

-          Snmp-server view MYVIEW cisco included

Group

-          Snmp-server group MYGROUP v3 priv read MYVIEW

User

-          Snmp-server user MYUSER MYGROUP v3 auth md5 PASSWORD priv des ENCRYPTKEY

Trap

-          Snmp-server host 10.0.0.100 trap version 3 auth MYUSER cpu syslog

RMON:

====

Remote Monitoring

-used to monitor MIB variables

Monitoring has two components

-Alarm

. Condition to trigger event

-Event

. Action to associate to alarm

. Normally a syslog message/SNMP Trap

RMON Alarm

===============

RMON alarm defines how MIB is sampled

Alternate of SNMP

An alternative to SNMP (Simple Network Management Protocol) is the NETCONF (Network Configuration Protocol) protocol. NETCONF is a standardized network management protocol developed by the IETF (Internet Engineering Task Force) to provide a more modern and flexible approach to network device management compared to SNMP. Here are some key differences and features of NETCONF compared to SNMP:

1. **Data Model**: SNMP uses a hierarchical management information base (MIB) to represent and organize managed objects. NETCONF, on the other hand, uses YANG (Yet Another Next Generation) data modeling language to define the structure and semantics of configuration and operational data exchanged between network devices and management systems. YANG provides a more structured and expressive way to describe data models compared to MIBs.

2. **Configuration and Operations**: NETCONF supports both configuration management and operational data retrieval operations. It allows network administrators to remotely configure and manage network devices using standardized RPC (Remote Procedure Call) operations defined in the NETCONF protocol. This includes operations such as get, set, edit-config, delete-config, and more.

3. **Transport Protocol**: SNMP typically uses UDP (User Datagram Protocol) as its transport protocol, which can be less reliable and secure compared to TCP (Transmission Control Protocol). NETCONF, on the other hand, uses SSH (Secure Shell) as its transport protocol by default, providing secure and encrypted communication between network devices and management systems.

4. **Transaction Support**: NETCONF provides transactional support for configuration changes, allowing administrators to group multiple configuration changes into a single atomic transaction. This ensures consistency and reliability when applying configuration changes to network devices.

5. **Extensibility**: NETCONF is designed to be extensible and supports the use of custom data models and extensions. This allows vendors to define vendor-specific data models and capabilities while still interoperating with standard NETCONF implementations.

Overall, NETCONF offers a more modern and flexible approach to network management compared to SNMP, with support for structured data modeling, transactional configuration changes, and secure transport. It is increasingly being adopted by network vendors and operators as a replacement or complement to SNMP for managing and configuring network devices.