Layer 7 Models

How DHCP clients work

DHCP client sends a DHCP-DISCOVER packet (flowchart here):

When a DHCP client device receives a packet:

• It drops the packet if (any):
  • The packet is not a valid DHCP packet.
  • The packet's destination MAC address does not match its own MAC address.
• It checks the packet's DHCP type (its DHCP message).
  • If the packet is a DHCP-OFFER packet, it uses the information in the packet (including client IP address, offered IP address, server IP address, and gateway address) to construct a DHCP-REQUEST packet and sends it back to the server.
  • If the packet is a DHCP-ACK packet, it gets the IP address, subnet mask, and the gateway IP address from the packet and sets its IP address configuration accordingly.
  • If the packet is not a DHCP-OFFER or a DHCP-ACK packet, it will drop the packet.

When a DHCP client device does not receive a packet:

• It starts to assign an auto-configuration ip address in the 169.254.0.0/16 address block.
• It sends out ARP Gratuitous to detect duplicate ip address.
  • If it gets an arp reply, it starts to assign the next available ip address from the 169.254.0.0/16 address block and sends out another ARP Gratuitous.
  • If it does not get an arp reply, it assigns the ip address to the port and continue sending out DHCP-DISCOVER packet.

How DHCP servers process incoming packets

When a DHCP server device receives a packet (flowchart here):

• It drops the packet if:
  • The packet is not a valid DHCP packet.
• It checks the packet's DHCP type (its DHCP message).
  • If the packet is a DHCP-DISCOVER packet:
  • If the client already has a lease:
  • Send a DHCP-OFFER packet with the associated IP to the client.
  • If the client does not already have a lease:
  • If there is an available IP address:
  • Send a DHCP-OFFER packet with the available IP address to the client.
  • Otherwise, drop the packet and stop.
  • If the packet is a DHCP-REQUEST packet:
  • If the requested IP address is available:
  • Send a DHCP-ACK packet with the available IP address to the client.
  • Bind the client to the IP address.
  • Otherwise, drop the packet and stop.
  • If the packet is a DHCP-RELEASE packet:
  • If the client is bound to the IP address:
  • Unbind the IP address and the client.
  • Otherwise, drop the packet and stop.
  • If the packet is a DHCP-OFFER or a DHCP-ACK packet, drop the packet.

How DHCP for IPv6 clients process incoming packets

When a DHCP for IPv6 client device receives a packet (flowchart here):

• It drops the packet if (any):
  • The packet is a Solicit message.
  • The packet is an Advertise message that meets any of the following conditions:
    • The message does not include a Server Identifier option.
    • The message does not include a Client Identifier option.
    • The content of the Client Identifier option does not match the client’s DUID.
    • The “transaction-id” field does not match the value the client used in its Solicit message.
  • The packet is a Request message.
  • The packet is a Reply message that meets any of the following conditions:
    • The message does not include a Server Identifier option.
    • The “transaction-id” field does not match the value used in the original message.
• It checks the packet's DHCP type (its DHCP message).
  • If the packet is an Advertise message, it will do the following actions:
    • It terminates retransmission of its Solicit message.
    • It sends a Request message to the DHCP server that the Advertise message was sent from.
  • If the packet is a Reply message, it gets the prefix and prefix length from the message and combines with its received interface’s local link address to create an IPv6 address and subnet mask.  It also retrieves the gateway IPv6 address from the packet.  Then the client sets its IPv6 address configuration accordingly.  

How DHCP for IPv6 servers process incoming packets

When a DHCP for IPv6 server device receives a packet (flowchart here):

• It drops the packet if:
  • The packet is a Solicit message that meets any of the following conditions:
    • The message does not include a Client Identifier option.
    • The message does not include a Server Identifier option.
  • The packet is an Advertise message.
  • The packet is a Request message that meets any of the following conditions:
    • The message does not include a Server Identifier option
    • The content of the Server Identifier option does not match the server’s DUID.
    • The message does not include a Client Identifier option.
  • The packet is a Reply message.
• It checks the packet's DHCP type (its DHCP message).
  • If the packet is a Solicit message, it uses the information in the packet and its server configuration to construct an Advertise message and sends it back to the client.
  • If the packet is a Request message, it uses the information in the packet and its prefix pool configuration to construct a Reply message and sends it back to the client.

How FTP client processes work

