Primo Hoagie Nutritional Information

(My apologies to anyone not interested in this.. it is completely off-topic from my usual network-related postings)

I recently decided to pay more attention to what I’m eating. My favorite hoagie shop is Primo Hoagie. I looked online for their nutritional information but I could not find it anywhere. The local shop was able to supply me with a printed sheet. There must be others who are interested in this information, so I decided to post it to my blog.

Primo-Sized Sandwiches (click for full-sized page):

Wraps (click for full-sized page):

A Brief Introduction to LISP

At Cisco Live 2009 I was introduced to the Locater/ID Separation Protocol (LISP).  I thought the idea seemed interesting, but I didn’t quite follow the practical purpose for it.  While planning my Cisco Live 2010 schedule I made sure to revisit this topic to get a better understanding of it.  After the breakout session and a few hours of experimenting, I believe I have a good feel for the issue LISP is attempting to solve, and the manner in which it intends to solve it.

By the way, I’m going to skip the requisite joke about the recursive programming language.  I will say that in college I spent a semester and a half programming in Scheme.  This first semester was an Introduction to Computer Science course, and wasn’t too bad.  The half semester was an advanced course called Artificial Intelligence.  It was a struggle for me to wrap my head around all the recursion.  When I reached the halfway point of the course, I asked the instructor about my outlook for a good grade.  She politely suggested I consider dropping the course :)

 

The IP Routing Problem

Before discussing LISP, it is useful to compare/contrast how DNS works versus how Internet IP routing works.  Both DNS and IP Routing deal with a large databases.  With DNS, the database is truly distributed.  End user DNS servers (for example, your corporate Internet-attached DNS server) are configured with specific names for their authoritative zones, plus enough information to allow them to look-up any other information they might need.  Random DNS entries (for example, www.cisco.com) are not pre-loaded into your DNS server.  If you need to resolve this name, the DNS server requests the information from an upstream server.  Caching adds some efficiency, but does not change the overall structure.  This system has allowed the number of DNS zones to scale well into the millions.

The database for IP routing is handled quite differently.  In the Internet’s Default Free Zone (DFZ), all routers must have the entire Internet routing database.  Summarization can help alleviate this requirement to a degree, but summarization also comes at the price of less accurate routing information.  The IPv4 routing database is currently 325,000 routes, give or take a few thousand.  Ultimately the IPv6 table will be as large, or more likely considerably larger, and the increased size of the address space will result in larger memory requirements.  And remember, this is high-speed router memory, not generic DRAM.  Wouldn’t it be great if we could transition IP routing from it’s current ‘replicated database’ model to a distributed database, like DNS?  As a matter of fact, that’s the goal of LISP.

 

Following a Connection in a LISP-Enabled World

Let’s go through a simple example in a fully LISP-enabled environment.  A user PC would determine the destination IP address of a web server via DNS and create a standard IP packet, with its own IP as the source and the IP of the web server as the destination.  The packet would be routed through the user’s LAN until it reached an Internet gateway.

 

At this point, the LISP-aware ISP router (in LISP-speak, the Ingress Tunnel Router, or ITR) would perform a lookup for the destination IP address.  An answer would come back with the IP address of the Egress Tunnel Router (ETR) for that destination.  The ITR would then encapsulate the user’s packet in a LISP packet, with a source IP of the ITR’s ISP interface and a destination of the ETR’s ISP interface.  This packet would then be sent through the Internet to the ETR.

The ETR receives the LISP-encapsulated packet, removes the header and routes the native IP packet (with the user’s PC as a source IP and the web server’s IP as a destination) into the local LAN, to the web server.  Return traffic from the web server to the user follows the same procedure in reverse (the web server’s ISP router acts as the ITR and the user’s ISP router is the ETR).

As a side note, the “Ingress” and “Egress” designations for Tunnel Routers are relative to the LISP-encapsulated tunnel.  The router that encapsulates a packet into LISP is the ingress router.

 

