Nov 7, 2008


BFD在我之前準備SP CCIE LAB時就曾經提及過,目前sp ccie lAB中ios vERSION暫時尚未支援此功能,但是這個新功能在未來的r&s OR sp CCIE中應該會是一個很好的題材,因為它可以達到比縮減HELLO TIMER的方式更快速的收歛。



by Ivan Pepelnjak

A few years ago, we measured network convergence times in seconds, and aimed to establish an alternate path across the network following a link or node failure within a few seconds. Ten seconds was a sensible number that wouldn’t upset users (assuming that the failures weren’t too common) and definitely wouldn’t break TCP sessions. (The DLSw local termination would take care of the leftovers of the SNA networks.) The only environments aiming at sub-second convergence times were real-time mission-critical applications, from industrial control to battlefield communications.

The introduction of Voice over IP (VoIP) into the data networks changed the rules completely; the human ear tends to be upset by even a sub-second loss of signal. While the quality-of-service requirements of VoIP deployment are usually well understood (and often implemented quite successfully), the convergence aspects are often forgotten—that is, until the first major failure, when even the proverbial phone doesn’t ring any more.

Until recently, we’ve had to struggle with a patchwork of (frequently proprietary) kludges implemented on top of unreliable data-link layers (for example, frame relay end-to-end keepalives) and routing protocol “solutions” that offered only shortened hello timers. Fortunately, after struggling for more than 25 years with the deficiencies of Layer 2 signaling, major router vendors introduced an interoperable standard protocol aimed exclusively at detecting two-way communication with the next-hop router: Bidirectional Forwarding Detection(BFD).

Introduction to BFD

The Bidirectional Forwarding Detection protocol has a single, well-defined goal: “[P]rovide low-overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data links and (to the extent possible) the forwarding engines themselves” (source: BFD draft specifications).


Forwarding engines are commonly known as routers. The distinction between a router and a forwarding engine is significant only in distributed architectures with physically separate control and forwarding plane; for example, the Gigabit Switch Router (GSR).

The BFD protocol is very similar to the hello mechanisms used in the majority of the routing protocols, with a few significant differences:

BFD tests bidirectional communication. (The EIGRP hello protocol can have problems with unidirectional links.)

BFD packets are small (24 bytes on top of the UDP+IP header) and focused exclusively on path-failure detection. (Routing protocolhello packets perform a number of additional duties.)

In routers with a distributed architecture, BFD packets can be processed on interface modules (see Figure 1), whereas routing protocolhello packets are always processed by the control plane (main CPU).


Distributed platforms run BFD on the line cards


Due to the low overhead, it’s common to use BFD timers in the milliseconds range. (The minimum value accepted by Cisco IOS is 50 milliseconds.)

BFD can rely on control packets (similar to the hello packets used by the routing protocols), or use echo packets (IP packets addressed to the router itself but sent to the Layer 2 address of the next-hop node, as shown in Figure 2) in parallel with control packets. The echo packets thoroughly test the complete bidirectional forwarding path between adjacent routers, as they have to be transmitted by the originating router, propagated to the adjacent router, received by its interface logic, switched by its forwarding engine and sent back to the originator (similar to the way in which GRE keepalives work).

For example, when R1 sends a BFD echo packet in Figure 2, it sets the destination IP address in the packet to its own interface IP address and the MAC address in the Layer 2 frame header to the neighbor’s (R2) MAC address. When R2 receives the packet, it performs a Layer 3 lookup and sends the packet toward its final destination (back to R1).


BFD echo mode

The BFD protocol has no inherent discovery mechanisms to detect adjacent BFD nodes; it’s designed solely as an agent for other applications requiring fast failure-detection. Whenever a routing protocol (or any other application) configured to use BFD detects a new neighbor, it requests availability tracking from the BFD module, as shown in Figure 3. After the BFD session is established with the new neighbor, BFD signals adjacent node failure to the routing protocol, significantly reducing failure-detection time.


OSPF registers its neighbors with BFD

Using BFD in Cisco IOS

As of October 2008, the implementation of BFD on Cisco routers is still somewhat sporadic and depends on the hardware platform you’re using and the software that the platform is running. All modern routing protocols (OSPF, IS-IS, EIGRP and BGP), as well as Hot Standby Router Protocol (HSRP), work with BFD. Some platforms can also use BFD to track the status of static routes.

