TLSA Record Generator

Last year I wrote a blog article on DNSSEC and Certificates. Occasionally I get questions from folks who've tried to follow my instructions to create the content of TLSA records, but have failed because they are using a version of openssl that is too old to generate SHA-256 and SHA-512 hashes.

I've written a small web application to help generate TLSA records. I hope this is of use to some folks:

        https://www.huque.com/bin/gen_tlsa

(I apologize in advance for my rather primitive webpage design skills!)

Here is a screenshot of it in action to generate the TLSA record for my own website:

And the resulting TLSA record that was generated:



-- Shumon Huque

IPv6 and DNSSEC at LISA in DC

Once again, I'm teaching a couple of courses at the USENIX LISA conference, this time in Washington, DC. The first is a half day course on DNSSEC on Sunday, November 3rd. And the second is a full day course on IPv6 on Monday, November 4th. I hope to see you there if you're interested in learning or talking about these topics. Early bird registration discounts for the conference end on October 22nd (sorry for the short notice).

Matt Simmons (@standaloneSA) interviewed me about both classes: DNSSEC and IPv6.

-- Shumon Huque

Singh Nanotechnology Center

The grand opening of Penn's new Singh Center for Nanotechnology is tomorrow (Friday, October 4th). Computing directors in my department got to see it a week early when we held a special meeting in the Forum room.

This post contains a few photos from my visit - of the building exterior, hallways, and conference rooms. The labs weren't open yet. The full set can be found at Google Plus.

The Nanotech center has been featured in some recent articles:

* Philadelphia Inquirer - "Changing Skyline - Inga Saffron"
* The Daily Pennsylvanian
* Philadelphia Inquirer - "Penn going all out for small science"

Building exterior, from Walnut Street close to the 33rd Street intersection, looking east:

This cantilevered section houses a conference room - the Glandt Forum room.

The Forum room, where our meeting was held.

At the edge of the cantilevered section.

Looking westward along Walnut St towards the rest of campus. Directly in front (right side) is the Laboratory for Research on the Structure of Matter (LRSM). To the left is the David Rittenhouse Lab.

View from the green rooftop terrace.

Rooftop terrace.

Hallways.

"We Lost" sculpture by Tony Smith.

Latest World IPv6 Launch Measurements

The Internet Society recently published results of their latest round (September 17th 2013) of IPv6 measurements. The measurement data is provided by Google, Facebook, Yahoo!, and Akamai. From the description on the website: "We present measurements of network operator participants in World IPv6 Launch, based on data received from major website participants, as described in more detail below. We present a simple average of the data received, and list all networks with measurements from at least two sources, with a simple average above 0.1%."

I find it instructive to sort the results by the percentage of requests from each participating network that are composed of IPv6. This is a pretty good indicator of how extensively these networks have deployed IPv6 to their end users.

Note: the measurements are only done for networks that have signed up as participants in World IPv6 Launch. If you've deployed IPv6 to your users, you should consider registering your network to take part in these measurements.