Tell Me Again… Why Is This Better?

On the surface this seems like extra work for little to no benefit.  Let’s dig a bit deeper to see how this helps each component in the path.

User PC – Nothing is different

ITR – This router only needs a default route to the Internet.  It is not clear from this example, but even if there is redundancy, in a fully LISP-enabled environment, only a default route is required.

Internet PE / P routers – This is where the magic happens.  The Internet PE and P routers only need routes for the ISP interfaces of the customer routers.  All packets between customers will be encapsulated, with the source and destination IP addresses coming from the WAN circuits.  Memory requirements are greatly reduced in these devices.

ETR – Only requires a default route to the Internet.

Web Server – Nothing is different

 

Drawbacks

So what are the drawbacks to LISP?  I can think of several:

MTU Issues – At its heart, LISP is a tunneling technology.  All tunneling technologies suffer from potential MTU issues.

Complexity – This paradigm is clearly different than what most of us are comfortable with.  But we didn’t enter this field thinking nothing would ever change, right?

Delay – The initial packet towards a new destination will likely get dropped, because the destination lookup takes time.  After the first packet the destination information is cached, so subsequent packets should flow without delay.  According to the Cisco LISP team, testing has shown this isn’t as big of an issue as it appears in theory.

A few optimizations have been suggested to deal with this delay issue.  First, a set of common destinations could be pre-programmed into ITRs (subnets associated with Google, for example).  Colin McNamara had a particularly interesting suggestion of ITRs performing DNS reply snooping, as it is highly likely that a DNS lookup will be followed quickly by an initial packet to that destination.  I’m not sure if this is being worked on, but it seems like a great idea.

 

What is Missing?

I glossed over the entire destination IP address lookup portion of LISP.  I will post a follow-up article describing this step.  For now, trust me when I say that it is not much different than DNS.

I also skipped over the other advantages of LISP.  For one, the ETR completely controls how inbound traffic is delivered to it.  If a destination IP address has multiple ISP gateways, those gateways can instruct ITRs to load-balance between destinations.  Experienced network engineers should immediately see the power of this feature.  This could signal the end of our rudimentary BGP-based load-balancing mechanisms (AS prepending, subnet splitting/disaggregation, etc).

A second benefit that LISP provides is its ability to send non-native traffic over a routed backbone.  In the example above I did not specify any of the IP addressing involved.  It is possible for the user PC and the web server to use IPv6, while the ISP network uses IPv4.  The ITR would receive an IPv6 packet from the user and perform a lookup which resolves to the IPv4 ISP address of the ETR.  The ITR would then encapsulate the IPv6 packet into an IPv4 LISP packet, which would then be sent over the ISP infrastructure.  When the ETR receives the LISP-encapsulated packet, it strips the header off and routes the IPv6 packet towards the web server.  This can also happen in reverse, where a pair of IPv4 speakers communicate over an IPv6 backbone.

Lastly, I completely bypassed the transitioning technologies to a fully LISP-enabled Internet.  They do exist, and it is very possible to deploy LISP incrementally.  We are long past the point of Flag Days.

 

What’s Next?

The LISP presentations I’ve seen have spent a lot of time describing the benefits of LISP for IPv4.  I’m not sure that is the correct place to focus.  As stated above, we are at about 325,000 IPv4 Internet routes.  At most I foresee a doubling in size of the routing table, to somewhere around 600,000 routes.  This factors in the usage of the 10% or so of remaining IPv4 space, as well as increased use of subnetting for load-balancing purposes.  I see the LISP protocol filling two needs.  First, it can be a great transitioning technology to IPv6, as well as a way to keep IPv4 alive over an IPv6-only infrastructure.  In an upcoming LISP blog post I will demonstrate how I am using LISP to reach the IPv6 Internet over an IPv4-only ISP.