The hardware support is sketchier: high-end routers (including ASR) running specialized IOS releases (for example, the 12.2 SRC release) support almost anything you might need in the core of your network. Integrated Service Routers (1800 through 3800) support BFD on Ethernet interfaces, but not on serial links. Older low-end routers don’t support BFD at all.


If you want to run BFD on ISRs, use the latest maintenance build of the 12.4(15)T release or a later IOS release.

Configuring BFD is a two-step process:

Step 1.

Configure BFD timers on the interfaces on which you want to use BFD.

Step 2.

Configure routing protocols to use BFD.

Configuring BFD

BFD timers are configured with the bfd interval send-timer mix_rx receive-timer multiplier number interface configuration command. The send-timer specifies the frequency of BFD packets originated by the router, the receive-timer the minimum interval between packets accepted from BFD peers. (BFD adjacency will not form if the send-timer on one peer is lower than the receive-timer on another peer.) The multiplier number is the number of BFD packets that can be lost before the BFD peer is declared “down.”

If you want to use the BFD echo mode, you should configure bfd slow-timers to specify the interval at which the control packets are sent and bfd echo on the interface to enable BFD echo mode.

Listing 1 shows a typical BFD configuration with BFD echo mode.


Typical BFD configuration

bfd slow-timers 3000


interface FastEthernet0/0

 bfd interval 100 min_rx 100 multiplier 3

 bfd echo

Configuring Interior Routing Protocols

After you’ve configured BFD on individual interfaces, you have to tell the routing protocols to use it. In most cases, there’s no good reason that the routing protocols would not use BFD whenever possible; the only command you have to use in these scenarios is the bfd all-interfaces router configuration command. For example, to tell OSPF to use BFD as configured in Listing 1, use the OSPF configuration in Listing 2.


OSPF uses BFD on all interfaces

router ospf 1

 network area 0

 bfd all-interfaces

If you want to be more specific, you could enable BFD on individual interfaces with the specific command for that particular routing protocol (for OSPF, use the ip ospf bfd interface configuration command), as shown in Listing 3.


OSPF uses BFD on Fast Ethernet interface only

interface FastEthernet0/0

 ip address

 ip ospf bfd

 bfd interval 100 min_rx 100 multiplier 3

You could also enable BFD on all interfaces with the bfd all-interfaces router configuration command, and disable it on specific interfaces. (OSPF uses the ip ospf bfd disable interface configuration command.)


You’d disable BFD on an interface only if the interface is flaky but you want to retain routing adjacency across short failures. This shouldn’t be necessary in most well-designed networks.

Using BFD with BGP

BGP can use BFD to detect failure of directly connected neighbors. eBGP or iBGP neighbor failure is detected as long as the neighbor resides on a directly connected subnet. The per-neighbor loss detection is configured with the neighbor fall-over bfd router configuration command. The configuration in Listing 4 uses BFD to detect failures of two BGP neighbors. One is directly connected (even though it uses an iBGP session); the other uses the more common loopback-to-loopback iBGP session.


Using BFD with BGP

interface FastEthernet0/0

 ip address

 bfd interval 100 min_rx 100 multiplier 3


router bgp 65000

 no synchronization

 bgp log-neighbor-changes

 neighbor remote-as 65000

 neighbor fall-over bfd

 neighbor remote-as 65000

 neighbor update-source Loopback0

 neighbor fall-over bfd

 no auto-summary

When the router succeeds in establishing a BGP session with a neighbor configured with BFD failure detection, it tries to register the neighbor’s IP address with BFD. Directly connected neighbors are accepted by BFD. Destinations of multihop BGP sessions are obviously rejected (BFD for multihop paths is not yet supported by Cisco IOS), resulting in a syslog message, as shown in Listing 5.


BFD does not work for multihop BGP neighbors

%BGP-4-BFD_NOT_ONEHOP: BFD is supported for single hop neighbors. is not single hop neighbor

%BGP-5-ADJCHANGE: neighbor Up

BFD in Action

In Figure 4, I’ve set up a very simple lab network to illustrate BFD failure-detection capabilities: two OSPF routers connected over a Fast Ethernet link. I’ve synchronized the times with Network Time Protocol to ensure that the syslog messages will indicate proper chronological order of events.


BFD test network

In this example, I’ve configured BFD on the Fast Ethernet interfaces (remember that BFD doesn’t work on serial interfaces yet on the 2800 series routers) and configured the OSPF routing protocol to use it with the configuration commands from Listing 3. After configuring BFD and OSPF, I’ve used the show bfd neighbor command to check the BFD neighbors (Listing 6).


