15 year CCIE!

I just got an email from Cisco congratulating me. 15 years wow how did that happen?

I think back to where this all started. The HP 85. After college, I spent years working in electrical engineering for many companies on various DoD products. The HP 85 was very popular in the early 80s as you could write programs using “Basic” and pull instrumentation off the serial bus of any HP instrument. I did a lot of R&D and also QA so it was important that we documented the results of all the testing.

The successors had more modern color screens and capabilities and this was a large part of my work environment.

I was fortunate to work on avionics for the F15 and A10, precision cesium standard clocks for the Space Shuttle, Project Gallelo, and other satellites. Eventually, I made my way to Sperry Gyroscope (Unisys) working on the MK-92 fire control radar. We still used the HP85, but then DOS on the IBM 8086 came around and we had serial cards that could integrate with the testing equipment.

Eventually, my future electronic jobs started to use windows 3.11 and then I can remember converting dozens of computers to windows 95 with 15 floppies. Took forever. Back in the mid-’90s the “certification craze” took effect. The big one was the MSCE, and my employer Brookhaven National lab was offering it at night for free. So I took the courses and learned all about Windows domains, IIS, and Exchange and got my MCSE in NT 4.0. I even built my first little network using a 486 as a router.

We also had some Cisco routers to connect building out at the lab and I was interested in that as well so I studied Cisco and networking and got my CCNA back in 1999. From there it was hook line and sinker. I went down the Cisco and Microsoft path learning as much as I could using my home lab. Eventually, I was able to get my first real IT job(even though I have been doing computers and such since the 80s).

At my job at Northfork Bank, I was responsible for all the networking as well as computers. In those days it was token ring for the workstations and DLSW over fractional T1 or ISDN to the branches. By then I had my CCNA/CCDA and CCNP/CCDP. The next step was the CCIE! This was 2001 I attended Bruce Caswell CCIE BootCamp, read all the books, and took the exam in early 2002 and failed. Also in late 2002, I got a job with LendingTree down in Charlotte NC so I moved down and my family came down in 2003. At that point, I had a good job and the CCIE took a back seat while my kids were young and growing up.

In 2006-2007 I started collecting gear so I could work on the CCIE R/S test again. I passed the written and used CCBootCamp and IPExpert materials. I had my lab on the dining room table for the longest time and one of my neighbors came home with a sweet rack with glass doors someone was throwing out. At that point, the CCIE lab reservations were actually running on the weekends. So off I went to RTP on Saturday, Feb 9th, 2008, and spent the day in a hotel room cramming for any last things.

Sunday a group of CCIE candidates was waiting to get in. Most were from all over the country and there was a guy from the UAE. I breezed through the first part and everything went well up to lunch. One guy walked out at lunch never to return. I can’t reveal details but there was an easy 5-minute configuration I could not get working. I spent a great deal of time as I couldn’t move on to further items. I went to the proctor and asked if was it possible somehow I was hooked to the wrong link. Nope, all things looked good but he did say you are missing something really basic. I went back and instantly saw the deception and my neighbors came up. I had about an hour left to do 3 hours of test so flew through it and finished.

The proctor asked if the 10 of us left wanted to wait and if he would grade it right there. Of course, we all said yes. And we did it alphabetically so of course, Witte is last. One by one people were graded, failed, and left. Then it was my turn. Before he started grading he mentioned how well I finished off the last portion after getting stuck he never expected me to pass. And we went through my test and I passed easily. He handed me a yellow tear-off pad with my CCIE #19992! I even wrote my name up on the board there in RTP. Out of 10 or 11 of us, I was the only one to pass. Literally one of the proudest moments in my career. Still have that piece of paper.