Here's a ranked list of these networks sorted by percentage of IPv6 requests of the total from each.

     1    interscholz Internet Services GmbH & Co. KG    81.22%
     2    Sauk Valley Community College                  71.23%
     3    ThaiSarn                                       69.41%
     4    Rensselaer Polytechnic Institute               61.25%
     5    Virginia Tech                                  59.54%
     6    Universidad de Carabobo                        58.50%
     7    Sistemas Fratec S.A.                           58.19%
     8    Universidad Panamericana                       57.89%
     9    Bayu Krisnawan                                 56.64%
    10    Dedicated Zone Inc                             56.55%
    11    Google Fiber                                   55.64%
    12    REACCIUN                                       52.41%
    13    NETIS TELECOM                                  52.17%
    14    Gustavus Adolphus College                      46.64%
    15    DreamHost                                      46.32%
    16    Alhambra Eidos                                 45.37%
    17    VOO                                            45.32%
    18    SPAWAR                                         45.28%
    19    Greek Research & Technology Network            43.96%
    20    Karlsruhe Institute of Technology (KIT)        43.51%
    21    AIMES Grid Services CIC                        42.37%
    22    Host Virtual, Inc                              42.24%
    23    ARNES                                          41.90%
    24    FCCN                                           40.95%
    25    Marist College                                 40.89%
    26    guifi.net                                      39.97%
    27    University of Pennsylvania                     38.94%
    28    Zimcom Internet Solutions, Inc                 35.75%
    29    Verizon Wireless                               35.73%
    30    NIIF/Hungarnet                                 29.92%
    31    LITNET                                         29.07%
    32    DirectVPS                                      29.05%
    33    Jiri strohalm                                  28.56%
    34    Hughes Network Systems                         28.00%
    35    DegNet GmbH                                    26.76%
    36    Louisiana State University                     26.61%
    37    University of Minnesota                        26.44%
    38    iway AG                                        25.73%
    39    RedIRIS                                        25.39%
    40    University of Iowa                             22.56%
    41    Universidade Federal de Santa Catarina, Brazil 22.26%
    42    Cisco                                          22.14%
    43    Monash University                              21.82%
    44    Hurricane Electric                             21.80%
    45    RENATER                                        21.55%
    46    TUBITAK ULAKBIM / ULAKNET                      21.46%
    47    Aristotle University of Thessaloniki           20.89%
    48    DataChambers                                   20.28%
    49    UNESP                                          19.85%
    50    Chubu Telecommunications                       19.06%
    51    Swisscom                                       18.83%
    52    Indiana University                             18.08%
    53    Free                                           18.04%
    54    FranTech Solutions                             17.69%
    55    Tulane University                              17.55%
    56    University of New Hampshire                    17.45%
    57    Leibniz Supercomputing Centre                  16.60%
    58    HEAnet                                         16.59%
    59    US Dept of Transportation                      16.55%
    60    GARR                                           16.27%
    61    XS4ALL                                         16.14%
    62    Defense Research and Engineering Network       15.24%
    63    DMZGlobal                                      14.26%
    64    PCextreme B.V.                                 13.80%
    65    RCS & RDS                                      13.25%
    66    PowerTech Information Systems AS               12.24%
    67    SURFnet                                        12.07%
    68    BIT BV                                         11.93%
    69    ATT                                            11.52%
    70    Academia Sinica Network                        11.34%
    71    Honesty Net Solutions (I) Pvt Ltd               9.85%
    72    UNINETT                                         9.48%
    73    Storm Internet                                  9.25%
    74    CESNET                                          9.18%
    75    University Of Lampung                           9.12%
    76    AAISP                                           8.88%
    77    prgmr.com                                       8.61%
    78    KDDI                                            8.49%
    79    Voxel / Internap                                8.29%
    80    Init7                                           8.19%
    81    AMRES - Serbian National R&E Network            8.06%
    82    Comcast                                         7.95%
    83    CJSC Progressive Technologies                   7.92%
    84    MediaCat Div./Community Network Center Inc.     7.17%
    85    green.ch AG                                     7.02%
    86    StarHub                                         6.68%
    87    OVH                                             6.30%
    88    UniNet                                          6.26%
    89    CORPORACION NACIONAL DE TELECOMUNICACIONES      6.02%
    90    National Technical University of Athens         5.91%
    91    Forthnet                                        5.81%
    92    Deutsche Telekom AG                             5.18%
    93    EPT Luxembourg                                  5.11%
    94    Energy Group Networks                           4.62%
    95    M1 Limited                                      4.56%
    96    Internode                                       4.33%
    97    BelWue                                          4.32%
    98    Quonix Networks                                 4.26%
    99    SMELLY BLACK DOG                                4.22%
   100    LENTEL                                          4.15%

DNSSEC Validation in the Internet2 community