BFD neighbors registered by OSPF

a1#show ip ospf neighbor

Neighbor ID  Pri  State      Dead Time Address    Interface    0  FULL/  -   00:00:37 Serial0/0/0.100    1  FULL/BDR   00:00:31   FastEthernet0/0

a1#show bfd neighbor

OurAddr    NeighAddr  LD/RD  RH/RS  Holddown(mult)  State  Int    1/2    Up        0    (3 )   Up     Fa0/0

If you want to see which protocols use BFD to detect failure of a particular BFD neighbor, use the show bfd neighbors detailscommand. The printout in Listing 7 indicates that both OSPF and HSRP use BFD to improve neighbor failure-detection times.


BFD is used by OSPF and HSRP

a1#show bfd neighbors details

OurAddr    NeighAddr  LD/RD  RH/RS  Holddown(mult)  State  Int    1/2    Up        0    (3 )   Up     Fa0/0

Session state is UP and using echo function with 100 ms interval.

Local Diag: 0, Demand mode: 0, Poll bit: 0

MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3

Received MinRxInt: 1000000, Received Multiplier: 3

Holddown (hits): 0(0), Hello (hits): 1000(866)

Rx Count: 525, Rx Interval (ms) min/max/avg: 1/23596/923 last: 176 ms ago

Tx Count: 869, Tx Interval (ms) min/max/avg: 1/1000/869 last: 624 ms ago

Elapsed time watermarks: -1 0 (last: 0)

Registered protocols: OSPF HSRP

Uptime: 00:05:59

Last packet: Version: 1            - Diagnostic: 0

             State bit: Up         - Demand bit: 0

             Poll bit: 0           - Final bit: 0

             Multiplier: 3         - Length: 24

             My Discr.: 2          - Your Discr.: 1

             Min tx interval: 1000000    - Min rx interval: 1000000

             Min Echo interval: 100000

Failure Detection with BFD

Without BFD, neighbor failure-detection relies exclusively on OSPF hello timers. A1 thus realized that A2 was no longer available approximately half a minute after I shut down the Fast Ethernet interface on A2 (Listing 8).


Neighbor failure-detection with OSPF

a2(config)#int fa 0/0



17:31:27.347: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down


17:32:01.723: %OSPF-5-ADJCHG: Process 1, Nbr on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired

When using BFD, A1 detected that A2 was no longer reachable long before A2 had time to generate the syslog message indicating that the interface had been disabled (Listing 9).


OSPF neighbor loss-detection with BFD



17:34:10.304: %OSPF-5-ADJCHG: Process 1, Nbr on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached

17:34:12.300: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down


17:34:10.615: %OSPF-5-ADJCHG: Process 1, Nbr on FastEthernet0/0 from FULL to DOWN, Neighbor Down: BFD node down


In this article, you’ve seen how the introduction of Bidirectional Forwarding Detection (BFD) can significantly reduce network convergence time in environments that don’t provide fast link or node failure-detection. BFD enables you to detect hop-by-hop Layer 3 failures in milliseconds without having to fine-tune routing protocol hello timers. The only changes required in the router configuration are the configuration of per-interface BFD parameters with the bfd interval configuration command and the enabling of BFD functionality in the routing protocols with the bfd all-interfaces router configuration command (or a protocol-specific configuration command, if you want to configure BFD only on particular interfaces).

Global Knowledge Releases the Cisco 360 Learning Program for CCIE Routing and Switching to Worldwide Customers


Global Knowledge Releases the Cisco 360 Learning Program for CCIE Routing and Switching to Worldwide Customers

Participation in the Proof-of-Concept and Pilot of the Cisco 360 Learning Program Drives Training Excellence for Those Seeking Cisco's Highest Ranking Certification

