Facebook is a Bad Investment

Nasdaq is receiving a lot of bad press regarding the Facebook IPO and problems with their trading platform. Some of this is justified because the IPO was interrupted and trades were not executed or cancelled successfully, but ultimately it is not the cause of Facebook's meltdown in the open market. The bottom line is that Facebook is a bad investment and it was never worth the initial valuation of $100 billion. At the time of this writing, FB has lost more than 20% of its value since the IPO started.

There are a lot of people in the world that like Facebook as a social media platform. It has an immense customer base including individuals, governments, and organizations. Many companies regularly use Facebook in their marketing and work to socially connect their companies with customers. Facebook also develops a lot of ad impressions and has taken steps to build a platform that developers can use to make money. Many pages have a "like"button or functionality to share something on Facebook. For all that it provides, Facebook fails the test of both long term and short term ability to serve shareholders (both from a growth and income standpoint).

Facebook launched its IPO in both a declining profit and declining revenue scenario. Facebook, as a product, is in its decline stage (and it reached a peak a couple of years ago). Although people will continue to use it, it will become easier for competitors to chip away at Facebook's regular user base. Coupled with Facebook's horrific ad performance and their lack of partnership with other organizations with regard to its demographic data, this spells a long term underperforming stock and an almost permanent sell (or short sell) rating.

When you look at Facebook compared to other technology giants (like Apple, Google, and Microsoft), ask "What is Facebook actually selling?" Right now, they are selling underperforming ad space and a couple of digital products with limited marketability. They have no real long term product offerings and their sources of revenue are difficult to imagine without Facebook compromising customer privacy.

Ultimately, individuals and organizations need to communicate with their financial professionals to determine the suitability of any investment for their portfolio. My opinion of Facebook is that they are a strong sell (and a never buy), but we'll see if the market proves me wrong.

Frame Relay Switching Lab Using Multiple Switches (Tunnels)

Frame Relay is an important exam topic in the CCNA (mostly ICND2 exam), CCNP, and CCIE certifications for the routing and switching track. This post builds on the frame relay switching post that showed configuration of partially meshed and fully meshed permanent virtual circuits (PVCs). There are a lot of examples that show how to configure a single router as a frame-relay switch, but very few that show how to configure multiple provider devices to enable an end-to-end frame relay network. This lab, built in GNS3/Dynamips, demonstrates 2 customers being connected using a provider network with an IP backbone and frame-relay switching on the edge devices. Configurations shown are Cisco 3725 routers running  Cisco IOS 12.4(15)T7.