The proctor then said since you did so well on some of the sections, I would go home and start studying Service Provider you should be able to get past that easily. So that’s what I did buy more gear, an ATM 1010 Lightstream, some 7200s with ATM, and some IPExpert SP material. I tried 2x for the SP CCIE and that was when there was rampant cheating. There was a 4-question written portion worth 20 pts if you got 2 wrong you started the test with an 80. And you need an 80 to pass so both times I got a 74 so I should have passed. I did that 2x and didn’t get through the 4 questions pretty unfair for an at the time $1400 test to ride on. Then they changed the test from IOS to IOS-XR, new gear the whole thing was changed. At that point, I had enough with SP. Below is my lab with the CCIE DC added. NetApp filer, MDS switch, and servers for virtualization. You can also see the LightStream 1010 on the bottom from the CCIE SP.

Here is the entire lab, I had frame relay, ATM, and call manager, then used VMWare a vASA, virtual 7k running OTV, FC with the MDS, and a UCS simulator. I tried the CCIE DC using this gear but failed as well. At that point, I had joined WWT and was traveling a lot so with the travel and family obligations I put it away

Here is the physical portion;

And the virtual portions with the CCIE DC gear and virtual 7K and UCS

I’ve tried seeing about revisiting these but 15 years have gone by. I’d rather learn AWS and public cloud, Kubernetes, smart NICs, and AI/ML. The CCIE was a great gateway to getting me fantastic jobs at ePlus and WWT. People ask why I don’t go Emeritus and that I’ve worked too hard and you never know where you’ll end up. I keep doing my re-certifications using CE learning credits instead of the CCIE written. I’m up to 50 credits, I need 70 more CE credits from Cisco to re-certify everything.

Been a long 40 years journey with computers then moving to networking and I’ve been fortunate to see it go from AppleTalk, IPX/SPX, RIP, DLSW, Token Ring to SD-WAN/LAN/DC, AI/ML training of the network and virtualized everything with VNFs. Now we are getting into containers and microservices via Kubernetes and other container platforms so there is never a lack of something new. Next is 20 years!

MPLS AToM,L2TPv3 and Interworking IP Pt4 AToM

So the last part we will talk about is AToM. AToM is a method of transporting L2 frames from attachment circuits across a MPLS network. Whereas MPLS VPN provides a service of creating VPNs at Layer 3, AToM creates VPNs at Layer 2 and is sometimes referred to as L2VPN. The AToM intelligence is limited to the provider edge (PE) routers. Therefore, AToM is an edge technology—like MPLS VPN—that uses an MPLS backbone. However, AToM is limited to creating a Layer 2 point-to-point service, which is referred to as virtual private wire service (VPWS). You can also use MPLS to create a Layer 2 point-to-multipoint service. This service is referred to as Virtual Private LAN Service (VPLS).

Inside the PSN tunnel might be one or more pseudowires that connect the attachment circuits (ACs) on the PE routers to each other. The AC can be ATM, Frame Relay, HDLC, PPP, and so on. Frames that the PE receives on the AC are encapsulated and sent across the pseudowire to the remote PE router. The egress PE router receives the packets from the pseudowire and removes their encapsulation. The egress PE extracts and forwards the frames to the AC.

Before the pseudowire is ready to switch the frames, the PE routers must set it up between them. During the setup, the PE routers exchange the necessary information so that they agree what the service is. For example, the PE routers must agree on the encapsulation method and what to do if they receive out-of-order frames. The result of the AToM service is that the customer edge (CE) routers or CE switches see themselves as directly connected to each other on Layer 2, even though a pseudowire separates them. If the CE routers or switches are running Cisco Discovery Protocol (CDP), for example, they see each other as CDP neighbors. If they are routers, they can directly form a routing protocol adjacency between them because the CE routers are seen as directly connected at Layer 2.

In networks that use AToM, all the routers in the service provider network run MPLS, and the PE routers have an AC toward the CE router. The PE router receives Layer 2 frames on the AC and encapsulates them with labels before sending them onto the PSN tunnel toward the remote PE. At the remote PE, the label(s) are removed and the frames are sent toward the remote CE.