• File Transfer Protocol (FTP) is a standard network protocol used to exchange and manipulate files over a TCP/IP-based network, such as the Internet. FTP is built on a client-server architecture and utilizes separate control and data connections between the client and server applications. FTP uses user-based password authentication and is used for transferring configuration files between Cisco Switches and Routers and also available as a command in PC device.

When a FTP client receives a packet (flowchart here):

• If the packet is not a valid FTP response packet, it drops the packet.
• Otherwise, it writes the received information stored in the packet onto the screen.
  • Informs the application that uses FTP whether the response is successful or not.
  • It then checks to see if any further FTP commands are expected to be sent and sends them out.

How FTP server processes work

• The FTP server listens on the TCP port 21 for control connections and awaits FTP commands from the client. FTP can be run in active mode or passive mode, which control how the data connection is opened.
• In active mode the client sends the server the IP address port number that the client will use for the data connection, and the server opens the connection. Passive mode was devised for use where the client is behind a firewall and unable to accept incoming TCP connections. The server sends the client an IP address and port number and the client opens the connection to the server. By default passive mode is supported in this version of PT.
• The FTP server is available in Server device and is enabled by default. It can be configured via FTP configuration page for customizing FTP server behavior.

When a FTP server receives a packet (flowchart here):

• If the user is not valid or fails authentication, then it informs the FTP client and terminates the control connection.
• If the packet is not a valid FTP packet, it drops the packet.
• Otherwise, it checks the packet and:
  • If the FTP command is not supported by the server, an error message is sent back to the client.
  • If the FTP command is supported by the server, the action is performed and result of the operation is sent back to the client.
  • The list of supported FTP commands are:
    • USER
    • PASS
    • TYPE
    • PASV
    • RETR
    • STOR
    • RNFR
    • RNTO
    • DELE
    • QUIT

How TELNET client processes work

• TELetype NETwork is a network protocol that utilizes TCP/IP protocol stack to establish a client/server connection. The user starts a TELNET client process on a PC or a Cisco device using telnet command with server IP address. The TELNET server usually listens on TCP port 23 and awaits client connection requests. A TELNET packet is generated from the client process when a key is pressed.

When a TELNET client receives a packet (flowchart here):

• If the packet is not a valid TELNET packet, it drops the packet.
• Otherwise, it writes the received information stored in the packet onto the screen.

How TELNET server processes work

• TELetype NETwork is a network protocol that utilizes TCP/IP protocol stack to establish a client/server connection. The user starts a TELNET client process on a PC or a Cisco device using telnet command with server IP address. The TELNET server is started automatically on a Cisco router or switch. The server listens on TCP port 23 awaiting client connection requests.

When a TELNET server receives a packet (flowchart here):

• If the packet is not a valid TELNET packet, it drops the packet.
• Otherwise, it checks the packet and:
  • If the information received is part of a command, it sends an echo back to the client.
  • If the server is able to determine the command entered by the client, it sends the result back to the client.
  • If the server does not understand the information received, it sends an error message back to the client.

How SSH client processes work

• SSH client utilizes TCP/IP protocol stack to establish a client/server connection.
• Before a SSH connection could be established between client and server, both need to have an RSA key pairs generated, if the keys are not generated connection will be refused by the other side.
• In order for the Cisco device to generate RSA keys it needs to be configured with hostname and IP domain name.
• The user starts a SSH client process on a PC or a router using “ssh –l” (-l is for login) command with the associated client’s user name which is already configured on the SSH server, and IP address of the SSH server. The SSH server, usually listens on TCP port 22, awaits client connection requests. A SSH packet is generated from the client process when a key is pressed.

When a SSH client receives a packet:

• If the packet is not a valid SSH packet, it drops the packet.
• Otherwise, it writes the received the information stored in the packet onto the screen.

How SSH server processes work

• SSH is a network protocol that utilizes TCP/IP protocol stack and RSA key pairs to establish a secure client/server connection. The user starts a SSH client process on a PC or a Cisco device using ssh –l command with client’s associated user name and also the server’s IP address. The SSH server is started automatically on a Cisco router. The server listens on TCP port 22 awaiting client connection requests.

When a SSH server receives a packet:

• If the packet is not a valid SSH packet it drops the packet.
• If both client and server are not configured with RSA keys the connection will be refused by SSH server.
• Otherwise, it checks the packet and:
  • If the username received in the connection request packet is configured on the server it will prompt the client for the password
    • Client will be prompted for the correct password up to 3 times. If the password that the client provides is not valid for the third time it will be disconnected by the server.
  • If the information received is part of a command, it sends an echo back to the client.
  • If the server is able to determine the command entered by the client, it sends the result back to the client.
  • If the server does not understand the information received, it sends an error message back to the client.

How HTTP works (HTTPS works the same as HTTP)

When a client needs to find a webpage from a server:

• If the address is empty or starts with anything else other than http protocol, it drops the request since it is not supported in Packet Tracer.
• If the address is an IP address or starts with http:// the HTTP client processes it.
  • The HTTP client first finds the server IP through the server name by parsing the address in the address bar and:
    • If server name is not found, it tries to resolve the domain name through a DNS query.
    • If server name is found, it gets the IP address.
  • The HTTP client constructs a request HTTP segment and connects the server through TCP sockets and starts a timer for its request.

When an HTTP client receives a packet (flowchart here):

• If the HTTP message has the HTTP OK code, it fetches the page from the message and displays the message.
• Otherwise, the HTTP page displays an error page.

When HTTP server receives a request (flowchart here):

• If the HTTP service is enabled, and a TCP connection with the HTTP client is established:
• If the HTTP request is an HTTP GET:
  • If the username and password in the HTTP request are not correct:
  • The server sends back an unauthorized error message to the client.
• If the Request is for an html page:
• If the requested page exists on the server, the server creates a response packet and sends back an HTTP reply to the client.
• If the requesting page does not exist on the server, the server sends back an error message to the client.
• If the Request is for an image:
• If the requested image exists on the server, the server creates a response packet and sends back an HTTP reply to the client.
• If the requesting page does not exist on the server, the server sends back an error message to the client.
• If the HTTP request is an HTTP Post:
• If the post request is successful, the sever sends an HTTP success reply to the client.
• If the post request fails, the server sends an HTTP error reply to the client.
• Other message codes are not supported in this version of PT, and the server drops the packet.

How SMTP works

When a client needs to send a mail:

• If there is no outgoing mail server configured, it drops the request.
• If outgoing mail server name is not found it tries to resolve the domain name through a DNS query.
• If outgoing mail server name is found it gets the IP address.
• The SMTP client constructs a request SMTP segment and connects the server through TCP sockets and starts a timer for its request.

When an SMTP client receives a packet (flowchart here):

• If the SMTP message has the SMTP success codes it indicate that mail has been sent successfully
• Else the error message from server is passed to mail browser to display appropriate error message.

When SMTP server receives a request (flowchart here):

• If the SMTP service is enabled, and a TCP connection with the SMTP client is established:
  • If the SMTP request is not for this server:
  • Send a error message to client
  • If sender of mail does not exist on this server:
  • Send user does not exist error message to client
  • If receiver of mail does not exist on remote server:
  • Send user does not exist error mail to sender of mail.
  • If mail belong to this server:
  • If receiver of mail exist at this server:
  • Add mail to users account
  • Else
  • If sender of this mail has user account on this server:
  • Add a delivery failure mail to this users account
  • If Sender of this mail does not have user account on this server:
  • Send a delivery failure mail to sender of mail
  • Else ( Mail does not belong to this server)
  • If the request is forward request and sender does not have user account on this server:
  • Send a error mail to sender of a mail
  • Forward mail to receiver's server

How POP3 works

When a client needs to receive a mail:

• If there is no incoming mail server configured, it drops the request .
• If incoming mail server name is not found it tries to resolve the domain name through a DNS query.
• If incoming mail server name is found it gets the IP address
The POP3 client constructs a request POP3 segment and connects the server through TCP sockets and starts a timer for its request.

When an POP3 client receives a packet (flowchart here):

• If the Pop3 message has the Pop3 success codes it indicate that mail has been received successfully and mail/mails are displayed in mail browser
• Else the error message from server is passed to mail browser to display appropriate error message.

When POP3 server receives a request (flowchart here):

• If the SMTP service is enabled, and a TCP connection with the SMTP client is established:
  • Verify the user
  • If User Exist:
  • Fetch the mail/mails from mail server and send to client
  • Else:
  • Send user does not exist error message to client

How TFTP servers process incoming packets

When a TFTP server receives a packet (flowchart here):

