Davide Salomoni, July 19, 1999
Notes on Networkers í99, Vancouver BC, 7/13 Ė 7/16 1999
Introduction to Voice and Telephone Technology
A general overview of analog and digital technologies (plus voice coding, compression techniques, and signaling).
Deploying VPNs and Tunneling Technology
Very interesting overview of tunneling protocols and techniques;
- At the dial/access level (of potential interest to SLAC mobile users), 3 solutions:
- PPTP/MPPE (MPPE should only be used in its stateless mode). Available in 12.1(3)T.
- L2TP/IPSec (needs client software, but this is bundled into Windows2000), more robust from a security standpoint.
- IPSec (only supports IP).
- Enterprise VPNs (i.e., remote offices, or possibly application-specific VPNs), a lot of possibilities:
- Policy routing / ACLs
- IP in IP (similar to GRE, only limited to IP)
- L2TP router-to-router (maybe available next year)
- GRE with private addresses
- IPSec in tunnel mode (the configuration here seems quite complicated, and not many people seemed to be already using it)
- Service provider VPNs Ė quite often with Outsourcing and Wholesale Dial. Very interesting for the business world, I donít see a direct application to the SLAC needs here unless we want to revive an HEPnet-like VPNÖ
- Cisco is pushing a lot for MPLS-based VPNs; these should theoretically overcome the limitation of pure tunneling technologies, which donít provide QOS guarantees (or at the very best they just use the IP ToS byte). So, the Cisco recipe is:
- MPLS at the core, with proper AAA servers.
- L2TP if needed inside a routing domain; the MPLS attributes will be carried to other domains via BGP.
This solution has the drawback of requiring an upgrade of the existing backbones.
I believe one or more of the VPN technologies could well be tested with our future network testbeds (e.g., NTON).
Evolution of Network Management Technologies
A lot of words about the integration of the several management technologies we have today (Telnet, SSH, IPSec, SNMPv1/2/3, tftp/rcp, LDAP).
- SSH will provide (IOS 12.0(4)T) encryption for the CLI
- IPSec can be used to establish a secure management tunnel between the management station and the devices to be managed (regardless of whatís in between)
- SNMPv1 is finally seen as dead; Cisco recognizes that not much effort has been put into SNMPv2, and that only SNMPv3 will provide a serious security framework. IOS 12.0(3)T supports the SNMPv3 USM (User Security Model).
- But anyway, the industry feels a new model for application data exchange (i.e. a new data model, tracking all the variables of a managed device) is needed, since SNMP is in essence not flexible enough. Also, itís important to avoid dependencies on a set of APIs. The solution is called CIM (Common Information Model), and will be used to provide open interoperable schemas to describe objects. The info defined in this model will be accessed via XML (possibly using the HTTP or HTTPS protocols), hence no API is needed. At the very end, all of this fits into the use of a true Directory Service (possibly integrating the existing LDAP, NDS, Microsoft AD, etc).
- Service Monitoring: obviously all these tunnels, encryptions, etc, change the NMS approach. The proposed Cisco solution is RTR (Response Time Reporter), available from IOS 11.2 on. Itís basically a software-based probe, integrated in the IOS, that can send packets of various type at specified intervals to other devices (routers or hosts). This looks very interesting to me, especially with IOS 12.0(3), which supports RTR not only with ICMP (i.e. ping-like), but also with UDP, TCP-Connect, HTTP, DNS, and VoIP, which makes it more tied to the application level. Itís interesting that RTR also reports all the active network paths, showing the RTT for each of them hop-by-hop. RTR can be simply manually configured on Cisco routers, or it can be used together with IPM (Internet Performance Monitoring), a client-server application that produces nice graphs (the server only runs on Solaris at the moment, the client is available for Solaris and WNT). Thresholds could be set to alert a NMS.
- Ciscoworks2000 will have a traceswitch-like capability in a future release!
Troubleshooting the Catalyst 5000 series
Very interesting talk on common problems with Catalyst switches. Particular attention has been given to VTP problems and to hints on configuring trunks, Fast/Giga EtherChannels, and Spanning Trees. A note on trunking: while ISL supports multiple spanning trees, IEEE 802.1q does not (i.e., thereís a single ST for all VLANs Ė which isnít beneficial for load sharing, for example). Cisco has therefore developed a (proprietary) extension to 802.1q, called PVST+ (Per-VLAN Spanning Tree) to support multiple ST.
Thorough discussion on the architecture of several router models.
Advanced Security Technology Concepts
Very detailed talk on cryptography concepts and applications. Most of the discussion has been around IPSec techniques and implementation issues.
Advances in Multicast Technology
A lot of new things are going on in this area. PGM (Pragmatic General Multicast) could be of interest to SLAC applications; it is basically a multicast-enabled reliable transport layer protocol. This could overcome some of the difficulties related to UDP multicast currently seen e.g. in the BaBar DAQ system. Many networks have already deployed MBGP together with MSDP (Multicast Source Discovery Protocol, to overcome the well-known third-party RP-problem with PIM-SM). Futures include the long-awaited BGMP and (it will be interesting to see how and if it works!) the dynamic allocation of multicast addresses (MASC, Multicast Address Set-Claim). To support multicast with asymmetric (e.g., ADSL) or unidirectional (e.g., satellite) links, thereís UDLR (Unidirectional Link Routing).
We could use the NTON network to establish a multicast path with reasonable bandwidth to the outside world, couldnít we?
LAN Switch Architectures and Performance
Normal talk on switching architectures Ė with some discussion of the architecture of the Catalyst 4000, 5000, 6000, 8500; an OC-12 ATM card for the C6500 will be available around December. Other enhancements to the C6500 family include the replacement of the current MSM (Multilayer Switching Module) with the MSFC (Multilayer Switch Feature Card), which will free a slot in the chassis (itís a daughtercard of the motherboard, and the MSM will have to be removed Ė so much for investment protection) and provide IP and IPX routing performance up to 150 Mpps. Also, the fabric will be upgradable to ~256 Gbps.
Comment on the availability of ATM on the C6500: as it became apparent in another discussion (see below), this is seen as an aid to integrate "legacy" ATM LANs with Fast/Gigaethernet switching, more than as an extension of the C6500 platform into the WAN arena.
Advanced Optical Technology Concepts
The title was a bit misleading: all of the talk was concentrated in the description of the new Cisco-proposed DPT (Dynamic Packet Transport). This is a Cisco patent pending technology based on the SRP (Spatial Reuse Protocol): basically, itís a new L2 encapsulation protocol to be used (in the Cisco vision) for LAN, MAN and WAN applications. In a way, itís similar to PPP, in that while we now have Packet Over SONET (POS) using PPP encapsulation, with this solution weíd have DPT over SONET (or SDH) with SRP encapsulation (i.e., in both cases we have SONET framing at the lower layer). Its plus should be scalable bandwidth (up to 64 stations on the SONET ring, although the speaker himself doubted there will be such a large ring anytime soon), spatial reuse of bandwidth inside the ring (no tokens involved), fairness (I personally have some doubts on the fairness algorithm used), survivability in case of node/fiber failures, and adaptability to LAN, MAN and WAN solutions. The initial implementation of DPT will be on a 2 ports OC-12 card (due end of July) and on a single port OC-48 card (due end of the year); the target platform for both cards is the GSR.
My opinion is that this technology could, at this point in time, be of interest to large ISPs to design/upgrade POP interconnections or MANs. It could also be used to build a campus ring at 2x622M (for example), but I donít see the point of it now (my guess is also that it would be a hell more expensive than a traditional solution based on multi-gigabit ethernet backbones).
Video Broadcast/Video-on-Demand Product Directions
A commercial presentation of the Cisco IP/TV product, which allows typically Broadcast Video (i.e., one or more scheduled one-to-many [multicasted] streams), and Video-on-Demand (i.e., a point-to-point stream from a source to a user). IP/TV is not a product used for Video Conferencing.
I asked to the Cisco engineers a couple of questions that popped up in discussions with other people of the SLAC networking group.
- Secure connections to the routers
I.e., how do you connect securely to a router? Answer: turn on AAA and use Radius or Tacacs+; Tacacs+ is preferred to Radius, because it will allow granularity in specifying permissions for individual users, down to the single command (e.g., a user could be allowed to do a "write terminal", but not a "write erase"). Note that with neither Radius nor Tacacs+ the communications will be encrypted, though (just the authentication); for encrypted communication, one has to use SSH, available with IOS 12.0(4)T.
- NAT and Telnet
I.e., how can we use a router to redirect telnet connections to a special-purpose server that informs the users that telnet is not allowed? Can we use NAT? Answer: itís apparently not possible to use NAT to redirect telnet connections to a special server (in short, NAT is only able to rewrite source addresses, not destination addresses). The guy at the clinic suggested the use of the Cisco PIX firewall: every outgoing packet should cross the firewall and, if itís a telnet packet, a Tacacs+ server can be checked for permissions; the server would then be instructed not to allow telnet and would discard the packet, sending a message back to the user.
My comment here is that it does not seem very sensible to me for SLAC to buy a device (the PIX) that, as per the Cisco literature, only scales up to the 7200 series: and in our case it would have to be put behind a router (GSR or whatever) having OC-12+ WAN links, thus most likely becoming a serious bottleneck.
New cards for the GSR:
- A DPT-based 2xOC-12 (end of July)
- A DPT-based 1xOC-48 (end of the year)
A new GSR (the GSR+) will come out in about 6 months. It will "probably" be downward compatible in terms of the cards used; it will have a higher capacity crossbar fabric.
The "general Cisco perception" is that Ipv6 will not happen at once, and that itís not going to be a soon-to-be-available technology. Now that we have hardware-based L3 switches (as in the C6500) that rely extensively on the Ipv4 address format, it will not come for free to upgrade those devices to Ipv6; moreover, there is some concern in terms of the Ipv6 memory requirements. With regard to the integration of VoIP and Ipv6, the requirements are simply said not to be there. By the way, ARIN has begun allocating Ipv6 addresses, following the recent approval of "Ipv6 Assignment and Allocation Policy" by IANA.
- Directory services
A lot of talks here and there about these things. The latest "Internet Week" issue has an interesting article on the directory services. The pie-chart included shows that IT managers believe weíll have several standards: NDS (31.4%), Microsoft Active Directory (28.6%), Pure LDAP (13.3%), Metadirectory (3.8%) and a combination of directories (22.9%). Interestingly, 68.6% of the IT managers of the poll plan to use directory services to centrally manage both their networks and applications (see below). Cisco plans to use directory services to supplement (at the beginning) information provided by SNMP. The directory services will also overcome the need of constantly producing up-to-date SNMP MIBs, because there will be just one source of info on the products Ė namely, the directory service (while we now have e.g. source code, then the CLI and then SNMP MIBs).
- General directionsIt seems to me that the "Cisco vision" is quickly ruling out ATM, both on LAN and on WAN. This may not immediately be the case for ISPs that have committed a lot of resources to the ATM technology. I havenít heard anything in particular on WDM or 10Gb Ethernet, but it looks like thereís already the assumption that bandwidth is not seen as "the problem" anymore (this was one of the rationales behind ATM). Therefore, Cisco is pushing quite a lot for the already-available (in contrast with what they now define "theoretical approaches" like Ipv6) ways of defining VPNs with QOS (aka MPLS). Voice over IP is strongly seen as part of this vision, and the demo at the plenary session (with VoIP, IP telephones, and web-accessible voice mails) clearly showed this. Multicasting is also well integrated in the framework as an optimized way of transferring application data (and "voice is an application", as itís been said in one of the sessions).
A line I believe particularly intriguing is that of integrating network and application management; this means to me that the network layer, and the network engineers with it, will have to shift more toward the application layer and provide service levels at this layer. This is good news for mission-oriented networks like ours (also given the fact that after all we should be application-providers/supporters, rather than network providers). The impression I have now of this shift is that, since the integration services are not (entirely) there, weíll have to struggle a bit and keep on learning a lot about the new facilities that are already available and work out their integration ourselves. I believe itís also instrumental that we try and follow the new developments as closely as possible.
CCNA (Cisco Certified Network Associate)
Got my CCNA! J