As a follow-up to my examination of the ISC DLV registry, I conducted an informal poll of some of my peers in the Internet2 community to find out 1) who is using DNSSEC validation on their resolvers, and 2) who additionally uses the ISC DLV.

A while back I setup a small project to monitor the status of DNS signed zones in Internet2 and few other selected communities. There is no easy way to programmatically determine who is using DNSSEC validation though, so the easiest way is to ask others [1]. I got responses from a number of universities and regional R&E networks. Here's a summary:

Institution                             Uses ISC DLV?
University of Pennsylvania              Yes      
Virginia Tech                           Yes
Univ of California, Los Angeles         No
Univ of Massachusetts, Amherst          No
Kansas Research & Education Network     Yes
Kansas State University                 <unknown>
Fort Hays State University              <unknown>
Louisiana State University              No
Univ of California, Berkeley            Yes
Energy Sciences Network (ESNet)         Yes
Lawrence Berkeley National Lab (LBNL)   <unknown>
North Dakota State University           Yes
Univ of Delaware                        Yes
3ROX (3 Rivers Optical Exchange)        Yes
Pittsburgh Supercomputing Center (PSC)  <some resolvers>
University of Idaho                     No

I'm sure I'm missing others - I'll add to this list as I discover them. If you know of anyone, feel free to let me know!

Footnotes:
[1] Although Geoff Huston and others have conducted some large scale studies of validation use, using a method of buying and analyzing ad impressions at popular websites, directing clients to carefully constructed URLs located in zones with differing DNSSEC signature statuses.

-- Shumon Huque

ISC DLV registry usage

On a LinkedIn forum, Dan York of the Internet Society recently asked a question about who still uses the ISC DNSSEC Lookaside Validation (DLV) registry. While commenting on the discussion, I decided to take a look at the contents of the registry, and I'm sharing some of my findings in this article.

DLV is a method to locate DNSSEC public keys off-path. See RFC 5074 and RFC 4431 for details. It is meant to be an early deployment aid until full deployment of DNSSEC happens. It's useful in situations where the DNSSEC keys for a target zone cannot be obtained by the normal top down traversal of the DNS delegation hierarchy, typically because one or more zones between the target zone and the root aren't signed. Another situation is where a parent zone may be signed but it was not possible for the child zone to have a Delegation Signer (DS) record installed in the parent for some reason - a common one is that the DNS registrar in use did not support the ability to do it.

Internet Systems Consortium (ISC) runs a DLV registry at dlv.isc.org. The basic idea is that if you can't find a DS record for a zone, say "example.org", you append the name of the DLV registry and look for DLV record at "example.org.dlv.isc.org" - the contents of the record are the same as would have been found at the DS record. Validating resolvers are pre-configured with the public key of the dlv.isc.org zone and use it to authenticate the signature associated with the DLV record.

It appears that some large DNS resolver services like Google DNS and Comcast do not use any DLV registries for validation, so only zones that have an intact chain of trust can have their data validated. I'm not sure if ISC publishes any usage statistics for their DLV registry, but from casual discussion with colleagues in the US R&E community over the years, I know quite a number of universities that do have their campus resolvers configured to use it. We use it at the University of Pennsylvania too.While upenn.edu is signed and has a secure delegation in its parent, there are some auxiliary zones that we run, like magpi.net that don't have a secure delegation, and we make use of the ISC DLV registry to publish keys there. In MAGPI's case, the reason is that the registrar we use, Network Solutions, still doesn't support DS records. I suppose it's time to switch registrars, and it's on my todo list!

In modern versions of  resolvers like ISC BIND and Unbound, a mere one line addition to the configuration file will turn this feature on. In fact, some OS distributions, like Fedora Linux already have it turned on in their default configuration.

The ISC DLV zone by design uses NSEC, so it's trivial to write a short program to fully enumerate its contents and look at the data. Here's what I see from a snapshot of the zone taken on August 29th 2013:

  Number of distinct zones:    2760
  Total number of DLV records: 6020

