Category Archives: 01) CCIE V5

1.1.e Explain TCP operations

i was actually asked this once in a phone interview. name four of the six flags in a tcp stream…

syn, ack, fin, right?

then radio silence. dammit.

one might argue this is almost trivia but that would be dismissive. of course he was reading from a cheat sheet while i was relying on my early onset alzhiemer’s. the cobwebs pile up.

and rust never sleeps. to review, thanks to the wonderful site:

http://www.firewall.cx/networking-topics/protocols/tcp/136-tcp-flag-options.html

Let’s take a look at the TCP flags field to begin our analysis:

tcp-analysis-section-4-1

You can see the 2 flags that are used during the 3-way handshake (SYN, ACK) and data transfers.

As with all flags, a value of ‘1’ means that a particular flag is ‘set’ or, if you like, is ‘on’. In this example, only the “SYN” flag is set, indicating that this is the first segment of a new TCP connection.

In addition to this, each flag is one bit long, and since there are 6 flags, this makes the Flags section 6 bits in total.

You would have to agree that the most popular flags are the “SYN”, “ACK” and “FIN”, used to establish connections, acknowledge successful segment transfers and, lastly, terminate connections. While the rest of the flags are not as well known, their role and purpose makes them, in some cases, equally important.

We will begin our analysis by examining all six flags, starting from the top, that is, the Urgent Pointer:

1st Flag – Urgent Pointer

The first flag is the Urgent Pointer flag, as shown in the previous screen shot. This flag is used to identify incoming data as ‘urgent’. Such incoming segments do not have to wait until the previous segments are consumed by the receiving end but are sent directly and processed immediately.

An Urgent Pointer could be used during a stream of data transfer where a host is sending data to an application running on a remote machine. If a problem appears, the host machine needs to abort the data transfer and stop the data processing on the other end. Under normal circumstances, the abort signal will be sent and queued at the remote machine until all previously sent data is processed, however, in this case, we need the abort signal to be processed immediately.

By setting the abort signal’s segment Urgent Pointer flag to ‘1’, the remote machine will not wait till all queued data is processed and then execute the abort. Instead, it will give that specific segment priority, processing it immediately and stopping all further data processing.

If you’re finding it hard to understand, consider this real-life example:

At your local post office, hundreds of trucks are unloading bags of letters from all over the world. Because the amount of trucks entering the post office building are abundant, they line up one behind the other, waiting for their turn to unload their bags.

As a result, the queue ends up being quite long. However, a truck with a big red flag suddenly joins the queue and the security officer, whose job it is to make sure no truck skips the queue, sees the red flag and knows it’s carrying very important letters that need to get to their destination urgently. By following the normal procedures, the security officer signals to the truck to skip the queue and go all the way up to the front, giving it priority over the other the trucks.

In this example, the trucks represent the segments that arrive at their destination and are queued in the buffer waiting to be processed, while the truck with the red flag is the segment with the Urgent Pointer flag set.

A further point to note is the existence of theUrgent Pointer field. This field is covered in section 5, but we can briefly mention that when the Urgent Pointer flag is set to ‘1’ (that’s the one we are analysing here), then the Urgent Pointer field specifies the position in the segment where urgent data ends.

2nd Flag – ACKnowledgement

The ACKnowledgement flag is used to acknowledge the successful receipt of packets.

If you run a packet sniffer while transferring data using the TCP, you will notice that, in most cases, for every packet you send or receive, an ACKnowledgement follows. So if you received a packet from a remote host, then your workstation will most probably send one back with the ACK field set to “1”.

In some cases where the sender requires one ACKnowledgement for every 3 packets sent, the receiving end will send the ACK expected once (the 3rd sequential packet is received). This is also called Windowing and is covered extensively in the pages that follow.

3rd Flag – PUSH

The Push flag, like the Urgent flag, exists to ensure that the data is given the priority (that it deserves) and is processed at the sending or receiving end. This particular flag is used quite frequently at the beginning and end of a data transfer, affecting the way the data is handled at both ends.