In the case of AToM, the PSN tunnel is nothing other than a label switched path (LSP) between two PE routers. As such, the label that is associated with that LSP is called the tunnel label in the context of AToM. The LSRs can signal that LSP in different ways. First, the Label Distribution Protocol (LDP) can signal the LSP hop-by-hop between the two PEs. Second, the LSP can be an MPLS traffic engineering (TE) tunnel that the Resource Reservation Protocol (RSVP) signals with the extensions needed for TE. With this tunnel label, you can identify to which PSN tunnel the carried customer frame belongs. This tunnel label also gets the frames from the local or ingress PE to the remote or egress PE across the MPLS backbone. To multiplex several pseudowires onto one PSN tunnel, the PE router uses another label to identify the pseudowire. This label is called the VC or PW label because it identifies the virtual circuit or the pseudowire that the frame is multiplexed onto. 

An LSP is unidirectional. Therefore, for a pseudowire to be set up, two LSPs must exist between a pair of PE routers, one for each direction.

As the ingress PE receives a frame from the CE, it forwards the frame across the MPLS backbone to the egress LSR with two labels: the tunnel label and the VC label.

In an AToM network, each pair of PE routers must run a targeted LDP session between them. The targeted LDP session signals characteristics of the pseudowire and most importantly advertises the VC label. The VC label is always the bottom label in the label stack. It identifies the egress AC on the egress PE. The tunnel label is the top label in the label stack and tells all intermediate LSRs to which egress LSR the frame must be forwarded. Figure 10-3 shows a typical setup with a pseudowire between two PE routers.

The ingress PE router PE1 first pushes the VC label (label 33) onto the frame. Then it pushes the tunnel label. The tunnel label is the label that is associated with the Interior Gateway Protocol (IGP) prefix identifying the remote PE. This prefix is specified by the configuration of AToM. The MPLS packet is then forwarded according to the tunnel label, hop by hop, until the packet reaches the egress PE, PE2.

Notice that when the packet reaches the egress PE, the tunnel label has already been removed. This is because of the penultimate hop popping (PHP) behavior between the last P router and the egress PE. The egress PE then looks up the VC label in the label forwarding information base (LFIB), strips off the VC label, and forwards the frame onto the correct AC.

The P routers never need to look at the VC label; therefore, they do not need the intelligence to be able to do anything with the VC label. The P routers are completely unaware of the AToM solution.

Because the tunnel label is simply the LDP or RSVP-learned label, no special label distribution protocol has to be set up for AToM on the P routers. The MPLS backbone normally is already using either label distribution protocol. The VC label, however, needs to be associated with a certain AC and advertised to the remote PE. A targeted LDP session performs this job

Signaling the Pseudowire

A targeted LDP session between the PE routers signals the pseudowires. In essence, the signaling protocol LDP sets up and maintains the pseudowires between the PE routers. LDP has been extended with new Type Length Value fields (TLVs) to perform this job. The main purpose of this LDP session between the PE routers is to advertise the VC label that is associated with the pseudowire. This label is advertised in a Label Mapping message using the downstream unsolicited label advertisement mode.The VC label is advertised by the egress PE to the ingress PE for the AC (VC ID 100) over the targeted LDP session. The tunnel label is the label advertised for the egress PE router to the ingress PE by LDP. Notice that the egress PE advertises label 3, which indicates that PHP is used.

Here is a basic example of an AToM network with two PE routers that provide an AToM service to the two CE routers, CE1 and CE2. The transported Layer 2 protocol is HDLC.

MPLS AToM,L2TPv3 and Interworking IP Pt3 configuration

So I am going to start with L2TPv3 using GSn3 in the following configuration. This setup will be used for L2TPv3, AToM and Interworking IP.

We can see that CE1 is connected to PE1 and CE2 is connected to PE2 via a PPP connection and a frame relay. CE3 is  connected to PE1 via ethernet and CE4 is connected to PE2 via ethernet. There is OSPF routing in the PE-P-PE core and the loopbacks at 1.1.1.1 on PE1 and 2.2.2.2 on PE2 are advertised. These loopback will be used to form our pseudowires.