• If the packet is a READ request:
  • If the file with the requested name exists on the TFTP server:
    • Start a write session with the client.
  • If the file with the requested name does not exist on the TFTP server:
    • Send back a TFTP ERROR packet to the client.
• If the packet is a WRITE request:
  • Start a read session with the client.
• If the packet is anything else:
  • Drop the packet and stop.

How TFTP servers and clients process incoming packets during a session

When a TFTP server or client receives a packet during a session (flowchart here):

• If the packet is a READ or WRITE request:
  • Drop the packet and stop.
• If the packet is a DATA packet:
  • If the session is a WRITE session or the block number on the packet is not the expecting one:
    • Drop the packet and stop.
  • Save the data on the packet.
  • Send back an ACK packet.
  • Increment the block number.
  • If this is the last packet:
    • Write data to file.
    • Stop the TFTP session.
• If the packet is an ACK packet:
  • If the session is a READ session or the block number on the packet is not the expecting one:
    • Drop the packet and stop.
  • If this is not the last packet:
    • Increment the block number.
    • Send the next block of data in a DATA packet.
  • If this is the last packet:
    • Stop the TFTP session.
• If the packet is an ERROR packet:
  • Stop the TFTP session.

How an SNMP Manager processes a command from the User

When an SNMP Manager processes a command (flowchart here):

• If it is a GET-Request command:
• The SNMP Manager creates an SNMP GET-Request packet and sends to the destination agent.
• If it is a GET-BULK-Request command:
• The SNMP Manager checks against the selected SNMP version and only sends out an SNMP GET-BULK-Request packet if the SNMP version is of version 2 or above.
• If it is a SET-Request command:
• The SNMP Manager creates an SNMP-SET-Request packet and sends to the destination agent.

How an SNMP Manager processes incoming packets

When an SNMP Manager receives an incoming packet (flowchart here):

• It checks if the packet has a correct SNMP header. If it's correct, it goes to the next step. Otherwise, it drops the packet.
• It checks if the timeout from the last sent request to this destination has expired. If it's not expired, it goes to the next step. Otherwise, it drops the packet.
• It checks if the SNMP header contains a correct SNMP PDU. If it's correct, it goes to the next step. Otherwise, it drops the packet.
• It checks if the SNMP PDU is of the SNMP-GET-Response type. If it's correct, it goes to the next step. Otherwise, it drops the packet.
• It checks for the error status of the PDU:
  • If there is an error, it will signal the MIB browser to display the error string. Or the error string can be displayed via the command line.
  • If there is no error:
  • It processes the PDU Variable Bindings in the SNMP PDU.
  • It signals the MIB browser to display the result. Or the result can be displayed via the command line.

How an SNMP Agent processes incoming requests

When an SNMP Agent receives an incoming packet (flowchart here):

• It checks if the packet has a correct SNMP header. If it's correct, it goes to the next step. Otherwise, it drops the packet.
• It checks if it has configured the same community string as in the received SNMP header. If it has the community string configured, it goes to the next step. Otherwise, it drops the packet.
• It checks if the SNMP header contains a correct SNMP PDU.
• From the PDU Variable Binding section in the SNMP PDU, the agent obtains the OID and checks if it has the MIB for this OID.
• Based on the type of the request:
• If it is an SNMP GET-Request, the SNMP Agent obtains the value configured for this OID and sends back an SNMP-GET-Response packet.
• If it is an SNMP GET-BULK-Request, the SNMP Agent obtains the values of all the child OIDs and sends back an SNMP-GET-Response packet.
• If it is an SNMP SET-Request, the SNMP Agent checks the type of the value, and if it is correct, it configures the new value to the device and sends back an SNMP-Get-Response method.

How a Syslog Client works

When a client needs to send a log message to the syslog server (flowchart here):

• If logging is disabled, the syslog client does nothing.
• If logging is enabled:
• If the client has syslog servers (1 - N) configured, it constructs a syslog packet and sends the packet to the configured servers (1- N) over UDP.
• Otherwise, the syslog client does nothing.

How a Syslog Server works

When Syslog server receives a packet (flowchart here):

• If the Syslog server is enabled:
• If the received packet is a valid syslog packet:
• Information from packet is extracted and stored in syslog table.
• If the received packet is not a valid syslog packet, server drops the packet.

How NTP works

When a client needs to update its time from a server:

• If the NTP server address is configured, the NTP client creates and sends a time update request to the NTP server over UPD.

When an NTP server receives a request (flowchart here):

• If the received packet is a valid NTP request:
• The server updates the NTP request packet with current time and other relevant information and sends it back to client over UDP.
• Otherwise, the server drops the packet.

When an NTP client receives a packet (flowchart here):

• If the received packet is not a valid packet, the packet is dropped.
• If authentication is not enabled at the NTP server, and the NTP client or authentication is not enabled at the client but enabled at the server:
• Time is fetched from the packet, and device time is updated with this time.
• Else If the authentication is enabled at the client but not enabled at the server:
• Server authorization is not there, hence the packet is dropped.
• Else (authentication is enabled at the NTP server as well as at the NTP client)
• If key & password are not same for both the client and server:
• It drops the packet, and clock is unsynchronized.
• Else If trusted key is not same for client and server:
• It drops the packet, and clock is unsynchronized.
• Else If key is a valid key:
• Time is fetched from the packet, and device time is updated with this time to make clock synchronized.

How a DNS Client resolves a name to an IP Address

When a domain name resolution process starts, a DNSClient gets the DNS Resolver. The DNS Resolver:

• Creates DNS query packet.
• Generates a random query id and set it in the packet.
• Sets type= A Record.
• Sends the DNS query message to the DNS server over UDP.

The response will be received in the DNS Resolver.

How a DNS Resolver handles receiving messages

When a DNS Resolver receives a message (flowchart here):

• If the packet received is a valid DNS Response packet , it continues else drops the packet.
• It checks if the Query Id matches with the pending request’s Query Id:
• If yes, it continues.
• If not, it drops the packet.
• If this DNS Resolver belongs to a DNS Server (which means, this DNS Resolver is used by a DNS Server for sending secondary queries to servers pointed by the NS records.)
• It deletes the corresponding query from the waiting-query-vector.
• It checks for the condition if the response code = 0 (which means failure) OR if the number of answer Resource Records =0,
• If yes, it adds the query into the failed queries list.
• Else, it adds the answer records to the Cache.
• The DNS Resolver gets the DNS server to which it belongs to and calls the step - SearchDnsRecursively. (This step: gets the name to translate and searches the local Database and Cache. If required, it searches other Name Servers as pointed by the NS records. Then it returns the answers in a result vector.)
• If the step SearchDnsRecursively returns failure:
• The DNS Resolver creates a DNS Error response packet with,
• Response Code=3,
• Number of Answers=0,
• Then, it sends to the waiting client, through the UDP Process.
• Otherwise it continues execution.
• If the step SearchDnsRecursively‘s result Vector size > 0 (which means, the address resolution is success)
• The DNS Resolver creates a DNS Response packet.
• Sets response code=0.
• Adds all the answer records.
• Sets the number of answer records field.
• Sends to the waiting client, through the UDP Process.
• If this Resolver DOES NOT belong to a DNS Server (which means it is functioning as part of a DNS Client)
• If number of answers in the response = 0, the resolver sends an event "name resolution failure" through a callback.
• Else if,
• The resolved IP is present in the answers, the resolver extracts the IP Addresses.
• The resolver sends an event "domain name resolution success" and sends the IP Addresses through a callback.
• Else, the resolver sends an event, "name resolution failure" through a callback.

How a DNS server works

When a DNS server receives a message (flowchart here):

• If the Service is disabled the server drops the message.
• If the Message is an invalid or a non-DNS message ignore it.
• Otherwise,
• The server extracts the DNS query.
• The server calls the step - SearchDnsRecursively. (This step: gets the name to translate and searches the local Database and Cache. If required, it searches other Name Servers as pointed by the NS records. Then it returns the answers in a result vector.)
• If the step SearchDnsRecursively returns Failure
• The DNS Server creates a DNS search failure Message.
• It sets Response Code=3,
• It sets Number of Answer records= 0,
• It sends back to the client.
• If the step SearchDnsRecursively‘s result Vector size > 0
• The DNS Server creates a DNS reply Message.
• It Adds all the answer records. (Which contains the resolved IP Addresses)
• It checks if the answer record is from the local database and if an SOA record is present in the Database:
• If yes, it sets the TTL = minimum TTL Value.
• Otherwise, it sets the TTL=default value.
• The server then sends the reply to the client.

How the step - SearchDNSRecursively works