The topology below shows the entire network as it has been configured. PE1 and PE2 perform frame-relay switching for Customer 1 (Cust1) and Customer 2 (Cust2). The connections between PE1, P, and PE2 utilize HDLC (Cisco's default for serial interfaces) and IP. The internal provider (P) router has no knowledge of any of the frame relay configuration on the provider edge routers (PE1 and PE2). The provider network runs OSPF to maintain internal IP connectivity. A GRE-IP tunnel is configured between PE1 and PE2 to encapsulate the frame-relay packets as they cross the frame relay cloud.


The main interesting points of configuration exist on the provider network routers: PE1, P, and PE2. The simplest configuration is on the P router where the IP addresses and routing protocol (OSPF in this case) are configured:

interface Serial0/0
 ip address 172.16.1.2 255.255.255.252
!
interface Serial0/1
 ip address 172.16.2.2 255.255.255.252
!
router ospf 1
 log-adjacency-changes
 network 172.16.0.0 0.0.255.255 area 0
!

On router PE1, we perform some frame-relay configuration for the customer interfaces and specify that the frame-relay encapsulated frames should be tunneled. Customer 1 and 2 have a single point-to-point PVC defined between the customer edge routers connecting to PE1 and PE2:

!
frame-relay switching
!
interface Serial0/1
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 100 interface Tunnel0 200
!
interface Serial0/2
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 150 interface Tunnel0 300
!

We also configure one side of the GRE-IP tunnel:

interface Tunnel0
 no ip address
 tunnel source 172.16.1.1
 tunnel destination 172.16.2.1
!

Note that since GRE-IP is the default tunnel mode, the tunnel mode gre ip command is not necessary. Finally, the internal provider connection and the routing protocol are configured. If multiple paths existed between PE1 and PE2, a tunnel source using a loopback interface would be appropriate, but this case does not require loopback interfaces. Additionally, with the different tunnel choices, GRE over IP or GRE over IPv6 are the main tunnel types that will work for encapsulating frame relay over IP.

PE1(config-if)#tunnel mode ?
  aurp    AURP TunnelTalk AppleTalk encapsulation
  cayman  Cayman TunnelTalk AppleTalk encapsulation
  dvmrp   DVMRP multicast tunnel
  eon     EON compatible CLNS tunnel
  gre     generic route encapsulation protocol
  ipip    IP over IP encapsulation
  ipsec   IPSec tunnel encapsulation
  iptalk  Apple IPTalk encapsulation
  ipv6    Generic packet tunneling in IPv6
  ipv6ip  IPv6 over IP encapsulation
  mpls    MPLS encapsulations
  nos     IP over IP encapsulation (KA9Q/NOS compatible)
  rbscp   RBSCP in IP tunnel


Here we can finish the discussion of PE1's configuration with its connection into the provider cloud and its routing protocol configuration:

!
interface Serial0/0
 ip address 172.16.1.1 255.255.255.252
!
router ospf 1
 log-adjacency-changes
 network 172.16.0.0 0.0.255.255 area 0
!


The configuration is very similar on PE2. From the customer's perspective we are using global DLCI addressing:

!
frame-relay switching
!
interface Tunnel0
 no ip address
 tunnel source 172.16.2.1
 tunnel destination 172.16.1.1
!
interface Serial0/0
 ip address 172.16.2.1 255.255.255.252
!
interface Serial0/1
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 150 interface Tunnel0 300
!
interface Serial0/2
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay intf-type dce
 frame-relay route 100 interface Tunnel0 200
!
router ospf 1
 log-adjacency-changes
 network 172.16.0.0 0.0.255.255 area 0
!

Verification of the setup from the customer side is easy, if traffic flows, then the PVC is working:

Cust1_CE1(config-subif)#do ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/37/112 ms

We can also see that the PVC is active and assigned:

Cust1_CE1(config-subif)#do show frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.100

  input pkts 104           output pkts 106          in bytes 31197
  out bytes 31863          dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 91        out bcast bytes 30303
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 01:32:24, last time pvc status changed 01:31:54


On the provider routers, verification involves examining the status of the tunnel to make sure it is up/up (using the show interface tunnel 0 command) and the PVC (show frame-relay pvc). If there is a problem, the PVC will show as Inactive (where a PVC should show Active if it is working correctly).

See Also,
The Road to the CCIE

Setting Up a CCIE Switching Lab

Layer 2 Ethernet switching is a very important part of a network engineer's job and is a critical component to successfully passing the CCIE written and practical exams. Setting up a switching lab is different from setting up a routing lab because switches cannot be effectively emulated in GNS3/Dynamips. In order to work with a switch IOS, the physical hardware is required because of the specialized ASICs involved. Some switch features can be configured on the Ethernet switching modules available on specific platforms.

The CCIE Routing and Switching exam uses Cisco 3560 switches running a 12.2 IP Services IOS release. In lieu of having access to one or more 3560s, Catalyst 3750 switches are a reasonable substitute and support many of the same features in a similar way. The Cisco 2960 platform is unsuitable for CCIE preparation because the universal image that is used does not support routing. Chassis based switches (4500 and 6500) can also be used, but in many cases the features supported are different from the standalone models.

So, now that we know more about the models that are suitable for preparation, two questions arise: "How many?" and "How should I connect them?" The answer lies in one of the subtleties of the CCIE exam. The goal of the exam is to develop an "internetwork model" according to a set of specifications. The goal of an internetwork model is to develop a scaled-down representation of a complex enterprise network. This gives rise to a lot of the patterns presented in Cisco's Service Oriented Network Architecture (SONA) and the traditional "core-distribution-access" approach. When dealing with these models, there are a couple of useful reference topologies, what I call the "3-switch topology," "core-distribution topology," and "distribution-access topology."





The simple 3-switch topology is a good starting pattern for learning spanning-tree protocol (STP) concepts and how the different forms of STP (STP, Multiple STP [MSTP], and Rapid STP [RSTP]) work together. Generalizing from a 3 switch model to a more complex topology is extremely simple once an individual understands the port roles and transitions that can occur in each type of STP. Utilizing multiple connections between the switches can also demonstrate port aggregation and link-level fault tolerance concepts.



The distribution-access topology provides a fault tolerant layout for many access scenarios. Each of the access layer switches (located at the bottom of the topology) have redundant connections to the distribution layer switches (the top two), a lot of scenarios involving access-layer routing and first-hop redundancy protocols (FHRP) can be demonstrated. Effective demonstrations of the PortFast and UplinkFast features are also possible using this topology.



The distribution-core topology can be used to work with a 4 switch core or redundant connections between the distribution and core layers of an area of the network. This topology can be configured to effectively demonstrate the UplinkFast and BackboneFast features of the switch IOS.

Additional topologies can be created to show activity in specific scenarios, but variations on the above topologies are all that is needed to demonstrate the configuration and behavior of most of the IOS switch features tested on the Cisco certification exams (CCNA, CCNP, and CCIE).

See Also,
The Road to the CCIE

Why Should a CCIE Read Standards?

The stud/maintenance process for the CCIE exams is a long and difficult process. It takes an incredible amount of determination and self discipline to successfully understand everything that needs to be understood by a CCIE to effectively manage, evolve, and troubleshoot a complex Enterprise network. Cisco develops exam objectives loosely using Bloom's taxonomy. In the case of the CCIE Routing and Switching exam, all of the topics start with the word "Implement," "Evaluate," "Determine," and "Suggest."

There is probably a large potential debate about what the word "Implement" actually means, but I'll give my definition of what I think it means:

In the CCIE exam objectives, the combination of terms above around a given technology likely result int he following skills:
- Understand all of the concepts with a given technology and be able to unambiguously explain key terms and recall key facts
- Explain differences between the standard and the vendor-specific implementation
- Determine where a technology fits in a given network architecture
- Successfully design and optimize using the given feature/technology
- Evaluate a proposed design and develop positive and negative aspects and counter the proposal with design improvements
- Understand and code all of the related technology parameters and configuration options
- Explain how a technology works with technologies in higher, equal, and lower layers of the OSI model
- Evaluate the steps from start to finish to implement a change
- Explain the business impacts of making a specific change

Basically, in a one sentence summary: Effective operation at the CCIE level requires critical thinking, evaluation, and implementation using any feature/technology that exists in the networking industry regardless of whether Cisco implements it in a specific product or line of products.

This provides an insight into the title for this post. The level of knowledge required for the CCIE cannot be attained through memorization alone (in fact, memorization without context will likely hurt the CCIE candidate's chances for passing the exams on the first or second try). Simply, too much needs to be understood to be memorized. So why read standards?

Standards offer the CCIE candidate a complete, unabridged coverage of a technology or topic. Whether it is a set of RFCs released by the Internet Engineering Task Force or the authoritative electrical and mechanical specifications published by the IEEE, a topic can be comprehensively understood and applied by understanding the standards. Starting fromt he beginning, a CCIE can understand how a technology evolved and predict the future direction of a feature/technology.

Reading anything besides an authoritative standard is a paraphrase/summary of the standard. Depending on the source, a summary might be incorrect or provide an incomplete/misleading picture of what a technology/feature achieves. If a candidate uses the Cisco Press books to achieve the CCNA/CCNP, then they have gained a simplified understanding of the main technologies used in enterprise networks and may know the main features of technologies like Ethernet, Frame Relay, IP, TCP/UDP, but their level is likely at the "memorizing" level of understanding. This is not to say that the CCNA and CCNP aren't important, rather they help build some of the summary understanding required to successfully read/interpret a difficult IEEE standard or RFC.

Reading standards takes a candidate beyond memorization to a comprehensive end-to-end understanding of a protocol or technology. To achieve "Expert" status, this is really what is required. It's not easy, takes a lot of time and patience, but ultimately ends up in a level of knowledge where memorization is neither helpful nor required. Instead of memorizing the fields of an Ethernet frame, a candidate can break down why each field is present, where it originated, and can build an Ethernet frame without actually memorizing any fields. I structure my post on Ethernet basics in this way, by taking a bottom up approach from the 802.3 CSMA/CD fields to 802.2 LLC fields to RFC 1042 SNAP fields. By having read the majority of each of the standards, I know everything that needs to be known to create a layer 2 frame using Ethernet.

Would-be CCIEs who don't want to read standards and build a complete understanding are probably better off pursuing a different certification or staying at the CCNA/CCNP level. It simply takes too much time and too much effort for most people to gain the required level of understanding. Those who manage to magically pass the CCIE based on memorization alone give every other CCIE a bad reputation because they lack the knowledge that is required to be effective in an advanced network engineering role. This is why Cisco has made every effort to make the CCIE differentiate the top 1% of the networking world.

For those studying for the CCIE, understand that it is a long and difficult process. Most people can't complete the required study in 6 months and many can't complete the required study within a year. For many, it takes years to develop the required mastery of networking. If you measure the CCIE in pages of reading, you are easily into the tens of thousands...

Best of luck to those of you who are working towards this certification.

Below is a list of standards that I've found helpful in understanding the topics required for the CCIE (though, not a complete reading list and also not complete at this point):

Institute for Electrical and Electronics Engineers:
IEEE 802-2001: IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture
IEEE 802.1d-2004: Media Access Control (MAC) Bridges
IEEE 802.1q-2011:  Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks
IEEE 802.3-2008: Carrier sense multiple access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications
IEEE 802.2-1985: Logical Link Control

Internet Engineering Task Force (IETF):
RFC 1042: A Standard for the Transmission of IP Datagrams over IEEE 802 Networks

The Broadband Forum (formerly the Frame Relay Forum)

See Also,
The Road to the CCIE