We can explore AToM, L2TPv3 and interworking IP using this setup.

First lets start with L2TPv3 over ethernet  as its the simplest.

First we start with creating the Pseudowire-class then it gets applied to the PE-CE link

on PE1

pseudowire-class L2TPv3
 encapsulation l2tpv3
 ip local interface Loopback  0

interface FastEthernet0/0
 no ip address
 duplex full
 no cdp enable
 no clns route-cache
 xconnect 2.2.2.2 100 pw-class L2TPv3

On PE2

pseudowire-class L2TPv3
 encapsulation l2tpv3
 ip local interface Loopback  0

interface FastEthernet0/0
 no ip address
 duplex full
 no cdp enable
 no clns route-cache
 xconnect 1.1.1.1 100 pw-class L2TPv3

So from the above commands in the pseudowire-class we see we are binding one end to our local loopback(1.1.1.1) using the “ip local interface loop0” and we create our pseudowire with the xconnect command under the interface which binds it to the remote local loopback.

To verify use the “show l2tun” command(s)

Looks like PE1 is not established

PE1#sh l2tun
 Tunnel and Session Information Total tunnels 1 sessions 1

LocID RemID Remote Name   State  Remote Address  Port  Sessions L2TPclass
53473 63214 PE2           est    2.2.2.2         0     1

LocID      RemID      TunID      Username, Intf/                          State
                                 Vcid, Circuit
11053      0          53473      100, Fa0/0                               wt-rep

PE1#sh l2tun session all
 Session Information Total tunnels 1 sessions 1

Session id 11053 is down, tunnel id 53473
Call serial number is 1073600000
Remote tunnel name is PE2
  Internet address is 2.2.2.2
  Session is L2TP signalled
  Session state is wait-reply, time since change 00:21:54
    0 Packets sent, 0 received
    0 Bytes sent, 0 received
    Receive packets dropped:
      out-of-order:             0
      total:                    0
    Send packets dropped:
      exceeded session MTU:     0
      total:                    0
  Session vcid is 100
  Session Layer 2 circuit, type is Ethernet, name is FastEthernet0/0
  Circuit state is UP
    Remote session id is 0, remote tunnel id 63214
  DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
  No session cookie information available
  No FS cached header information available
  Sequencing is off

However on PE2 we see that the session is not established

PE2#sh l2tun session
 Session Information Total tunnels 1 sessions 1

LocID      RemID      TunID      Username, Intf/                          State
                                 Vcid, Circuit
31213      11053      63214      100, Fa0/0                               wt-sss

On closer inspection the connection between PE2 and Ce4 was shut, after brining it up, the session is established

PE2#sh l2tun session
 Session Information Total tunnels 1 sessions 1

LocID      RemID      TunID      Username, Intf/                          State
                                 Vcid, Circuit
31213      11053      63214      100, Fa0/0                               est

So we can see that the session is established. If we go onto PE3, we should be able to ping PE4 as its on the same L2 network.

CE3#ping 10.10.10.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.4, timeout is 2 seconds:
!!!!!

Next we will do L2TPv3 over frame-relay which is not really too straightforward

First we have to turn on frame-relay switching since we will be switching the pvc’s. Next we create a connection and bind it to the interface and local DLCI(use show frame-relay pvc). In some examples, I have seen the use of the “frame-relay intf-type dce” command under the frame-relay interface in this lab this caused the interfaces to be in a Up/Down state you may need to experiment with this. Finally we apply the xconnect command under this connection NOT under the interface as we have done in all other types of connections. As you can see there is no configuration done under the actual frame relay interface.

PE1

frame-relay switching

pseudowire-class L2TPv3
 encapsulation l2tpv3
 ip local interface Loopback0

interface Serial1/1
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 no clns route-cache