The number of DLV records is higher because most zones have multiple DLV records - their key digests are published with mutiple hashing algorithms (SHA1 and SHA256), and in some cases mutiple keys are published (perhaps key rollovers are in progress). Here's a breakdown of the number of DLV records per zone, and the number of zones with that many records:

  #DLV recs   #Zones
  8                1
  6                3
  4              241
  2             2515

The zone with 8 DLV records (!) incidentally is hysh.jp (4 keys, 2 digests/key).

Looking at the distribution of zones across Top Level Domains (TLD), we see:

  Number of TLDs represented: 111

There are 318 total TLDs at the current time, 116 of which appear to be signed, so that leaves 202 that aren't. I maintain some more detailed statistics of the TLDs at http://www.huque.com/app/dnsstat/category/tld/

Here's the full list of the 111 TLDs represented, sorted by descending order of the number of zones within them that are in the ISC DLV registry.

  arpa 487
  com 456
  org 270
  net 263
  de 185
  info 75
  eu 67
  uk 66
  ch 50
  hu 49
  ro 34
  us 34
  cz 32
  za 31
  pl 31
  fr 29
  ru 28
  ca 28
  it 26
  biz 25
  be 25
  au 25
  nl 24
  jp 22
  id 22
  name 20
  me 20
  mx 19
  tv 18
  at 17
  edu 16
  tw 13
  tk 12
  es 12
  mobi 11
  br 10
  cx 10
  co 8
  is 8
  nu 8
  fi 8
  sk 8
  dk 7
  se 7
  gov 6
  im 6
  ua 6
  am 6
  asia 5
  ws 5
  cc 5
  in 5
  nz 5
  xn--p1ai 5
  pt 4
  gs 3
  do 3
  bz 3
  cn 3
  hr 3
  ms 3
  ve 3
  mil 3
  nf 3
  gm 2
  lc 2
  la 2
  li 2
  th 2
  ph 2
  hn 2
  mu 2
  pro 2
  ar 2
  io 2
  ni 2
  gr 1
  gp 1
  lv 1
  to 1
  tl 1
  lu 1
  tj 1
  tg 1
  ec 1
  rs 1
  re 1
  jobs 1
  cm 1
  int 1
  tm 1
  pe 1
  pn 1
  aero 1
  hk 1
  md 1
  mg 1
  uy 1
  mw 1
  ug 1
  vc 1
  ae 1
  ai 1
  al 1
  vn 1
  as 1
  xxx 1
  kg 1
  sr 1
  st 1
  kr 1

Interestingly of the 2760 zones, 653 of them (almost a quarter!) also have DS records in their parent zones, so technically they don't need to be in the DLV registry at all. This includes three TLDs: th, ua, and kg. I wonder what the motivation for additionally maintaining keys in a DLV registry is. One theoretical reason might be to have an off-path database of keys that could be audited in case of an attack in the normal delegation chain.

Below are the sixteen zones inside .EDU:

  bucknell.edu                 DS exists
  internet2.edu                DS exists
  k-state.edu                  DS exists
  cs.kent.edu                  kent.edu not signed
  ksu.edu                      DS exists
  ai.mit.edu                   mit.edu not signed
  csail.mit.edu                mit.edu not signed
  dlp.mit.edu                  mit.edu not signed
  lcs.mit.edu                  mit.edu not signed
  npitest.psu.edu              psu.edu not signed
  ualr.edu                     DS exists
  ucaid.edu                    DS exists
  cse.ucdavis.edu              DS exists
  math.ucdavis.edu             DS exists
  ucr.edu                      DS exists
  maf.wisc.edu                 wisc.edu not signed

The EDU TLD is signed and has single registrar (Educause) that has supported DNSSEC for a long time. All the second level domains in the list above also have DS records in EDU, so they don't really need to also have DLV records. Most of the third level domains (one at Kent State U, four at MIT, one at Penn State, and one at U of Wisconsin) have parents that are not yet signed, so that makes sense. However, the two third level domains, cse.ucdavis.edu and math.ucdavis.edu have DS records in ucdavis.edu, so don't need DLV records either.
 