When developers create new applications, they must make sure they follow specific guidelines given by the RFC’s to ensure that their applications work properly and manage the flow of data in and out of the application layer of the OSI model flawlessly. When used, the Push bit makes sure the data segment is handled correctly and given the appropriate priority at both ends of a virtual connection.

When a host sends its data, it is temporarily queued in the TCP buffer, a special area in the memory, until the segment has reached a certain size and is then sent to the receiver. This design guarantees that the data transfer is as efficient as possible, without waisting time and bandwidth by creating multiple segments, but combining them into one or more larger ones.

When the segment arrives at the receiving end, it is placed in the TCP incoming buffer before it is passed onto the application layer. The data queued in the incoming buffer will remain there until the other segments arrive and, once this is complete, the data is passed to the application layer that’s waiting for it.

While this procedure works well in most cases, there are a lot of instances where this ‘queueing’ of data is undesirable because any delay during queuing can cause problems to the waiting application. A simple example would be a TCP stream, e.g real player, where data must be sent and processed (by the receiver) immediately to ensure a smooth stream without any cut offs.

A final point to mention here is that the Push flag is usually set on the last segment of a file to prevent buffer deadlocks. It is also seen when used to send HTTP or other types of requests through a proxy – ensuring the request is handled appropriately and effectively.

4th Flag – Reset (RST) Flag

The reset flag is used when a segment arrives that is not intended for the current connection. In other words, if you were to send a packet to a host in order to establish a connection, and there was no such service waiting to answer at the remote host, then the host would automatically reject your request and then send you a reply with the RST flag set. This indicates that the remote host has reset the connection.

While this might prove very simple and logical, the truth is that in most cases this ‘feature’ is used by most hackers in order to scan hosts for ‘open’ ports. All modern port scanners are able to detect ‘open’ or ‘listening’ ports thanks to the ‘reset’ function.

The method used to detect these ports is very simple: When attempting to scan a remote host, a valid TCP segment is constructed with the SYN flag set (1) and sent to the target host. If there is no service listening for incoming connections on the specific port, then the remote host will reply with ACK and RST flag set (1). If, on the other hand, there is a service listening on the port, the remote host will construct a TCP segment with the ACK flag set (1). This is, of course, part of the standard 3-way handshake we have covered.

Once the host scanning for open ports receives this segment, it will complete the 3-way handshake and then terminate it using the FIN (see below) flag, and mark the specific port as “active”.

5th Flag – SYNchronisation Flag

The fifth flag contained in the TCP Flag options is perhaps the most well know flag used in TCP communications. As you might be aware, the SYN flag is initialy sent when establishing the classical 3-way handshake between two hosts:

tcp-analysis-section-4-2

In the above diagram, Host A needs to download data from Host B using TCP as its transport protocol. The protocol requires the 3-way handshake to take place so a virtual connection can be established by both ends in order to exchange data.

During the 3-way handshake we are able to count a total of 2 SYN flags transmitted, one by each host. As files are exchanged and new connections created, we will see more SYN flags being sent and received.

6th Flag – FIN Flag

The final flag available is the FIN flag, standing for the word FINished. This flag is used to tear down the virtual connections created using the previous flag (SYN), so because of this reason, the FIN flag always appears when the last packets are exchanged between a connection.

It is important to note that when a host sends a FIN flag to close a connection, it may continue to receive data until the remote host has also closed the connection, although this occurs only under certain circumstances. Once the connection is teared down by both sides, the buffers set aside on each end for the connection are released.

CCNP SWITCH 300-115 2.1 Configure and verify switch security features

2.1.a DHCP snooping

In this segment we will cover DHCP, as well as DHCP Snooping. It seems the blueprint is remiss in mentioning DHCP in its own line item so we will briefly cover it here as you cannot have DHCP Snooping without DHCP.

DHCP is easy enough; there are only 2 requirements for it so long as you are using a single subnet, as we will do here for the sake of simplicity. The minimum requirements call for a default-router and a DHCP network for address assignment. You could establish a lease period, DNS, and many other delimiters,  but they are not minimum requirements. It is a good idea to include a domain-name but usually that has already been configured.