Last update: 8:07 a.m. EST Nov. 6, 2008
CARY, N.C. & LONDON & DUBAI, United Arab Emirates, Nov 06, 2008 (BUSINESS WIRE) -- Global Knowledge, the worldwide leader in IT and Business training, today announced the immediate availability of the new Cisco(R) 360 Learning Program for CCIE(R) Routing and Switching for customers in North America and EMEA.
The Cisco 360 Learning Program for CCIE Routing and Switching is designed to accelerate education, training, and certification of networking professionals. Cisco customers' and partners' network engineers will utilize the expert-level training to manage and troubleshoot advanced networks and apply the skills they acquire to achieve the CCIE Routing and Switching certification while providing exceptional value in managing their employers' networks.
"Global Knowledge is proud to be the first Learning Solutions Partner to release the new Cisco CCIE training to the world market," said Joseph Cece, Global Knowledge CEO. "We believe it speaks volumes about our strong and worldwide relationship with Cisco, our global footprint for training, and our proven ability to delivery exceptional training to customers and partners of Cisco who seek to achieve the highest level of Cisco certification," he added.
The Cisco 360 Learning Program for CCIE Routing and Switching offers a mix of e-Learning, classroom learning, remote lab access, and mentoring. "The blended learning approach helps our students acquire skills and ultimately achieve CCIE certification success through the courseware, one-on-one mentoring from industry experts, and specially-designed remote access labs that provide a real-world practice environment for optimal learning," said Richard Pryor-Jones, President, Global Knowledge EMEA.
In the pilot phase, Global Knowledge was appointed by Cisco to support the Global Talent Acceleration Program (GTAP) in Jordan and India by training newly-graduated engineers to become Cisco Technical Assistance Center (TAC) engineers--skills that will enable them to continue their work in TAC centers in Amman and India. "The graduates of our Cisco GTAP program will be the first to enroll in the CCIE 360 Learning Program, a vigorous four-to-six month path to network expertise and CCIE certification, slated to begin as early as November," said Melad Ghabrial, Global Knowledge Managing Director for the Middle East and Africa.
"We're applying our vast resources to deliver this flexible and holistic approach to skills acquisition and, ultimately, certification success for all CCIE candidates," said Michael Fox, Senior Vice President, Global Knowledge. "As a collaborative and supportive Cisco Learning Solutions Partner, we're often tapped to develop new content and courses for students seeking both official Cisco accreditation and professional IT skills development for basic and advanced technologies," he added.
Global Knowledge delivers a full schedule of Cisco courses in more than 14 countries across the US, Canada, and EMEA, Learn more about our Cisco 360 Learning Program for CCIE Routing and or
About Global Knowledge:
Global Knowledge is the largest privately held provider of training and enterprise learning services for information technology (IT) and management professionals. The company offers a broad array of hands-on IT, project management, and professional skills training featuring proprietary core and custom curriculum, as well as content from leading companies, including Cisco, Microsoft, Nortel, and Red Hat. Delivered in classrooms, at private facilities, or over the Internet, Global Knowledge has helped Fortune 500 companies, organizations and government agencies leverage learning to turn knowledge into productivity for employees, customers, and channel partners. Founded in 1995, Global Knowledge employs more than 1,200 people worldwide and is headquartered in Cary, N.C. The company is owned by New York-based investment firm Welsh, Carson, Anderson, and Stowe. For more information, or
SOURCE: Global Knowledge
Global Knowledge  Media Contact -- Corporate  Nancy Enloe, 919-460-3267  or  Media Contact -- MEA  Talal Thabet, + 20 (2) 290-2163  or  Media Contact -- Europe  Rene van der Zeeuw, + 31 (0) 30 60 89 460  
Copyright Business Wire 2008 End of Story

Nov 6, 2008

有線電視、STB 結盟


百一董事長許錦輝昨(5)日參與數位創新服務產業聯盟成立記者會時表示,雖然市況不佳,景氣不明,但STB出貨可望持續成長,成為帶動百一明年成長動能。 記者黃晶琳/攝影台灣五大有線電視多系統經營業者(MSO)中嘉、凱擘、TBC、台固媒體、台灣數位光訊昨(5)日宣布,與電視機上盒(STB)百一、兆赫等攜手成立數位創新服務產業聯盟,未來將積極推動高畫質數位化服務。







Nov 5, 2008

What is a Blue Box?

Blue boxes use a 2600hz tone to size control of telephone switches that use in-band signaling. The caller may then access special switch functions, with the usual purpose of making free long distance phone calls, using the tones provided by the Blue Box.

To quote Karl Marx, blue boxing has always been the most noble form of phreaking. As opposed to such things as using an MCI code to make a free phone call, which is merely mindless pseudo-phreaking, blue boxing is actual interaction with the Bell System toll network. It is likewise advisable to be more cautious when blue boxing, but the careful phreak will not be caught, regardless of what type of switching system he is under.