Shumon Huque

Network Engineer Job at Penn

We have an opening for a Senior Network Engineer in the University of Pennsylvania's Engineering group.

        https://jobs.hr.upenn.edu/applicants/Central?quickFind=197742

This position will be part of a small team that works very closely with our Network Operations group, offering final tier escalated support, researching new network designs, architectures & technologies, evaluating new equipment, designing and deploying related software and hardware systems.

The Engineering group is also involved in designing and operating a range of other services, including DNS, DHCP, Authentication & Authorization systems, Voice over IP, etc. So there are opportunities to get involved in many areas.

The candidate for this position will generally need to have a strong networking and programming background, as well as strong familiarity with UNIX and UNIX-like operating systems.

LOPSA East Class reviews - IPv6 & DNSSEC

I just received the reviews and attendee feedback for the IPv6 and DNSSEC classes I taught at the recent LOPSA-East conference. So far my recent stint as a technical course instructor at various conferences has been going well. Students are generally very pleased with the courses, and the positive feedback often results in invitations to teach at other venues.

The DNSSEC class is new. At past conferences, I've taught a combined DNS and DNSSEC class. But I've received feedback that many folks would like to see a course focussed on DNSSEC, so I created one. I also incorporated some live demos of setting up DNSSEC, which attendees found to be very useful.

I'll most likely be teaching these classes again at the USENIX LISA conference in Washington, DC later this year.

The possible responses for each question in the feedback survey are "Unsatisfactory", "Missed Some Expectations", "Met Expectations", "Exceeded Expectations", and "Greatly Exceeded Expectations". The data below is only for the (small) subset of the class that offered feedback of course.

IPv6 Course Feedback

==> SA1: Using and Migrating to IPv6 / Huque

Rate this training session: [Description matched the contents of the class]
    * Greatly Exceeded Expectations
    * Exceeded Expectations
    * Greatly Exceeded Expectations
    * Met Expectations
    * Met Expectations
    * Greatly Exceeded Expectations
    * Exceeded Expectations
    * Greatly Exceeded Expectations

Rate this training session: [Class material was useful to my job]
    * Greatly Exceeded Expectations
    * Met Expectations
    * Greatly Exceeded Expectations
    * Met Expectations
    * Met Expectations
    * Exceeded Expectations
    * Exceeded Expectations
    * Greatly Exceeded Expectations

Rate this training session: [Instructor was knowledgeable]
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations

Rate this training session: [Instructor was able to answer students questions]
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations

Rate this training session: [Course material quality]
    * Greatly Exceeded Expectations
    * Exceeded Expectations
    * Greatly Exceeded Expectations
    * Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Exceeded Expectations
    * Greatly Exceeded Expectations

What was the single BEST part of this class?
    * good material, awesome presenter
    * Excellent balance of technical detail with beginner introduction
    * instructor clear experience and ability to communicate topic
    * He has done the work, and could provide many answer from experience
    * Quality of the instructor - good speaker and very knowledgable.
    *
    * The instructor was able to explain a very complex topic clearly & in terms that are directly applicable to my future use of the material.
    * Shumon's depth of knowledge; he adapted what we covered and how fast we were going, on the fly! AWESOME instructor.

Name one aspect of this class that NEEDS IMPROVMENT?
    * needs to be longer
    *
    * wants more time to work in.
    * pacing, which material to emphasis. I thought the first part of the material could have been covered a bit faster, and more time on the meatier issues
    * The class seemed to detail a lot of 'differences between ipv6 and ipv4' and protocol internals in favor of 'how do I actually deal with migration issues'. A better mix would be nice, but I understand that unless you know of the differences, it can be hard to concentrate on implementation.
    *
    * Access to a Lab for a demo might add to the session.
    * nothing, run this class again. MAYBE, talk him into making another class focused on migrating your organization from v4 to v6... so people can do 'intro to ipv6' if they need, then another session on migration strategies.