DHCP is the Dynamic Host Configuration Protocol. It eases administration by allowing clients to broadcast for Ip addresses and a default gateway, among other parameters. A lot easier than statically configuring a bunch of windows or linux boxes in any size environment. The usual method is for a dedicated server to handle the chore, but Cisco was kind enough to include it in its routers and switches, and on it’s exams.

So the first step  will be to set up a DHCP server. Keep in mind the acronym DORA, dis, off, req, ack and you can easily memorize the dhcp process. Discover, Offer, Request, Acknowledge.

Option 82 or the information option is a player in the VIRL canvas. Option 82 is turned on by default and does further fact checking for validity on untrusted ports especially in the case of relays. We can avoid this by turning off option 82 at the switch, or by enabling option 82 on the access ports, the untrusted ports, however, here we will turn it off on the switch. You can find out more detail about option 82 on the internet, in fact Petr Lapukhov has a great article about it on his INE blog. Just do a search for “option 82 Petr” and that should be your first hit.

Let’s get down to configuration.

Now that we have DHCP in place and operational, we can talk about DHCP Snooping. DHCP Snooping is designed to disallow rogue DHCP servers from inhabiting your network and dishing out false Ip addresses and gateways to your clients. This is performed by establishing a trust between authorized devices and thereby building a reference database for cross checking. Remember, only untrusted connections will be leased ip addresses and assigned to the snooping database, along with their associated mac’s and vlan’s. It is vital to understand that trusted connections are established between server and switch or router and switch or switch and switch, not switch and access ports.

There are three essential items to get DHCP Snooping operational. Of course there are other options but we will discuss the minimum. They
are:

Turn on dhcp snooping

turn on dhcp snooping for the Vlan or Vlan’s

and establish trust between the server and switch.

here we go:

VIDEO

https://www.youtube.com/watch?v=_pRDz-B_O8U

 

 

Upcoming changes to CCIE V5 written blueprint

it just got bigger…

https://learningnetwork.cisco.com/community/ccie-enhancements?utm_campaign=Promo-CCIENextGen&utm_source=CLN-Newsletter&utm_medium=link&mkt_tok=3RkMMJWWfF9wsRols6XMZKXonjHpfsX57OspUaC%2FgIkz2EFye%2BLIHETpodcMScNqM6%2BTFAwTG5toziV8R7XDKM130sMQWBPh

coming to a testing center near you july 2016

Evolving Technologies Domain

1. Cloud

1.1: Compare and contrast Cloud deployment models

•  Infrastructure, platform, and software services (XaaS)

•  Performance and reliability

•  Security and privacy

•  Scalability and interoperability

1.2: Describe Cloud implementations and operations

• Automation and orchestration

• Workload mobility

• Troubleshooting and management

•  OpenStack components

2. Network Programmability

2.1: Describe functional elements of network programmability (SDN) and how

they interact

•  Controllers

•  APIs

•  Scripting

•  Agents

•  Northbound vs. Southbound protocols

2.2: Describe aspects of virtualization and automation in network environments

•  DevOps methodologies, tools and workflows

•  Network/application function virtualization (NFV, AFV)

•  Service function chaining

•  Performance, availability, and scaling considerations

3. Internet of Things

3.1: Describe architectural framework and deployment considerations for Internet of Things (IoT)

•  Performance, reliability and scalability

•  Mobility

•  Security and privacy

•  Standards and compliance

•  Migration

•  Environmental impacts on the network

resources

https://learningnetwork.cisco.com/docs/DOC-29253

Reference Material for Evolving Technology section

Created by Madhukar: Cisco Team on Nov 3, 2015 4:01 PM. Last modified by Madhukar: Cisco Team on Nov 18, 2015 1:49 PM.

Cisco Press books

Reference URLs

Cisco Live presentations

CCIE Community Events

Cisco DevNet

Recommended Courses