Even more importantly, we are at the very beginning of the IPv6 route table explosion.  If the LISP team can get significant traction with LISP6, we can avoid the routing table bloat issue we’ve run into with IPv4.  Remember, the IPv4 routing table isn’t going anywhere, so we will only be adding to our problems with the deployment of IPv6.

If you are keeping track, I’ve promised two upcoming blog posts on LISP (my implementation experience and how the mapping database system works).  In the meantime, there are two useful resources online – lisp4.cisco.com and www.lisp4.net.  For a more scholarly take on LISP, see Petr Lapukhov’s article at iNE.com.

Migrating from Catalyst to Nexus

There are already a couple great resources on the Internet for network engineers who are migrating from a Catalyst-based data center to a Nexus-based data center. Two of my favorites are Cisco docwiki.cisco.com site, which hosts a bunch of IOS –> NX-OS comparison pages, and a page put together by Carole Warner Reece of Chesapeake Netcraftsmen. Both of these resources helped me quite a bit in working out the syntax of NX-OS commands. This blog post is an attempt to supplement that base of knowledge with my own experiences in converting a production data center over to the NX-OS platform.

My Catalyst network was a fairly standard data center design, with a pair of 6509s in the core and multiple Top-of-Rack switches cascaded below. We used RAPID-PVST, with blocking occurring in the middle of a TOR stack.

The new Nexus environment looks pretty much the same. We have a pair of Nexus 7010s in the core with a layer of Nexus 5020 switches at the edge. Each 5020 supports 4 – 6 FEXs. The FEXs only uplink to a single 5020 switch. This new network was built alongside the existing Catalyst one. The plan was to interconnect the two environments at the cores (at layer 2) and migrate server ports over whenever possible. Once we reached a critical mass of devices on the Nexus side of the network we planned to move the Layer 3 functionality from the IOS environment to the NX-OS side.

A few months ago we finished building out the Nexus LAN and interconnected it to the Catalyst LAN. We used vPC on the Nexus side to reduce the amount of SPT blocking. All was well, and we began migrating servers to the Nexus infrastructure without any issues. Eventually we reached our pre-determined “critical mass” and scheduled a change window to migrate the SVIs to the Nexus side and reconfigure the core Catalyst 6509s as Layer-2 only devices. The configuration work for this migration was around 1500 lines, so it was not by any means trivial, but it was also quite repetitive due to the number of SVIs and size of the third party static routing tables. Here’s where the fun began.

The first issue we ran into was with an extranet BGP peering connection through a firewall. In our design, we connect various third parties to an aggregation router in a DMZ. The routes for these third parties are advertised to our internal network via BGP, through a statically-routed firewall. Most of our third party connections also utilize BGP, so we receive a variety of BGP AS numbers. In two cases, the BGP AS number chosen by the third party overlaps with one of our internal AS numbers. To rectify this, we enabled the “allowas-in” knob on the internal BGP peering routers. Unfortunately this knob will not be available on the Nexus platform until NX-OS 5.1. I should have caught this in my pre-implementation planning. This was fixed with a small set of static routes. Our medium-term plan is to work with the two third parties to change their AS numbers, and eventually we will implement “allowas-in”, once we upgrade to NX-OS 5.1. Another interesting thing to note about BGP on NX-OS is that the routers check the AS-path for loops for both eBGP and iBGP neighbors. IOS does not do any loop-checking on iBGP advertisements.

With that behind us, we moved on to the SVIs and migrating our spanning-tree root to the Nexus switches. The SVI migration was trivial, but the SPT root migration caused issues. We were bitten by the behavior of Bridge Assurance, a default feature in NX-OS that was unavailable in our version of IOS (SXF train). Surprisingly, the lack of Bridge Assurance support didn’t prevent the Catalyst<->Nexus interconnect from working while the SPT root was on the Catalyst side of the network, but once we moved the root to the Nexus side, Bridge Assurance shut down the interconnects. The only acceptable solution to this issue (that I could find) was to disable Bridge Assurance globally on the Nexus switches. My error here is that I took for granted that my interconnect was properly configured, because it had been working for several months.