Should LOPSA offer this class in the furture?
    * Yes
    * Yes
    * Yes
    * Yes
    * Yes
    * Yes
    * Yes
    * Yes

DNSSEC Course Feedback

==> SA4: DNSSEC (DNS Security Extensions) / Huque

Rate this training session: [Description matched the contents of the class]
    * Met Expectations
    * Exceeded Expectations
    * Greatly Exceeded Expectations
    * Exceeded Expectations
    * Greatly Exceeded Expectations

Rate this training session: [Class material was useful to my job]
    * Met Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Exceeded Expectations
    * Greatly Exceeded Expectations

Rate this training session: [Instructor was knowledgeable]
    * Met Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations

Rate this training session: [Instructor was able to answer students questions]
    * Met Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations
    * Greatly Exceeded Expectations

Rate this training session: [Course material quality]
    * Met Expectations
    * Missed Some Expectations
    * Greatly Exceeded Expectations
    * Exceeded Expectations
    * Greatly Exceeded Expectations

What was the single BEST part of this class?
    * DNSSEC appears do-able
    * My impression of DNSSEC went from theoretically possible to practical in a very short time. Something that is alluded me for quite some time.
    *
    * Best part was seeing the live application of theory in an enterprise environment.
    * Shumon's depth of knowledge; he adapted what we covered and how fast we were going, on the fly! AWESOME instructor. He's so good, we had wonky wifi, and he just ran demos through Bind on his Mac. nice.

Name one aspect of this class that NEEDS IMPROVMENT?
    *
    * Materials were not but will be posted to the presenters site
    *
    * nothing negative to say.
    * nothing, don't change anything, run it again!

Should LOPSA offer this class in the furture?
    * Yes
    * Yes
    * Yes
    * Yes
    * Yes

100 Gigabit Ethernet at Penn