In this part, I will explain how and why blue boxing works, as well as where. In later parts, I will give more practical information for blue boxing and routing information. To begin with, blue boxing is simply communicating with trunks. Trunks must not be confused with subscriber lines (or "customer loops") which are standard telephone lines. Trunks are those lines that connect central offices.

Now, when trunks are not in use (i.e., idle or "on-hook" state) they have 2600Hz applied to them. If they are two-way trunks, there is 2600Hz in both directions. When a trunk IS in use (busy or "off-hook" state), the 2600Hz is removed from the side that is off-hook. The 2600Hz is therefore known as a supervisory signal, because it indicates the status of a trunk; on hook (tone) or off-hook (no tone). Note also that 2600Hz denoted SF (single frequency) signaling and is "in-band." This is very important. "In-band" means that is within the band of frequencies that may be transmitted over normal telephone lines. Other SF signals, such as 3700Hz are used also. However, they cannot be carried over the telephone network normally (they are "out-of-band" and are therefore not able to be taken advantage of as 2600Hz is. Back to trunks. Let's take a hypothetical phone call. You pick up your phone and dial 1+806-258-1234 (your good friend in Amarillo, Texas).

For ease, we'll assume that you are on #5 Crossbar switching and not in the 806 area. Your central office (CO) would recognize that 806 is a foreign NPA, so it would route the call to the toll centre that serves you. [For the sake of accuracy here, and for the more experienced readers, note that the CO in question is a class 5 with LAMA that uses out-of-band SF supervisory signaling]. Depending on where you are in the country, the call would leave your toll centre (on more trunks) to another toll centre, or office of higher "rank". Then it would be routed to central office 806-258 eventually and the call would be completed. Illustration


A = You
CO1 = Your central office
TC1 = Your toll office.
TC2 = Toll office in Amarillo.
CO2 = 806-258 central office.
B = Your friend (806-258-1234)

In this situation it would be realistic to say that CO2 uses SF in-band (2600Hz) signaling, while all the others use out-of-band signal- ling (3700Hz). If you don't understand this, don't worry. I am pointing this out merely for the sake of accuracy. The point is that while you are connected to 806-258-1234, all those trunks from YOUR central office (CO1) to the 806-258 central office (CO2) do *NOT* have 2600Hz on them, indicating to the Bell equipment that a call is in progress and the trunks are in use.

Now let's say you're tired of talking to your friend in Amarillo, so you send a 2600Hz down the line. This tone travels down the line to your friend's central office (CO2) where it is detected. However, that CO thinks that the 2600Hz is originating from Bell equipment, indicating to it that you've hung up, and thus the trunks are once again idle (with 2600Hz present on them). But actually, you have not hung up, you have fooled the equipment at your friend's CO into thinking you have. Thus, it disconnects him and resets the equipment to prepare for the next call. All this happens very quickly (300-800ms for step-by-step equipment and 150-400ms for other equipment). When you stop sending 2600Hz (after about a second), the equipment thinks that another call is coming towards --> on hook, no tone -->off hook.
Now that you've stopped sending 2600Hz, several things happen:
  1. A trunk is seized.
  2. A "wink" is sent to the CALLING end from the CALLED end indicating that the CALLED end (trunk) is not ready to receive digits yet.
  3. A register is found and attached to the CALLED end of the trunk within about two seconds (max).
  4. A start-dial signal is sent to the CALLING end from the CALLED end indicating that the CALLED end is ready to receive digits.
Now, all of this is pretty much transparent to the blue boxer. All he really hears when these four things happen is a . So, seizure of a trunk would go something like this:
  1. Send a 2600Hz
  2. Terminate 2600Hz after 1-2 seconds
  3. [beep][kerchunk]

Once this happens, you are connected to a tandem that is ready to obey your every command. The next step is to send signaling information in order to place your call. For this you must simulate the signaling used by operators and automatic toll-dialing equipment for use on trunks. There are mainly two systems, DP and MF. However, DP went out with the dinosaurs, so I'll only discuss MF signaling. MF (multi-frequency) signaling is the signaling used by the majority of the inter- and intralata network. It is also used in international dialing known as the CCITT no.5 system. MF signals consist of 7 frequencies, beginning with 700Hz and separated by 200Hz. A different set of two of the 7 frequencies represent the digits 0 thru 9, plus an additional 5 special keys.

The timing of all the MF signals is a nominal 60ms, except for KP, which should have a duration of 100ms. There should also be a 60ms silent period between digits. This is very flexible however, and most Bell equipment will accept outrageous timings. In addition to the standard uses listed above, MF pulsing also has expanded usages known as "expanded in-band signaling" that include such things as coin collect, coin return, ringback, operator attached, and operator attached, and operator released. KP2, code 11, and code 12 and the ST_ps (STart "primes" all have special uses which will be mentioned only briefly here.

To complete a call using a blue box once seizure of a trunk has been accomplished by sending 2600Hz and pausing for the , one must first send a KP. This readies the register for the digits that follow.

For a standard domestic call, the KP would be followed by either 7 digits (if the call were in the same NPA as the seized trunk) or 10 digits (if the call were not in the same NPA as the seized trunk). [Exactly like dialing normal phone call]. Following either the KP and 7 or 10 digits, a STart is sent to signify that no more digits follow. Example of a complete call:
  1. Dial 1-806-258-1234
  2. Wait for a call-progress indication (such as ring, busy, recording, etc...)
  3. Send 2600Hz for about 1 second.
  4. Wait for about ll-progress indication (such as ring, busy, recording, etc...)
  5. Send KP+305+994+9966+ST

The call will then connect if everything was done properly. Note that if a call to an 806 number were being placed in the same situation, the are code would be omitted and only KP + seven digits + ST would be sent. Code 11 and code 12 are used in international calling to request certain types of operators. KP2 is used in international calling to route a call other than by way of the normal route, whether for economic or equipment reasons. STp, ST2p, and ST3p (prime, two prime, and three prime) are used in TSPS (Traffic Service Position System) signaling to indicate calling type of call (such as coin-direct dialing.)

MTU manipulation

以下這篇文章是轉載PacketLife的一篇文章,因為我發現有很多人事實上在準備CCNA/CCNP的過程中有時只著重在筆試的重點上,但是卻忽略了更重要的基礎理論,像這一篇就是介紹MSS(Maximum Segement Size)與MTU(Maximum Transmission Unit)差別,雖然沒有談很多,但是一圖勝過千言萬語,只要把底下那張圖片記在腦海裏,就不會搞不清楚MSS跟MTU的差別了。

Posted by stretch in Networking on Wednesday, 5 Nov 2008 at 2:26 a.m. GMT

The Maximum Transmission Unit (MTU) is the maximum length of data that can be transmitted by a protocol in one instance. For example, the MTU of Ethernet (by default 1500) is the largest number of bytes that can be carried by an Ethernet frame (excluding the header and trailer). MTUs are found at various layers of the OSI model, and can often be tweaked to more efficiently transport large volumes of data.

MTU comparison


The default Ethernet MTU is 1500 bytes, not including the header or trailer. Sometimes a slightly higher MTU is preferable to accommodate Q-in-Q tunneling or other encapsulation. The MTU can be raised on Cisco IOS with the system mtucommand under global configuration:

Switch(config)# system mtu ?   <1500-1998>  MTU size in bytes   
jumbo Set Jumbo MTU value for GigabitEthernet or TenGigabitEthernet interfaces 

The maximum MTU is dependent on the hardware platform, but the IEEE 802.3 standards require a minimum MTU of 1500 bytes. Additionally, a jumbo MTU for 1 Gbps and 10 Gbps interfaces can be allowed up to 9000 bytes. Changing either of these values will require a device power cycle.

Switch(config)# system mtu 1508 
Changes to the system MTU will not take effect until the next reload is done 
Switch(config)# system mtu jumbo 9000 
Changes to the system jumbo MTU will not take effect until the next reload is done 
Switch# show system mtu  
System MTU size is 1500 bytes On next reload, System MTU will be 1508 bytes  
System Jumbo MTU size is 1500 bytes On next reload, System Jumbo MTU will be 9000 bytes 


As with Ethernet frames, the MTU can be adjusted for IP packets. However, the IP MTU is configured per interface rather than system-wide, with the ip mtu command:

Router(config)# interface f0/0 
Router(config-if)# ip mtu ?   <68-1500>  MTU (bytes) 

Notice that the maximum IP MTU is capped at the Ethernet MTU, because it is being applied to an Ethernet interface. The configured IP MTU determines how large a packet to be transmitted out the interface may be. IP packets larger than the MTU are discarded, and may prompt the router to send a Fragmentation Needed ICMP packet back to the source to facilitate path MTU discovery.

It's also worth noting that while the Ethernet and IP MTUs effectively refer to the same section of an IP/Ethernet packet, they can be configured independently. For example, assume we want to shrink the IP MTU of an interface to 1200 bytes:

Router(config)# interface f0/0 
Router(config-if)# ip mtu 1200 

The IP MTU has been modified from its default of 1500:

Router# show ip interface f0/0 
FastEthernet0/0 is up, line protocol is up   
Internet address is   Broadcast address is   Address determined by setup command   MTU is 1200 bytes ... 

However, the interface's Ethernet MTU remains unchanged:

Router# show interface f0/0 FastEthernet0/0 is up, line protocol is up    Hardware is Gt96k FE, address is c200.5867.0000 (bia c200.5867.0000)   
Internet address is   MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,       reliability 255/255, txload 1/255, rxload 1/255 


There are two contexts in which the TCP Maximum Segment Size (MSS) can be configured: transient traffic and terminating traffic.

Transient Traffic

When a TCP client initiates a connection to a server, it includes its MSS as an option in the first (SYN) packet. On an Ethernet interface, this value is typically 1460 (1500 byte Ethernet MTU - 20 byte IP header - 20 byte TCP header).

TCP MSS option

However links beyond the host often have a lower effective MSS and full-size packets from the client may be dropped. To inspect and alter the MSS option included in TCP SYN packets passing through the router, use the ip tcp adjust-msscommand on the interface:

Router(config)# interface f0/0 
Router(config-if)# ip tcp adjust-mss ?   <500-1460>  Maximum segment size in bytes 

Terminating Traffic

Terminating traffic refers to TCP packets which originate from or are destined for the local router (for example, SSH or BGP). In this context, the router itself is considered the TCP client and/or server. The local MSS can be configured with theip tcp mss command under global configuration:

Router(config)# ip tcp mss ?   <68-10000>  MSS 

Google欲收購Skype 網絡電話行業盈利難





  並且,據國外媒體報道, Skype公司可能要被美國Google公司收購。Google開闢的Android手機平台和Skype幾乎完全匹配,可以想象,未來的Google手機,連接上WiFi就能通過Skype以非常便宜的價格進行全球通話。在Google大旗下的Skype的發展模式應該非常明晰:搶占用戶的手機終端,移動無線通信市場是其主攻路線。






My CCNA Voice & CCVP First Step - Voice Over IP Fundamentals

經過一番心情沈澱,又要開始迎接下一個挑戰 - CCNA Voice & CCVP,明年度我的老闆要我盡可能的把所有Voice課程承接起來,其實這對我來說是一個比考SP CCIE更大的挑戰,因為我對Voice實在不熟,所以只能用最原始的方式來了解 - K書。

我看了幾本Cisco Press的書,我覺得只要是Fundamentals系列的書目都是非常值得購買收藏的。雖然我之前曾經教過CVOICE,不過今年CVOICE又改版,把GWGK的東西也整合進來,再加上CCNA Voice的出現,所以我還是決定從頭學習再次打底,明年一定要把Voice課程接下來。

同樣的,我還是會把這個過程利用這個blog紀錄下來跟各位分享,希望各位也可以跟我分享你的know-how。也有人問我,有沒有打算再考第三個CCIE,我想在短時間內(至少明年不會)應該暫時沒有這個打算,除非等我把CCVP/Unity/NetMeeting等相關課程都接下來,我想我才會有那個把握及勇氣去挑戰Voice CCIE吧!

Nov 3, 2008

CCIE#11440's SP CCIE Lab Exam Experience Sharing

我其實沒有想過我還會有第二次機會報告個人的CCIE Lab考試經驗,不過還是很高興地跟大家說,我終於辦到了!

在這個過程中最需要感謝的還是brook兄,沒有他跟我一起co-work共同討論,互相挑戰彼此對同一個題目不同看法不同的solution真的讓我們彼此的功力在短時間內快速增長,我是無法這麼順利完成這個目標的! 當然還有我辛苦的老婆一個人24 hrs帶著兩個小朋友,讓我幾乎完全沒有後顧之憂(過去一年以來,除了假日之外,我每天回到家的時間平均是PM 11:00~11:30左右...,還好我兒子們還認得我是他們老爸...),希望這段話可以稍稍安撫我老婆的辛苦及她對我及這個家庭無私的奉獻。


準備Service Provider CCIE Lab最重要的當然是以Routing & Switching為基礎,所以我在此不會強調Routing & Switching的部份,我會把重心放在MPLS/BGP/Multicast上。我會建議所有要準備考SP CCIE的candidates都應該至少要把CCIP - BGP/MPLS/QoS這幾科熟讀,因為它們是SP最基本的功夫,不用我多說,很多人會想直接進入主軸去看WB or 考古題,我個人的建議是不要急躁,因為你會因此而常常回頭看基礎理論反而更沒效率…

1. Cisco Press - MPLS Configuration on Cisco IOS Software *
2. Cisco Press - MPLS and VPN Architectures Vol.I & II
3. Cisco Press - MPLS Fundamentals *
4. Cisco Press - Routing TCP/IP Volume I & II *
5. Cisco Press - Advanced MPLS Design and Implementation
6. Cisco Press - Traffic Engineering with MPLS
7. Cisco Press - BGP Design and Implementation *
8. Cisco Press - Definitive MPLS Network Designs
9. Cisco Press - Cisco ISP Essentials
10. Cisco Press - Cisco BGP-4 Command and Configuration Handbook
11. Cisco Press - Interdomain Multicast Solutions Guide *
12. Addison-Wesley - OSPF and IS-IS: Choosing an IGP for Large-Scale Networks(Jeff Doyle)
13. Addison-Wesley - Interdomain Multicast Routing: Practical Juniper Networks and Cisco Systems Solutions
14. Internetwork Expert WB Vol.I & II
15. IPExpert WB Vol.I & II

。Internetwork Expert SP CCIE Lab CoD *

* 以上強烈建議至少熟讀過一遍以上

其中的Internetwork Expert & IPExpert WB個人認為是最後衝剌前的最好教材,因為它cover了許多歷來曾經出現過feature及main point,還有許多你可能從來沒有留意到的特殊指令及功能,如果可以的話,最好擇一走過整份教材一遍。

Internetwork Expert CoD的教材個人認為相當的深入,對於了解整個SP CCIE Lab的範圍可以有個大致上的概念,不過美中不足的是在DEMO設定時,因為設定的速度很快,而且是在好幾個Router之間切換,很容易就會搞不清楚講師在設定的內容是那些部份,大部份是節錄重點設定,而非從頭到尾的configuration,一不小心分心就會忘了設定的重點。所以看這一份CoD的教材最適合在熟讀所有教材之後,準備練習Lab之間的階段。

。OSPF NBMA/Authentication
。OSPF Network Type/Neighbor Adjacency(Timer/MTU issue)
。ISIS L1/L2 area/routes redistribution
。ISIS Authentication(under interface or ISIS process, clear-text vs md5 password))
。ISIS Multi-Process(more than one NET address per router)
。IGP convergence method(under interface or IGP process)

。Weight/Local Preference/AS-Path/Metric的意義及控制路由的方向性
。Next-Hop-Self vs Next-Hop-Unchanged
。MPLS VPN Route Propagation in BGP
。Standard/Extension Community propagation(SOO, RT)
。send-label, match mpls-label, set mpls-label Command
。Fast Convergence
。Dual-AS BGP
。ORF(Outbound Route Filter)
。BGP Policy Accounting
。RTBH(Remote Trigger Black Hole)

。Frame-Relay FRTS & FECN/BECN/DE bits
。MPLS EXP(value 0~7) vs IP Precedence(value 0~7) vs qos-group
。DSCP(AF/CS/EF class, value 0~63)

。ip pim sparse-mode
。Static RP/Auto-RP/BSR-RP
。MPLS VPN Multicasting(MDT)
。Inter-Domain Multicast(MSDP)

。Event Manager
。SNMP Trap/Log
。MAC ACL/Rate-Limit
。CoPP(Control Plane Protection)

◎MPLS是整個SP CCIE Lab的最重要部份,我想沒有什麼特別的重點,重點就是請把以上我列出來的書目熟讀並且多加練習。
。CE-PE之間IGP交換、PE上的VPN Router Redistribution、PE-PE之間的MP-BGP
。AToM(Any Transport over MPLS)
。PPPoE(PPP over Ethernet)/L2TP
。EoMPLS(Ethernet over MPLS)
。Inter-Domain MPLS Label propagation(Option 1,2,3,4)
。MPLS over ATM
。VPN RD/RT import/export and VPN route filter
。Traffic Engineering
。OSPF Sham-Link
。BGP AS-override/Allowas-in
。EIGRP/BGP SOO Loop Prevention