(flowchart here):

• If the DNS query is in waiting-query-vector,
It returns success and result vector with size=0.
Otherwise
It continues.
• It adds the DNS-query to the waiting-query-vector.
• It searches the Database and the Cache for the queried name. Find all the matching Resource Records (RRs).
• If a matching A-record is found.
It returns success (true) and the result vector, with all matching RRs.
Otherwise
Performs the step - CnameSearchRecursively. (This step tries to resolve the name searching for CNAME records recursively.)
• If a matching A-record is found.
It returns success (true) and the result vector, with all matching RRs .
Otherwise
It performs the step - NSSearchRecursively - (This step searches for NS records, and if required sends query to servers pointed by NS records )
• If the step NSSearchRecursively returns false, (i.e., failed to find a related name server).
It gets the next level domain name ie; parent of the name (unless it reduces to null string) and repeats the same process recursively SearchDnsRecursively
Otherwise
It returns success (true) and result vector of size zero.

How the step - NSSearchRecursively works

(flowchart here):

• If the DNS query is in waiting-query-vector,
It returns failure ( false)
Otherwise
It continues.
• Adds the DNS-query to the waiting-query-vector.
• Searches the Database (DB) and Cache for the queried name. Finds all matching NS - Resource Records (RRs).
• If NO matching NS-record is found.
Reduce the name to next level domain name Ie; parent of the domain name and
Perform the step - NSSearchRecursively.
• If matching NS-record is found,
It adds the NS record to Answer Records Vector
• Iterates through the matching NS records and searches for one which is not in the failed-queries list.
• Perform the step - SearchDnsRecursively for the name pointed by the NS Record. (this is for finding out the IP address pointed by the NS record. This step gets the name-to-translate from NS record. Searches the local Database and Cache and if required searches other Name Servers as pointed by NS records.)
• If the step SearchDnsRecursively returns failure or the result vector size=0,
Returns failure (false) and exits
Otherwise,
If IP is resolved , Get the DNSClient from the owner device. From the DNS client, it sends a new DNS query to the resolved IP (of name server) with the original query.
it returns success/true

How the step - CNAMESearchRecursively works

(flowchart here):

• It searches in the given vector of RRs, for CNAME resource records (RR) matching with the given name.
Lets the result be stored in resultVect.
• If No records found in resultVect,
Returns failure (false)
Returns zero size vector as result.
Otherwise
Gets the first record from resultVect and extract the cname.
Lets name-to-translate=cname
• Performs the step - SearchDnsRecursively for the name-to-translate. (SearchDnsRecursively: It searches the local Database and Cache, and if required, it searches other Name Servers as pointed by NS records for the name-to-translate).
• If the step SearchDnsRecursively returns failure,
It repeats SearchDnsRecursively for next matching CNAME record in the resultVect until no matching records are left in the resultVect.
• If SearchDnsRecursively result Vector size = 0
Returns failure (false).
Returns zero size vector as result.
• Iterates through the result vector search for A-record matching the initial query name.
• If matching RR found,
Returns success (true).
Returns matching RRs in a vector as the result.
Otherwise,
Returns failure (false).
Returns zero size vector as result

How Radius Clients process incoming packets

When a Radius client receives a packet (flowchart here):

• It checks if the received Packet is NOT a valid Radius Packet.
• If yes, it drops the packet
• Otherwise, if the received packet is NOT A response for a pending authentication request.
• If yes, it drops the packet.
• Otherwise, it extracts the Authentication result.
• It checks if the result is Access Accept,
• If yes, it sends the event authentication success to the user module through call back.
• Otherwise
• If the result is Access Reject, it sends event-authentication failure to the user module through call back.
• Otherwise, it sends the event authentication Error to the user module through call back.

How Radius servers process incoming packets

When a Radius Server receives a packet (flowchart here):

• It checks if the radius service is disabled.
• If yes, it drops the packet.
• Otherwise, if the received packet is NOT a valid Radius Packet.
• If yes, it drops the packet.
• Otherwise, it continues.
• The Radius server verifies Client IP-client key matching and client type matching.
• If any of the above NOT matching, it drops the packet.
• Otherwise:
• The Radius server extracts UserName and Password.
• Authenticates.
• Checks if the authentication is success.
• If yes, it creates Access Accept packet and sends back to the client.
• Otherwise, it creates Access Reject packet and sends back to the client.