This summer, the University of Pennsylvania is upgrading its campus core routing equipment (in fact we're in the midst of this upgrade right now). This is basically an upgrade to the set of large routers that form the center of our network.

The current core topology consists of 5 core routers (and also 2 border routers) interconnected by two independent layer-2 switched 10 Gigabit Ethernet networks. Each of the core routers is located in one of five geographically distributed machine rooms across the campus. A rough diagram is shown below.

This diagram also shows the current external connections to/from the campus network - we have three links (each 10 Gigabit Ethernet) to Internet Service Providers (ISPs). And two connections to MAGPI (the regional Internet2 GigaPoP operated by us), via which we access a 10 Gigabit Ethernet connection to Internet2. The Internet2 connection is shared amongst Penn and other MAGPI customers, which are mostly Research & Education institutions in the geographic area.

The core interconnect is being upgraded to 100 Gigabit Ethernet (a ten-fold increase in link bandwidth). It would be cost prohibitive to fully replicate the current design in 100 Gig (since this equipment is still very expensive) so the interconnect design has been adjusted a bit. Instead of two layer-2 switch fabrics interconnecting the routers, we are deploying the core routers connected in a 100 Gig ring (see the diagram below). When the final design is fully implemented, each core router will have a 10 Gig connection into each of the border routers (this will require some additional upgrades to the border routers, which are expected to happen later this year). The topology redesign has fewer links, and in the final count (summing the bandwidth of all the core facing links), the new core will have about 5 times the aggregate bandwidth of the old one. The maximum (shortest path) edge to edge diameter of the network increases by one routing hop.

100 Gigabit Ethernet is today's state of the art in transmission speed. The next jump up will likely be 400 Gigabit Ethernet for which the IEEE already has a study group launched and several preliminary designs under consideration.

Not depicted in this diagram is the rest of the network towards the end systems. Below the layer of core routers, are smaller routers located at the 200 or so buildings scattered around campus. Each building router is connected to two of the core routers. The building routers feed wiring closets inside the building, which house layer-2 switches that network wallplates are connected to.

In the process of the upgrade, we are also changing router vendors. The current core routers, Cisco 7609 series routers with Sup7203BXL supervisor engines, have served us well. They were originally deployed in the summer of 2005, and have been in operation well past their expected lifetime.

As is our practice, we issued an RFI/P (Request for Information/Purchase) detailing our technical requirements for the next generation routers and solicited responses from the usual suspects, selecting a few vendors whose equipment we bring in for lab testing, followed by a selection.

The product we've selected is the Brocade MLXe series router, specifically the MLXe-16 - this router can support 16 half height, or 8 full height (or a mixture of full/half) line cards, as well as redundant management and switch fabric modules.

A product description of the MLXe series is available at:
http://www.brocade.com/downloads/documents/data_sheets/product_data_sheets/MLX_Series_DS.pdf

The photo below is one of the routers (prior to deployment) in the Vagelos node room (one of 5 machine rooms distributed around campus where we house critical networking equipment and servers).Going from left to right, this chassis has two management modules, one 2-port 100 Gigabit Ethernet card, six 8-port 10 Gigabit Ethernet cards, four switch fabric modules, two more 8-port 10 Gigabit Ethernet cards, and three 24-port Gigabit Ethernet cards.

One of these routers was deployed in production last week. The rest should be up and running by the end of this month or by early July.

(The full set of photos can be seen here on Google Plus)

Shown below is the 2-port 100 Gigabit Ethernet card, partially inserted into the chassis, showing the CFP optical transceiver modules attached.

Unlike preceding generations of ethernet, with 100 Gigabit Ethernet, the transmission technology uses multiple wavelengths in parallel (although there are parallel fiber implementations also). The current IEEE specifications (802.3ba) specify four lanes of 25Gbps. However a number of key vendors in the industry, including Brocade, formed the MSA (Multi Source Agreement) and designed and built a 10x10 (10 lanes of 10Gbps) mechanism of doing 100 Gig, at much lower cost than 4x25Gbps, operating over single mode fiber at distances of 2, 4, or 10km. This is called LR-10 and uses the CFP (C Form factor pluggable) media type.

Pictured below (left) is a Brocade LR10 100 Gigabit Ethernet CFP optical module installed in 100 Gig line card with a single mode fiber connection (LC). On the right is an LR10 CFP module taken out of the router.

Close up of the 8-port 10 Gigabit Ethernet module, and several 24-port Gigabit Ethernet modules. To connect cables to them, we need to install small form factor pluggable transceivers into them, SFP+ for the 10 gig, and SFP for the 1 gig.

Pictured below is one of the five Cisco 7609 routers that will be replaced.

One of the Penn campus border routers, a Juniper M120, is shown below. This is also scheduled to be upgraded in the near future to accommodate 100 Gig and higher density 10 Gig, although the product has not yet been selected/finalized.

Below: A Ciena dense wavelength division multiplexer (DWDM). Penn uses leased metropolitan fiber to reach equipment and carriers in 401 North Broad street, the major carrier hotel in downtown Philadelphia. We have DWDM equipment placed both at the campus and the carrier hotel to carry a mixture of 1 and 10 Gig circuits and connections across this fiber for various purposes. This equipment is also scheduled to be upgraded to allow us to provision 100 Gigabit Ethernet wavelengths between the campus and the carrier hotel.

High Performance Networking for Researchers

Penn is a participant in the National Science Foundation (NSF) funded DYNES (Dynamic Network Systems) project, which provides high bandwidth dedicated point to point circuits between (typically) research labs for specialized applications. Popular uses of this infrastructure today include high energy physics researchers obtaining data from the LHC and other particle accelerator labs, and various NSF GENI network research projects.

Earlier this year, we completed a grant application for the  NSF "Campus Cyberinfrastructure - Network Infrastructure and Engineering (CC-NIE)" program. I spent a large amount of time in March of this year with several Penn colleagues in preparing the application. If Penn does win an award (we'll find out later this year), we will be deploying additional dedicated network infrastructure for campus researchers, bypassing the campus core and with 100 Gbps connectivity out to the Internet2 R&E network. A rough diagram of how this will look is below.

Software Defined Networking

There's a huge amount of buzz about Software Defined Networking (SDN) in the networking industry today, and a number of universities are investigating SDN enabled equipment for deployment in their networks. Of the big router vendors, Brocade does appear to have one of the better SDN/openflow stories thus far. The MLXe series already supports an early version of Openflow (the portion of SDN that allows forwarding tables of switches/routers to be programmed by an external SDN controller).

Penn is building an SDN testbed in our network engineering lab, primarily to investigate its capabilities. For us, SDN is still largely a solution in search of a problem. We run a very simple network by design, whose primary purpose is connectivity and high performance packet delivery. The most probable use case in our future, virtualization of the network, is likely better achieved with a proven technology like MPLS first. But we'll keep an eye on SDN and its evolution. We do want to support research uses of SDN though. Several faculty members in the Computer Science department are interested in SDN, and the NSF CC-NIE grant will allow us to build some SDN enabled network infrastructure separate from the core production network to accommodate their work.

-- Shumon Huque

Former Student to Caltech and CERN

In addition to my full time job, I sometimes teach a course in Penn's Engineering School - specifically a Telecom Lab course on network protocols (mostly routing). The material covered in the course includes interior routing protocols like RIP, OSPF, and IS-IS; BGP for exterior routing; Multicast Routing; and MPLS (traffic engineering, Layer-2 and Layer-3 VPNs). I also cover the DNS and DHCP protocols in a fair amount of detail. All the lab assignments use both IPv4 and IPv6 extensively.

Indira is one of my former students, and also served as my teaching assistant the semester following the one during which she took the class. She just graduated (Masters Degree in Telecommunications) and is moving to Geneva, Switzerland for a full time job. She stopped in to see me last week on the day she was leaving and we snapped a few photos together.

The job is a full time network engineer position with Caltech, but based at CERN in Switzerland, working with some Caltech colleagues I know (Artur Barczyk, Azher Mughal, Harvey Newman) from Internet2 and various other R&E conferences. Among other things, Caltech is involved in operating USLHCNet, a very high speed network that provides transatlantic connectivity between computing facilities at CERN's  Large Hadron Collider (LHC) and computing facilities at major US particle accelerator labs like Fermilab and Brookhaven.

Harvey was also one of the principal investigators for the NSF funded DYNES (Dynamic Network System) project, of which Penn is a participant. DYNES, via the Internet2 network infrastructure, provides dynamically allocated dedicated point to point circuits between remote research labs (a common endpoint is the LHC). Penn researchers were involved in building the LHC's ATLAS detector, and played a role in the Higgs particle discovery last year.

Congratulations and good luck to Indira - I'm sure she has a bright and productive career ahead of her. She left me a small gift - a box of chocolates from Kazakhstan, pictured below. The box is almost too attractive to open, so I haven't yet.

Another talented former student and Teaching Assistant, Sangeetha had been working for me part time in Penn's Networking department on various projects. She also recently left (due to her advisor leaving Penn), transferring into the Ph.D program (CS) at the UIUC.

I'm planning to cancel my teaching appointment, since I don't really have the time for it, given the demands of my full time job. I originally decided to teach the course as a favor to my colleague, Roch Guerin, but it's actually been quite a fun and rewarding experience for me (and hopefully my students). However, now that Roch is leaving Penn to take the CS department chair position at the University of Washington at St. Louis, it looks like Penn is winding down the TCOM program anyway - a good time for me to make an exit.

I'm planning to write a more detailed blog post about my teaching experience at Penn. More on that later.

--Shumon Huque.