connect PE1 Serial1/1 201 l2transport
 xconnect 2.2.2.2 100 pw-class L2TPv3

PE2

frame-relay switching

pseudowire-class L2TPv3
 encapsulation l2tpv3
 ip local interface Loopback0

interface Serial3/1
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 no clns route-cache

connect PE1 Serial3/1 403 l2transport –
 xconnect 1.1.1.1 100 pw-class L2TPv3

Finally we use the ‘show l2tun” command to see if our session is established. Notice the DCLI(201)

PE1#sh l2tun
 Tunnel and Session Information Total tunnels 1 sessions 1

LocID RemID Remote Name   State  Remote Address  Port  Sessions L2TPclass
10516 36056 PE2           est    2.2.2.2         0     1        l2tp_default_cl

LocID      RemID      TunID      Username, Intf/                          State
                                 Vcid, Circuit
11059      31224      10516      100, Se1/1:201                           est

And finally we should be able to ping from PE1 to PE2

CE2#ping 10.10.10.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!

Finally lets try and go from ethernet to frame-relay

To do this we will use the interworking ip option. First lets bring up the pseudowire between the frame relay on PE1 and the ethernet connecting to CE4 on PE2 like we did in previous examples. As we can see the session does not come up.

PE1#sh l2tun
 Tunnel and Session Information Total tunnels 1 sessions 0

LocID RemID Remote Name   State  Remote Address  Port  Sessions L2TPclass
33095 53375 PE2           nosess 2.2.2.2         0     0        l2tp_default_cl

 By adding the interworking IP to the pseudowire class it will come up.

PE1#sh l2tun
 Tunnel and Session Information Total tunnels 1 sessions 1

LocID RemID Remote Name   State  Remote Address  Port  Sessions L2TPclass
33095 53375 PE2           est    2.2.2.2         0     1        l2tp_default_cl

LocID      RemID      TunID      Username, Intf/                          State
                                 Vcid, Circuit
11141      31306      33095      100, Se1/1:201                           est

No we should be able to ping from Ce1 connected via frame to CE4 connected via ethernet.

CE1#ping 10.10.10.4

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

SO here is the final config and relevant notes.

PE1

frame-relay switching

pseudowire-class L2TPv3
 encapsulation l2tpv3
 interworking ip      – this is how we connect disimilar attachment circuits
 ip local interface Loopback0

interface Serial1/1
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay interface-dlci 201 switched    -this switches the packets
 no clns route-cache

connect PE1 Serial1/1 201 l2transport
 xconnect 2.2.2.2 100 pw-class L2TPv3

On Ce1

interface s1/1

frame-relay map ip 10.10.10.4 102 broadcast    – we need this inverse arp doesnt appear to work.

On PE2

pseudowire-class L2TPv3
 encapsulation l2tpv3
 interworking ip      – this is how we connect disimilar attachment circuits
 ip local interface Loopback0

interface FastEthernet0/0
 no ip address
 duplex full
 no cdp enable
 no clns route-cache
 xconnect 1.1.1.1 100 pw-class L2TPv3

Thats about it, next we will do AToM.

MPLS AToM,L2TPv3 and Interworking IP Pt2

Ok so a little caveate here from my previous post;