After encountering this issue I took another look at Terry Slattery’s blog post on Bridge Assurance, and at Cisco’s Understanding Bridge Assurance IOS Configuration Guide. The problem I experienced is Bridge Assurance requires switches to send BPDUs upstream (towards the root), while normal RSTP behavior is to suppress the sending of BPDUs towards the root. When the Catalyst side of the network contained the root, the Catalyst switches sent BPDUs downstream to the Nexus switches (normal RSTP behavior) and the Nexus switches sent BPDUs upstream to the Catalysts, which is abnormal for RSTP, but harmless. The Catalyst switches simply discarded the BPDUs. Once the SPT root was migrated, the Nexus switches sent BPDUs to the Catalyst (normal), and the Catalysts suppressed all BPDUs towards the Nexus switches (normal for RSTP, but not correct for Bridge Assurance). For the first few seconds, this was not a problem and forwarding worked fine, but eventually the Bridge Assurance timeout was reached and the Nexus switches put the ports into BA-Inconsistent state. The “right” way to solve this issue is to upgrade the Catalyst switches to SXI IOS and re-enabled Bridge Assurance. My preference is to simply retire the 6509s, so I’ll have to keep tabs on the migration effort. If it looks like it will drag on for a while, I’ll schedule the upgrades.

(Edit on 8/9/2010 - commenter "wojciechowskipiotr" noted that configuring the port-channels towards the 6500s with "spanning-tree port type normal" would also disable Bridge Assurance, but only for those specific ports. If I get an opportunity to try this configuration, I will report on whether it is successful.)

The remaining issues I faced were minor, but in some cases are still lingering or just annoyed me:

1) Static routes with “name” tags are unavailable. I had gotten into the habit of adding a named static routes to the network, especially for third-party routing. It appears that NX-OS does not support this.

2) VTP is unavailable. Based on conversations with other networkers, I’m probably the last living fan of VTP. I am sad to see it go. Fortunately in the Nexus environment there are fewer places to add VLANs (only the 5ks and 7ks).

3) Some of the LAN port defaults are different (when compared to IOS). For example, QoS trust is enabled by default. Also, “shutdown” is the default state for all ports. If a port is active, it’ll have a “no shutdown” on the config.

4) OSPF default reference bandwidth is now 40gb, rather than the 100mb value in IOS. This is a good thing, since 100mb is woefully low in today’s networks.

5) Proxy-arp is disabled by default. Our migration uncovered a few misconfigured hosts. Not a big deal, but it is noteworthy. Proxy-arp can be enabled per SVI, but do you really want to do it?

6) We ran into a WCCP bug in NX-OS 4.2(3). For some reason NX-OS is not load-balancing among our two WAN accelerators. Whichever WAE is activated last becomes the sole WAE that receives packets. I have an active TAC case to find a solution to this issue. For now, we are running through a single WAN accelerator, which reduces the effectiveness of our WAN acceleration solution.

I hope this helps someone with their own migration. This is going to be a common occurrence in our industry for the next few years, especially if Cisco has their way. If anyone has questions, please send me an email or post a comment.

Cisco Live 2010 - Tuesday and Wednesday

I thought I'd be able to keep up with this on a daily basis, but I was wrong. So here's a recap of the bulk of the conference. I'm sitting in a Virtualization Case Study on Thursday while writing this.

Picking up where I left off in my previous post, I attended the LISP session. It was a good refresher, as I had not followed up on the technology since my first introduction at Cisco Live 2009. I'll save my thoughts on the technology for a later blog post.