How Tacacs Clients process incoming packets

When a Tacacs Client receives a packet (flowchart here):

• It checks if the Tacacs service is disabled:
• If yes, it drops the packet.
• Otherwise
• If the received packet is NOT a valid Tacacs Packet, it drops the packet.
• Otherwise, it continues.
• It checks if the TCP connection is NOT in the ESTABLISHED state:
• If yes, it drops the packet.
• Otherwise
• If the packet is NOT a proper reply for a pending request, it drops the packet.
• Otherwise, it extracts the Tacacs packet type:
• If the packet is - user name prompt:
• If yes, it sends the event user name prompt to the client module through the call back.
• If no, it checks if the packet is - Password prompt
• It sends the event password prompt to the client module through the call back.
• If the packet is Authentication Result
• If it is authentication Success, it sends the event Authentication Success to the client module through the call back.
• Otherwise, it sends the event Authentication Failure to the client module through the call back.

How Tacacs servers process incoming packets

When a Tacacs Server receives a packet (flowchart here):

• It checks if the Tacacs service is disabled
• If yes, it drops the packet.
• Otherwise
• If the received packet is NOT a valid Tacacs Packet, it drops the packet.
• Otherwise
• If Client IP-client key not matching or client type does not match:
• The Tacacs server creates an Authentication Reject Packet and sends back to the Client.
• If the packet contains - request for user name prompt
• It gets the UserName Prompt.
• It creates the Reply packet and sends back to the client.
• If the packet contains - request for Password prompt
• It gets Password Prompt .
• It creates the reply packet and sends back to the client.
• If the packet contains - user name, it stores the UserName.
• If the packet contains - password, it authenticates the username and password:
• If Authentication Success, it creates Authentication Accept Packet and sends back to the Client.
• Otherwise, it creates Authentication Reject Packet and sends back to the Client.

How VoIP registration works

When IP phone connected to a configured CME is powered on (flowchart here):

• Initiates a dhcp request
• IP phone receives an ip address. Check if tftp is enabled by default or manually entered. If tftp is not configured
• Ip phone will not register. It will retry in 10 seconds.
• Else if tftp is configured
• Start connecting to server/CME. If connection is not successful,
• Will retry in 10 seconds.
• Else
• Send registration request to server
• Server checks if the MAC is permitted. If NOT permitted,
• Server throws a phone rejected log message
• Phone will retry in 10 seconds
• Else
• Check if CME has a line number available for this phone. If NOT,
• Registration is failed. Close connection
• Will retry in 10 seconds
• Else
• Returns line number and registration ACK to the client/phone.
• Registration successful.

How local call works in VoIP

When IP phone lifts handset and start dialing number, :

• Router receives the number
• Checks in the local directory to find the number. If NOT found,
• Send back “Unknown number” to the client/phone.
• Else if called number is in another call,
• Send back “busy” to the client/caller.
• Else
• Send Sccp Ringermessage to the destination phone.
• Destination phone starts ringing.
• Also send Ringout to the caller phone.
• When destination phone picks up handset,
• Create an RTP port.
• Sends openReceiveChannelAck to the CME with the udp port.
• Caller phone creates udp port and sends openReceiveChannelAck to the CME with this udp port.
• Both phones now start media transmission.

How remote call works in VoIP

When IP phone lifts handset and start dialing number, (flowchart here):

• Router receives the number.
• Sccp session is updated with callstate and incoming/outgoing number
• If dial-peer finds target router for the number,
• Create an RTP port.
• Send H.323 setup message with RTP port to the target router.
• Target router looks up local directory for the dialed number. If NOT found,
• Send back “unknown number” to the client/phone.
• Else if target phone is in another call,
• Send back a “busy” to the source phone.
• Do a release complete of the connection
• Else
• Create RTP port. Send Ringin to the client/phone.
• Send back H.323 callProceeding to the source router/CME with the RTP port created.
• Creates a call information with caller/callee number.
• Call is answered by lifting handset.
• Sends a connect H.323 message to the source router.
• Target phone create another udp port and sends openReceiveChannelAck to the CME with the udp port.
• Source router send openReceiveChannel SCCP message to the caller phone.
• Caller phone creates udp port and sends openReceiveChannelAck to the CME with this udp port.
• Both phones now start media transmission.
• Else if doesn’t find target router
• Send back “unknown number” to the client/phone.