I purchased some NPE225’s for my 7200’s for the interworking IP support and was hoping that AToM was supported(xconnect with MPLS encapsulation. Unfortuantely they do no support this, you need a VXR chassis(at least in GNS3). The commands are there like I saw, however once you try and apply them to a interface you get a big fat error.

As we can see the MPLS option as well as the interworking IP  is there under the pseudowire-class however when you apply it to the interface you get the error;

pseudowire-class AToM
 encapsulation mpls
 interworking ip

Rack10R8(config-if)#xconnect 10.10.0.7 100 pw-class AToM
MPLS encap is not supported on this circuit

And if we do some digging we see that edge functionality is not supported.

Rack10R8#sh mpls l2transport hw-capability interface serial 3/1
Interface Serial3/1

Transport type PPP
  Core functionality:
    MPLS label disposition supported
    Control word processing supported
    Sequence number processing not supported
    VCCV Type 1 processing supported
  Edge functionality:
    Not supported

However if we look in GNS3 using a VXR chassis it is supported. Bummer…

PE2#sh mpls l2transport hw-capability interface s3/0
Interface Serial3/0

Transport type PPP
  Core functionality:
    MPLS label disposition supported
    Control word processing supported
    Sequence number processing not supported
    VCCV Type 1 processing supported
  Edge functionality:
    MPLS label imposition supported
    Control word processing supported
    Sequence number processing not supported

So a little background on this technology is in order I suppose. This is not included in the Internetwork Experts training guide I bought, and since it is on the blueprint it is testable  using AToM, Interworking Ip and/or L2TPv3.  Both AToM and L2TPv3 esentially do the same thing,  they connect L2 networks across a L3 network using a L2VPN.  AToM uses MPLS and LDP to setup the 2 bidirectional LSP’s using directed LDP sessions , while L2TPv3 uses traditional IP routing. They both use the Pseudowire concept and use the Xconnect command under the interfaces that are being joined. The first versions only supported like transports such as ethernet to ethernet or PPP to PPP. Recent releases no support using disimilar transports like ethernet to frame-relay or PPP to frame-relay. This is where the interworking IP supports comes in.

As we can see in this diagram we have all of the L2 transport types that can be sent over a L2 VPN(AToM or L2TPv3) They can be transported like to like or any to any(interworking IP)

Because an L2TPv3 session is inherently bidirectional, an L2TPv3 pseudowire is essentially an L2TPv3 session carrying a particular type of Layer 2 frame. In other words, a one-to-one mapping exists between sessions and pseudowires. During the process of L2TPv3 session establishment, the peering PE routers exchange session IDs. An L2TPv3 session ID is equivalent to an AToM pseudowire label. A session or pseudowire consists of two session IDs. Fundamentally, L2TPv3 pseudowires and AToM pseudowires are set up in a similar fashion. The difference is that the baseline L2TPv3 protocol specification is responsible for constructing such a bidirectional pseudowire, whereas AToM relies on an application-level mechanism that is built on top of the LDP protocol specification for the same function. From the end user’s point of view, this difference is insignificant.

Figure 3-6. L2TPv3 Network Components

An AToM pseudowire is made of a pair of MPLS label-switched paths (LSP). Because an MPLS LSP is inherently unidirectional, to have bidirectional connectivity, a pseudowire is formed by establishing two LSPs in the opposite directions. Different MPLS applications might use different ways to distribute labels. Some use the dedicated Label Distribution Protocol (LDP), whereas others use extensions of existing protocols, including routing protocols. AToM utilizes targeted LDP sessions between PE routers to exchange MPLS labels that are used for pseudowires. You establish a targeted LDP session by sending unicast hello packets rather than multicast hello packets during the LDP discovery phase. LDP also supports TCP message digest, also known as TCP MD5, as its authentication method. Figure 3-4. AToM Network Components

Following are the two types of Layer 2 VPN IW:

• Bridged (Ethernet) Internetworking— Ethernet frames that are extracted from the attachment circuit are sent over the pseudowire. In the case of 802.1q, the VLAN tag is removed. The pseudowire functions in Ethernet (VC type 0x0005) like-to-like mode, and the IW function at the NSP performs the required adaptation based on the attachment circuit technology. Non-Ethernet frames are dropped.
• Routed (IP) Internetworking— IP packets that are extracted from the attachment circuit are sent over the pseudowire. The pseudowire functions in IP Layer 2 Transport (VC type 0x000B) like-to-like mode, and the IW function (NSP) performs the required adaptation based on the attachment circuit technology. Non-IPv4 packets are dropped.

In general, you use Layer 2 IW to connect different Layer 2 technologies at both attachment circuits by means of a pseudowire. The actual type of IW typically depends on the end-to-end application type, such as bridged or routed. If you want to interconnect different attachment circuit technologies and carry protocols other than IP, the only current option is bridged IW.

In the IW case, the pseudowire consists of two endpoints with the same VC type. With Ethernet IW, the two pseudowire endpoints advertise a VC type of 5 for Ethernet. In contrast, with IP IW, the two pseudowire endpoints advertise a VC type of 11 for IP Layer 2 Transport. The attachment circuits can be different, however, so an IW function deals with processing the native service. The consequence is of paramount importance: Unlike the like-to-like case in which the attachment circuit is transported transparently and unmodified, in the IW case, the attachment circuits are terminated locally. The behavior of locally terminating attachment circuits imposes some limitations.

Another consequence is that the maximum transmission unit (MTU) considerations for IW scenarios differ from the like-to-like ones, not only because the PDU that is transported is different, but also because various interface types might have diverse default MTU values.

Table 14-1. Default MTU Values for Different Medias

Interface Type	Default MTU
Serial	1500 bytes
Ethernet
HSSI	4470 bytes
ATM
POS

When you are configuring pseudowires between interfaces that have default MTU values (such as Packet over SONET [POS] to Ethernet), the MTU values need to match. Frame Relay has a special circumstance that is covered in the case studies.

MPLS AToM,L2TPv3,and interworking IP Pt1

So going through some study materials, MPLS based AToM and interworking IP came up. In some of the scenarios I was trying to do, I got something similar working using L2TPv3 on my 2 7200’s but low and behold they would not support interworking IP or MPLS based AT0M on the NPE 200’s that I currently have. I did some looking on the  Cisco site and it looked like Interworking IP as well as AToM over MPLS were supported on the NPE 225’s so off to eBay. I found a third 7200 with the 225 so I got it bought and installed and sure enough the commands are there. So I just got 2 more NPE 225’s for my 2 other 7200’s and got the other 7200 racked and cabled. I redid my rack in a couple hours and cleaned up the cables as you can see in the pic it  looks pretty good. Here is what I have, this is based on the Internetwork Experts Service Provider labs;

• 3 7204’s with NPE 225’s, serial cards, fast ethernet cards and ATM cards running 12.2(25) S9.
• 4 3640’s with various serial, fast ethernet cards and ATM cards running 12.3 T trains.
• 3 2600’s with serial cards
• 2 3750’s
• A LS1010 Lightsteam(picked it up for $80 it cost more to ship it!)
• A 2523 FOR FRAME RELAY(from back when there was token ring on the lab. Also had a 3900 token ring switch back in the day as well as a old 5500 to run catOS)
• A 2511 for terminal server
• a bunch of 2500’s for BB routers.

Tommorow I’ll go through my scenario in detail hopefully this all works!

Back to the CCIE SP

After failing the SP test back in the spring I took some time off and its time to gear up. I went right back after a couple of months and I havent lost anything. I just ordered some NPE 225 for my 7200’s so I can do AToM and interworking IP. Also bought 2 more 7200’s for some of the labs I am working with.

Why the title

I tried to come up with something that describes what I work with on a daily basis. Basically I am a network engineer and I deal with taking data from one computer, putting it on a wire and sending it to another computer. If you break it down everything on a computer is based in binary(0’s and 1’s) bits. You take these bits off a hard drive, the OS does its thing and these bits are converted to binary electrical impulses(0’s and 1’s) and sent across the wire to the other computer. So basically these binary bits are taking a journey from one computer to another.

Forgetfulness

So the reason I started doing a blog is I am forgetting a lot of what I do on a daily basis and what I have done in the past. Hopefully in all this writing I can document all the cool things I have done with my life and hopefully help some people with all the mistakes I have made. So welcome to my blog hopefully I can help someone out. Please feel free to contact me and if anything that I blog about is incorrect feel free to tell me about it I try my best to put good information and experiences.