On Tuesday I attended an Overlay Transport Virtualization Breakout Session. It was a good compliment to my OTV Lab on Sunday. I felt that the presenter glossed over the significant architectural change that introducing Data Center Interconnect (DCI) brings to a network. He (rightly) stated that configuring OTV is fairly trivial, assuming you have the appropriate NX-OS and a pair of Nexus 7000 switches. Once you enable L2 adjacency between disparate DCs, there's no going back. On the plus side, if you need DCI, OTV looks much better than the alternatives (dot1q dedicated links, carrier VPLS, internal VPLS, EoMPLSoGRE, L2TPv3... I'm sure I am missing a couple).

The John Chambers keynote was good as usual. The introduction of the Cisco Cius was probably the highlight. I haven't investigate it yet, and probably won't get around to looking into it in detail. I have to confess that I'm not terribly interested in technology. I don't personally own any Apple products and I've only carried a Blackberry smart phone for three years. Probably the 'coolest' technology that I own is an original Kindle, which meets my nontechnical reading needs. For that matter, I only have a single Cisco router (and no switches) at my home. Somehow I manage to keep up, so don't let anyone convince you that you need racks full of equipment to participate in our industry.

My one complaint is that I always feel like my organization is 5 - 10 years behind when I leave the keynote. For example, the Cisco Live 2008 keynote was centered around complete virtualization. Two years later, we're nowhere near there. I know the point of the keynote is to show the future direction of Cisco, and I wouldn't want anything to change, but I don't like the feeling of being behind. I always leave the session with a sense of urgency to get us back on track. This year I brought my manager, so hopefully he'll feel the same way and we can get things moving a bit faster.

After lunch on Tuesday I attended a second Panel on Experiences with Deploying IPv6. I am finally convinced that my employer needs to begin the transition. This was a great session. Presenters from Comcast, Google, Microsoft and Tata described their IPv6 deployments and gave recommendations. For once, Apple took a bit of a beating (and not from the Microsoft presenter) because no Apple OS supports DHCPv6. This requires the use of SLAAC for acquiring IPv6 addresses in mixed PC environments. It's not a show stopper, but flexibility would be nice. I prefer SLAAC anyway for the simplicity, but I am firmly in the minority, based on a show of hands during the session.

On Tuesday evening I spent a few hours with John Chambers and my ~75 closest CCIE/CCDE friends. This was my first year attending the CCIE/DE NetVet reception. It was quite an experience. John Chambers took questions for about 1.5 hours, and gave very direct responses to some difficult questions. I received some great information that will help me position my organization for upcoming shifts in Cisco strategy. While I'm fairly confident this was information I could acquire elsewhere, when it comes from the CEO, it is reliable.

After the NetVet reception I spent an hour or so attending the CCIE party at the Voodoo Lounge. I didn't stay long, but I did get a picture of the cool (both literally and figuratively) CCIE logo ice sculpture. I would have preferred the original laurel leaf router logo, but I was still impressed.


