Thank you to all those who have submitted questions and comments to our blog and our CCIE Instructors. If you have a question, please email them to blog@ine.com.
Question 1:
Hi,
Is it possible to recommend the Cisco press books to read when preparing for the Cisco SP Written exam.
Kind Rages
For the written exam, you should make sure you have reviewed the items in the online resources General, Metro Ethernet, and Service Provider sections for the Written Exam Blueprint preparation material.
http://www.cisco.com/web/learning/le3/ccie/sp/online_resources.html
As far as additional books, I recommend reviewing the books in the following sections of the book list: Cisco Press Titles, MPLS, Service Provider.
http://www.cisco.com/web/learning/le3/ccie/sp/book_list.html
I would also recommend the Cisco Press book titled "MPLS Configuration on Cisco IOS".
Other than books, there are a number of RFCs and other related resources which can be found online.
Answer by: Marvin Greenlee, CCIE #12237
Question 2:
I would very much appreciate if someone could cover this issue for me. I have asked a few times now but never seen anything back on it?
It's regarding MTU:
I would like to know:
How can you tell if you have an MTU Issue
Normally you see your TCP based application getting "stuck" on large transfers. Essentially, the problem only affects transfers that are over MTU size. Most TCP implementations have Path MTU discovery procedure, which uses cetain ICMP message types. Often, these messages are blocked by firewalls (corporate or personal) which breaks Path MTU discover process.
What is the full impact of an MTU Issue as experienced by end users?
TCP based applications that involve bulk transfers stop working. For example, you would be able to establish an FTP connection but the file transfer will be stalled.
How should the network devices be configured and tested to see that all is ok (Marvin touched on it in a video and that was great - but if we could have a little more detail please)
You normally having problems if you are using any sort of tunneling in your network (e.g. MPLS, GRE, QinQ etc). They all reduce maximum MTU and may cause the problems. Use any command line tools to discover the MTU end-to-end, e.g. tracepath command on Linux: http://linux.die.net/man/8/tracepath . Normally, if you are using any tunneling in your routers, make sure you apply the "ip tcp adjust-mss" command. This will resolve practically all problems, though at the expense of some CPU cycles. In many cases it's easier then going around and fixing interface MTU settings, especially if you have to call your ISP for that :)
Isn't there a lot of different MTU settings i.e. Global, TCP, Interface, L2/L3 etc?? What is the differences?
In general, MTU applies to L2 and L3 protocols, as those are normally frame/packet oriented.
For Ethernet switches, it's normally a global setting that applies to all Gigabit Interfaces (100Mbps Ethernet does not support large MTUs with some exceptions). For routers, you normally have basic interace MTU settings (L2, mtu command) and IP MTU (ip mtu). It's like a russian-doll model, lower level MTU should be larger than higher-level one. TCP has the notion of MSS, but this is slightly different from MTU - it's and end-to-end characteristic, negotiated by TCP at the start of the connection.
I noticed that if you have MTU set correctly end-to-end you should be able to ping with any packet size (within reason) and it works fine, but if there is a slight mismatch anywhere your ping packets will fail at a certain size! Why is this happening, and why does it work fine then when they match up, is this to do with Fragmentation or something similar???
Right, the router that has lower MTU would drop the exceeding ICMP packets if they have DF bit set. Your best tool for end-to-end MTU discovery would be tracepath utility. Also, just keep in mind that as soon as you are using any tunneling technique in your network you are most likely to run in the problem :)
Would very much appreciate any help with this issue...
Best Regards,
Ian.
I would very much appreciate if someone could cover this issue for me. I have asked a few times now but never seen anything back on it?
Ir's regarding MTU:
I would like to know:
> . How can you tell if you have an MTU Issue
Normally you see your TCP based application getting "stuck" on large transfers. Essentially, the problem only affects transfers that are over MTU size. Most TCP implementations have Path MTU discovery procedure, which uses cetain ICMP message types. Often, these messages are blocked by firewalls (corporate or personal) which breaks Path MTU discover process.
> . What is the full impact of an MTU Issue as experienced by end users?
TCP based applications that involve bulk transfers stop working. For example, you would be able to establish an FTP connection but the file transfer will be stalled.
> . How should the network devices be configured and tested to see that all is ok (Marvin touched on it in a video and that was great - but if we could have a little more detail please)
You normally having problems if you are using any sort of tunneling in your network (e.g. MPLS, GRE, QinQ etc). They all reduce maximum MTU and may cause the problems. Use any command line tools to discover the MTU end-to-end, e.g. tracepath command on Linux: http://linux.die.net/man/8/tracepath . Normally, if you are using any tunneling in your routers, make sure you apply the "ip tcp adjust-mss" command. This will resolve practically all problems, though at the expense of some CPU cycles. In many cases it's easier then going around and fixing interface MTU settings, especially if you have to call your ISP for that :)
> . Isn't there a lot of different MTU settings i.e. Global, TCP, Interface, L2/L3 etc?? What is the differences?
In general, MTU applies to L2 and L3 protocols, as those are normally frame/packet oriented.
For Ethernet switches, it's normally a global setting that applies to all Gigabit Interfaces (100Mbps Ethernet does not support large MTUs with some exceptions). For routers, you normally have basic interace MTU settings (L2, mtu command) and IP MTU (ip mtu). It's like a russian-doll model, lower level MTU should be larger than higher-level one. TCP has the notion of MSS, but this is slightly different from MTU - it's and end-to-end characteristic, negotiated by TCP at the start of the connection.
> . I noticed that if you have MTU set correctly end-to-end you should be able to ping with any packet size (within reason) and it works fine, but
> if there is a slight mismatch anywhere your ping packets will fail at a certain size!
> Why is this happening, and why does it work fine then when they match up, is this to do with Fragmentation or something similar???
Right, the router that has lower MTU would drop the exceeding ICMP packets if they have DF bit set. Your best tool for end-to-end MTU discovery would be tracepath utility. Also, just keep in mind that as soon as you are using any tunneling technique in your network you are most likely to run in the problem :)
Would very much appreciate any help with this issue...
Best Regards,
Ian.
Answer by: Petr Lapukhov, CCIE #16379
Question 3:
Hi,
I have a question which is troubling me a lot these days during my work.. 1)
What is the difference between Process Switching, Fast Switching and CEF (
have browsed the whole internet but not getting in my head :( )
2) How does the bandwidth statement work in WRED. Please please please
reply...
Warm Regards,
Khan
Hello Khan and thank you so much for actively participating in our Blog site!
1) Let’s walk through the technologies of Process Switching, Fast Switching, and Cisco Express Forwarding as well as Distributed CEF in plain English! Once you go through this material, I recommend you read this document from Cisco that I used as a basis for my response. This article should make perfect sense to you following our discussion here:
(http://www.cisco.com/en/US/docs/ios/12_2/switch/configuration/guide/xcfovips.html)
In order to move traffic from network to network in your infrastructure, a router or multilayer switch engages in two overall, inter-related functions – routing and switching. I am sure you understand the routing piece very well…this is where we typically have a dynamic routing protocol at work (such as OSPF), and this protocol helps build a routing table that is consulted to determine the best path to reach a prefix through the network. In the case of OSPF, this best path determination defaults to using bandwidth as the ultimate determining factor in best pathing.
Where students tend to get confused is in the many flavors of switching that are possible on the device:
- Process switching
- Fast switching
- CEF
- dCEF (Distrbuted CEF)
First of all, switching on the device involves taking the frame and moving it as quickly as possible from the input interface to the output interface. The switching process also needs to worry about the layer 2 addressing. We will focus here on Ethernet, so the switching process is concerned with addressing the frame with the correct MAC address. As you know, the switching process relies on ARP and the ARP cache to obtain this information.
Process switching is considered the least efficient method of switching on the device. And to think that there was a time where this was all we had! With process switching, the device copies the packet into a system buffer, the route processor then looks up the IP address in the routing table. The frame is then rewritten with the correct destination MAC address and switched to the correct outgoing interface. It is the job of the route processor to calculate the cyclical redundancy check to make sure the frame was not damaged in this procedure.
With Fast Switching, the information required to route and switch the traffic is all stored in a fast-switching cache. In addition to this faster approach, the interface’s processor is able to calculate the CRC, which adds even more to the efficiency of the procedure.
With Cisco Express Forwarding, we have even more efficiency! Now the route processor is building everything it needs to handle the routing and switching of traffic right in memory. The routing table is parsed and stored in memory as something called the Forwarding Information Base (FIB) and the ARP Cache information is stored in what is called the Adjacency Table.
Stepping up the efficiency one more notch – some devices are capable of dCEF. With this approach, the line cards installed in the multilayer switch are capable of doing the CEF right there at the line card level! Wow – more speed.
As you might guess, all devices from Cisco now are defaulting to the CEF mode of operation to provide the greatest performance levels possible right “out of the box”.
2) Hmmm – there is no bandwidth command in WRED that I am aware of…I think you might be confusing two different QoS features here. And both can be used in conjunction with each other…that is probably what you have seen. The bandwidth command is used in the configuration of Class-Based Weighted Fair Queuing to guarantee a minimum amount of bandwidth during times of congestion. While this is cool, the default Congestion Avoidance approach in the queue is Tail Drop. This can be changed by adding WRED (with the random-detect command) to the CBWFQ configuration.