On Wednesday morning I attended "IS-IS Network Design and Deployment". I was looking forward to this session more than any other, as I have had great difficulty getting this content from other sources. There are a few books that cover IS-IS, but Cisco Live Virtual has never had the audio for this session. The slide deck I found in the past (and the one used during this presentation) lacks sufficient detail to reconstruct the information. The presenters did not disappoint, and I took about four pages of notes (the only notes I've taken at Cisco Live 2010). I intend to write a separate blog post on why IS-IS can no longer be ignored by Enterprise-focused networkers. If this describes you, you'll have a year or two to prepare.

After lunch I attended a session called "Designing Multipoint WAN QoS". This session didn't stand out in the session list when I was registering, but I was tipped off by a friend (the presenter) that it would be a good session. He didn't disappoint. I am almost embarrassed to say that I had never given much thought to the problem this session attempts to solve. It certainly deserves an individual post, but I'll describe it in a few sentences here. The best example of the issue is the Teleworker problem, where the remote user has a small Cisco router with a VPN tunnel to a Corporate headend router. The user also uses the same ISP connection (DSL, cable, etc) for home Internet usage. The problem is how do you ensure that the ISP connection prioritizes real-time Corporate traffic over general Internet web traffic downstream (towards the remote user)? To put it more generally, how do you get outbound QoS from a Service Provider network that is not QoS-aware?

My last session on Wednesday was Enterprise IPv6 Deployment. I've seen this content before, and originally I had scheduled a DCI session (DCI w/ Advanced-VPLS), but I thought it would be best to reinforce the IPv6 content. The presenter (Shannon McFarland) is very good, so I was not bored by seeing some of the information for a second time. His recommendation to begin in the core and work out towards the edge is somewhat unconventional, but he defends it well, to the point that I was convinced. Maybe more contemplation will change my mind. More information to come in the future. The biggest point he wanted to get across was "Dual Stack Where Possible, Tunnel When You Must." Tunnels introduce MTU issues and create difficult-to-troubleshoot network architectures. Maybe he should talk to the TRILL, LISP and OTV groups! :)

Cisco Live 2010 - The First 36 Hours

A quick update on my Cisco Live 2010 experience. On Sunday I attended an OTV labtorial. It was quite useful; I'm getting more confident in going that direction for an upcoming data center relocation project.

On Monday I attended the first half of an MPLS Security session. It was good, but I had to leave prematurely to take my Cisco exam. I feel like the 2nd half would have been great though, so I've made a note to revisit that one after it gets posted to www.ciscolivevirtual.com.

I passed my CCDE written exam, with a score between the first attempt (good score, during the beta) and my second attempt at Cisco Live 2009. I don't care much about what score I receive on an exam, provided it is a passing score, but I'm glad to see my score went up from last year.

I'm sitting on a Panel discussion on VPN right now. I don't think I have attended a Panel session before, and I was really missing out. This session is highly interactive, with no Powerpoint slides. Great info on GETVPN, DMVPN and a bit of EasyVPN info. The crowd isn't too interested in EasyVPN though, so the presenter responsible for that is having an easy time with this session. I am registered for a second Panel tomorrow on IPv6 Deployment Experiences, which should be great. It was a tough call registering for that, as there is also a LISP Panel at the same time. They are right next door to each other, so I may slide over to the LISP session if I'm not getting much out of the IPv6 one.

Speaking of LISP, my next session is "LISP - A Next Generation Networking Architecture". I attended this session last year and found it fascinating, but I never got a chance to follow-up on the content at home. I spoke briefly with Dino Farnacci (one of the protocol authors). He said there is a bunch of new content in this year's presentation. I finally have a use-case in my network, if I end up utilizing OTV to extend Layer-2 between my data centers during my upcoming DC migration. The Internet use-case is very cool, but I don't see a good reason to jump on board anytime soon. The list of attendees for this session is quite impressive. There are plenty of influential industry voices, so I hope the presentation goes well. If it does, the roll-out of LISP will benefit greatly.

Professional Life Update

I’ve been relatively quiet on this blog, but for some good reasons, or what I think are good reasons.  Here is my attempt at creating some excuses, it is left to the reader to determine if I get a pass :)

In March I taught my first CCDE Practical Bootcamp class.   It was a captive class, for a specific company.  I had a great teaching experience, and most of the feedback was positive, with two helpful suggestions for improving the course.  I was satisfied (but not thrilled) with the student’s results on the subsequent Practical exam.  I had hoped that my class would have had a larger impact on the candidate’s results, and I take responsibility for improving the course for future cohorts.

In May I taught my first CCDE Written Bootcamp.  I was more apprehensive about teaching this course than the Practical course, as I had no way of knowing whether the students would be properly prepared for the course.  The advantage of the Practical course is that all students are expected to have passed the CCDE Written exam prior to attending, so I could be comfortable with the level of knowledge they brought into the course.  There are no official prerequisites for the Written course, so some of the students could be very ‘green’.

Fortunately my fears were unfounded.  This was also a captive course, with all students from a common organization.  The training coordinator did a great job of ensuring that all students were prepared for the course.  At the conclusion of the course all students took the CCDE written exam and I was very happy with their results.  The student feedback was again very positive.  My biggest area for improvement is to get more familiar with the delivery of the supplied course materials for the written class.

So those paragraphs explain what I did for a couple of weeks… Where has my other time gone?  Well, the feedback from the Practical Bootcamp students indicated that they wanted some mock tests added to the syllabus.  I agree 100%; a simulation of the Practical exam is critical for preparing students.  I’ve spent the last couple of weeks developing these new materials.  My first opportunity to deliver them is coming up on July 12th in Washington DC, when I deliver the CCDE Practical Bootcamp course for CCBOOTCAMP.  If you are interested in attending, or just want some more information, please visit the CCBOOTCAMP website or write me an email.  I’ll also be at Cisco Live in Las Vegas next week, so if you would like to chat there, let me know and I’ll make some time.

Aside from these items, I also have a real job, which occupies the majority of my professional time.  Outside of that, I’ve become a bit of a soccer fan, at least as long as the USA is involved in the World Cup tournament.

Cisco Live 2010 Schedule

For anyone who is interested, I’ve posted my tentative Cisco Live 2010 schedule below.  I have a habit of switching sessions at the last minute, so if you don’t see me at one of these Breakout Sessions, don’t assume I slept in.  :)  I’ll be especially vigilant this year, with both my manager and my wife in attendance!  I added asterisks to my “must see” sessions.

My primary focuses for this year’s event are Data Center Interconnect and IPv6 Preparation.  I also sprinkled in a few sessions that caught my eye, such as IS-IS Network Design and the VPN Panel.  It occurred to me after last year that if I was interested in a panel discussion, it is necessary to attend in person.  I couldn’t find any of the sessions on Cisco Live Virtual last year.

As always, if you see me walking by, please say hi.

 

Sunday

Start: 1:00 PM End: 5:00 PM

*** LTRDCT-2008 Deploying Overlay Transport Virtualization

 

Monday

Start: 9:30 AM End: 11:30 AM

BRKSEC-2145 MPLS Security

Start: 11:00 AM End: 12:30 PM

Cisco Exam

Start: 12:30 PM End: 2:30 PM

PNLSEC-1010 Panel: VPN

Start: 3:00 PM End: 5:00 PM

*** BRKCRS-3045 LISP - A Next Generation Networking Architecture

 

Tuesday

Start: 8:00 AM End: 9:30 AM

BRKDCT-2049 Overlay Transport Virtualization

Start: 10:00 AM End: 11:30 AM

*** GENKEY-7846 Keynote and Welcome Address

Start: 12:30 PM End: 2:30 PM

*** PNLRST-2303 Panel: Experiences with Deploying IPv6

Start: 4:00 PM End: 6:00 PM

BRKSPG-2602 IPv4 Exhaustion: NAT and Transition to IPv6

 

Wednesday

Start: 8:00 AM End: 10:00 AM

BRKRST-2335 IS-IS Network Design and Deployment

Start: 12:30 PM End: 2:30 PM

*** BRKRST-3500 Designing Multipoint WAN QoS

 

Start: 3:00 PM End: 3:30 PM

Micronics Booth for CCIE Flyer Elvis Guitar Giveaway

Start: 4:00 PM End: 6:00 PM

BRKDCT-2011 Design and Deployment of Data Center Interconnects using Advanced VPLS (A-VPLS)

 

Thursday

Start: 8:00 AM End: 10:00 AM

BRKVIR-2007 Data Center Virtualization Case Study

Start: 10:30 AM End: 11:30 AM

GENKEY-7848 Closing Keynote: Author Ben Mezrich

Start: 12:00 PM End: 2:00 PM

BRKMPL-3102 Designing NGN SP/Enterprise Networks for Scale and Reliability

Start: 2:30 PM End: 4:30 PM

*** BRKSPG-2051 Evolution of Service Provider Edge Architectures