Saturday, October 21, 2000
Topic/Presenter |
---|
Full AbstractThis talk will discuss the mechanisms used in optical networks to provide highly available services, and their applicability to IP networks. Topics to be covered include:
|
RecordingsFull AbstractTopics covered in this tutorial include:
NEW: Other router vendors are welcome to participate in this session by supplying IS-IS configs comparable to those shown by Abe. Redback Configs Example An Example of Redback ISIS configuration October 12, 2000 [email protected] (1) Redback router IS-IS setup Router "sunnyvale-c1" has 3 IS-IS interfaces and are connected to IS-IS instances "Optical-Backbone" on fe1/1, to instance "IP-Metro-SanJose" on sr2/1 and fe3/1. IS-IS Authentication is applied to all IS-IS packets on instance "Optical-Backbone" with hmac-md5, and authentication is applied only on IIH packets on instance "IP-Metro-SanJose". IS-IS level-2 prefixes are leaked into level-1 with the prefix-list policy on "Optical-Backbone". The IS-IS "Optical-Backbone" prefixes are redistributed into instance "IP-Metro-SanJose" on level-1 with a route-map policy applied. IS-IS instance "IP-Metro-SanJose" is running with "wide" metric style. ----------------------------------------------------------------------- (2) show IS-IS portion of the configuration [local]sunnyvale-c1#show configuration isis Current configuration: context local ! interface fe1/1 ip address 10.1.1.1/24 ip router isis Optical-Backbone isis circuit type level-2-only ! interface sr2/1 ip address 10.3.1.1/24 ip router isis IP-Metro-SanJose isis circuit type level-1 isis authentication key-chain bar ! interface fe3/1 ip address 10.7.1.1/16 ip router isis IP-Metro-SanJose isis authentication key-chain foo type simple ! router isis Optical-Backbone net 47.0001.1111.1111.1111.00 interarea-distribute l2-to-l1 prefix-list filter-100/8 authentication key-chain foo ! router isis IP-Metro-SanJose net 49.0002.1111.1111.1111.00 redistribute isis Optical-Backbone level-1 route-map metro-sanjose metric-style wide [local]sunnyvale-c1# ----------------------------------------------------------------------- (3) show IS-IS interface information [local]sunnyvale-c1#show isis interface [local]sunnyvale-c1#show isis interfaces IS-IS interface(s) for tag Optical-Backbone: Interface L P State Level-1-DR Level-2-DR Metric fe1/1 2 Up sunnyvale-c1.01 10 Total IS-IS Interface(s): 1 IS-IS interface(s) for tag IP-Metro-SanJose: Interface L P State Level-1-DR Level-2-DR Metric sr2/1 1 Up sunnyvale-c1.01 10 fe3/1 3 Up sunnyvale-c1.02 sunnyvale-c1.02 10 Total IS-IS Interface(s): 2 [local]sunnyvale-c1# ----------------------------------------------------------------------- (4) show IS-IS interface detail information [local]sunnyvale-c1#sh isis interfaces detail IS-IS interface(s) for tag Optical-Backbone: fe1/1 Up, Ckt level: 2, lan, IP address: 10.1.1.1/24, Ckt id: 0x01 Level Adjs Priority Hello Hold Auth Blocked Metric 2 1 64 5 24 10 Total IS-IS Interface(s): 1 IS-IS interface(s) for tag IP-Metro-SanJose: sr2/1 Up, Ckt level: 1, lan, IP address: 10.3.1.1/24, Ckt id: 0x02 Level Adjs Priority Hello Hold Auth Blocked Metric 1 1 64 9 24 md5 10 fe3/1 Up, Ckt level: 3, lan, IP address: 10.7.1.1/16, Ckt id: 0x03 Level Adjs Priority Hello Hold Auth Blocked Metric 1 1 64 4 24 simple 10 2 1 64 5 24 simple 10 Total IS-IS Interface(s): 2 [local]sunnyvale-c1# ----------------------------------------------------------------------- (5) show IS-IS adjacency information [local]sunnyvale-c1#show isis adjacency IS-IS Adjacenc(ies) for tag Optical-Backbone: SystemId Interface Lvl State Holdtime SNPA Uptime santa-cruz-b1 fe1/1 2 Up 22 00d0.b714.1512 01:18:33 Total IS-IS Adjacenc(ies): 1 IS-IS Adjacenc(ies) for tag IP-Metro-SanJose: SystemId Interface Lvl State Holdtime SNPA Uptime palo-alto-c2 sr2/1 1 Up 18 0090.27af.4269 00:06:15 4444.4444.4444 fe3/1 2 Up 22 0030.949f.cb00 00:06:16 4444.4444.4444 fe3/1 1 Up 22 0030.949f.cb00 00:06:19 Total IS-IS Adjacenc(ies): 3 [local]sunnyvale-c1# ----------------------------------------------------------------------- (6) show IS-IS redistributed or leaked prefixes [local]sunnyvale-c1#sh isis routes redistribute IS-IS Redistributed route(s) for tag Optical-Backbone, on Level-1 Prefix L Type Source Metric M-Type Summarized 100.0.0.0/24 1 Leak isis 15 Int 100.0.1.0/24 1 Leak isis 15 Int 100.0.2.0/24 1 Leak isis 15 Int 100.0.3.0/24 1 Leak isis 15 Int 100.0.4.0/24 1 Leak isis 15 Int Total IS-IS Redistributed Route(s) in level-1 for tag Optical-Backbone: 5 IS-IS Redistributed route(s) for tag IP-Metro-SanJose, on Level-1 Prefix L Type Source Metric M-Type Summarized 100.0.0.0/24 1 Ext isis 20 Ext Total IS-IS Redistributed Routes in level-1 for tag IP-Metro-SanJose: 1 IS-IS Redistributed route(s) for tag IP-Metro-SanJose, on Level-2 Prefix L Type Source Metric M-Type Summarized 10.3.1.0/24 2 Leak isis-intf 10 Int 10.7.0.0/16 2 Leak isis-intf 10 Int Total IS-IS Redistributed Routes in level-2 for tag IP-Metro-SanJose: 2 [local]sunnyvale-c1# ----------------------------------------------------------------------- (7) show IS-IS route summary information [local]sunnyvale-c1#show isis routes summary IS-IS route(s) summary for tag Optical-Backbone: Route Type Level-1 Level-2 Summarize(L1/L2) L2-to-L1 Leak IS-IS Route 0 11 - 0 Redistribute 0 0 0/0 Inter-area 5 0 0/0 Summary Address 0 0 0/0 IS-IS interface routes: 1 Route leaking prefix lists: filter-100/8(l2-to-l1) IS-IS route(s) summary for tag IP-Metro-SanJose: Route Type Level-1 Level-2 Summarize(L1/L2) L2-to-L1 Leak IS-IS Route 3 0 - 0 Redistribute 1 0 0/0 Inter-area 0 2 0/0 Summary Address 0 0 0/0 IS-IS interface routes: 2 Redistributed protocols: isis [local]sunnyvale-c1# ----------------------------------------------------------------------- (8) show one IS-IS prefix This prefix 100.0.3.0/24 is learn through level-2 with nexthop of 10.1.1.2 on interface fe1/1. This route is from LSP 2222.2222.2222.00-00 of seq# 0x24 from router santa-cruz-b1. That lsp was last arrived 4:35 ago from interface fe1/1. [local]sunnyvale-c1#show isis route 100.0.3.0/24 IS-IS prefix for tag Optical-Backbone: Prefix Level Metric Interface Nexthop 100.0.3.0/24 2 15 fe1/1 10.1.1.2 Is sourced from LSP(s): LSP ID Seq # System Name Arrive(ago) Interface(from) 2222.2222.2222.00-00 0x24 santa-cruz-b1 00:04:35 fe1/1 [local]sunnyvale-c1# ----------------------------------------------------------------------- (9) some debug IS-IS information This output captured the debug output on isis adjacency events for both send and receive packets on interface fe1/1 with packet source systemID of 2222.2222.2222: [local]sunnyvale-c1#debug isis adjacency filter interface fe1/1 system-id ? String System ID (XXXX.XXXX.XXXX) [local]sunnyvale-c1#$adjacency filter interface fe1/1 system-id 2222.2222.2222 [local]sunnyvale-c1# Oct 11 04:19:34: %ISIS-7-ADJ: rcvd L2 LAN IIH from 00d0.b714.1512 on intf fe1/1 Oct 11 04:19:36: %ISIS-7-ADJ: send L2 LAN IIH on intf fe1/1 Oct 11 04:19:42: %ISIS-7-ADJ: rcvd L2 LAN IIH from 00d0.b714.1512 on intf fe1/1 Oct 11 04:19:43: %ISIS-7-ADJ: send L2 LAN IIH on intf fe1/1 [local]sunnyvale-c1#no debug isis all [local]sunnyvale-c1# Speakers |
Sunday, October 22, 2000
Topic/Presenter |
---|
Full AbstractISPs are regulated by a complex set of rules governing their creation, retention, and disclosure of customer communications and transactions. This session provides an overview of the specific rules in the controlling Federal statute, the Electronic Communications Privacy Act, and the legal consequences of failing to comply. Speakers |
|
Full AbstractIn this talk, we expand on our earlier NANOG presentation with an exploration of what roles inter-domain topology and routing policy play in the process of delayed Internet routing convergence. In our previous talk, we demonstrated that the Internet lacks effective inter-domain path fail-over with backbone routers requiring tens of minutes to reach a consistent view of the network topology after a fault. We also presented a theoretic, upper factorial bound on BGP convergence computation. Speakers |
Full AbstractThe purpose of this panel is to discuss desired route filtering capabilities of services providers (both panel members and attendees), as well as to express perceived shortcomings with the different components required to effectively support large numbers of prefixes (e.g., routing registries, vendor support, management and provisioning, etc.). It's relatively well understood that service providers need to employ customer ingress prefix filters. However, the feasibility and usefulness of inter-provider filters has yet to be realized. Once fully supported, these filters may potentially be used for other applications as well. Speakers |
Monday, October 23, 2000
Topic/Presenter |
---|
RecordingsFull AbstractThis talk provides an overview of the continued evolution of the MAEs, including a technical description of an additional service type that is being rolled out on MAE-ATM. The status of MAE-FDDI and current work on new exchange fabrics will also be covered. Speakers |
RecordingsFull AbstractPublic Internet exchange points have traditionally been built around LAN switches or PVC switches (ATM and Frame Relay.) New communication technologies are becoming readily available, such as MPLS, IP-over-optical, DWDM, and others.
Speakers |
Full AbstractAmber Networks |
Full AbstractInternet Service Providers interconnect in peering and transit relationships in order to provide their customers with access to the global Internet. Previous studies of Internet Operations (see Peering Decision Tree, NANOG 19) in this area have highlighted key challenges facing ISPs that seek additional peering-based (non-transit) interconnections. One challenge is that the peering process is undocumented and the negotiations are veiled under non-disclosure agreements. As a result, peering discussions are hampered with confusion and misunderstandings. This led to the creation of the Peering Simulation Game, first introduced at NANOG 19, which has proven to be effective in highlighting key peering issues, and stimulating discussion amongst the audience and the players of the simulation.
Speakers |
Full AbstractA discussion this summer on the NANOG list prompted Sassaman to consider ways that the ISP community can benefit and benefit from a robust PGP keyserver network. This BOF provides a forum for discussing the integration of PGP services into the Internet as a function that NSPs could provide. Speakers |
Full AbstractSpeakers |
Full AbstractWe are actively involved in ongoing efforts in the IETF, Optical Internetworking Forum, and Optical Domain Service Interconnect to standardize IP-centric control architecture and protocols for optical networks. Our objective is to discuss the following issues and get service providers' feedback on them:
Speakers Debanjan Saha, Tellium |
Full AbstractThere is currently a worldwide shortage of 10Gbs optical components for manufacturing SONET OC-192 transponders. As a result, OC-192 interfaces for routers and DWDM equipment are very expensive and difficult to obtain. Carriers have estimated that about 75% of all SONET interfaces connect to other equipment in the same facility, with a link length of under 300m. The Optical Internetworking Forum (OIF) has been working for over a year on Very Short Reach (VSR) OC-192 interfaces which trade link length for lower cost and better manufacturability. Speakers |
Full Abstract
The Network Reliability and Interoperability Council, an industry group which has advised the FCC on telecommunications reliability, has, for the first time, expanded its vision to include a one year voluntary trial monitoring the reliability of non-traditional networks such as the Internet. Mobile devices such as wireless palms and browsers on cell phones have created pressure for making new wireless spectrum available for technological advances. Increased Internet usage has increased demand for bandwidth and created a new broadband market to the residence; the FCC's recent Section 706 Report examined whether advanced broadband services are being deployed to all Americans in a reasonable and timely manner. Finally, an intense controversy has been brewing concerning whether cable services should have an obligation to open facilities to some form of non-discriminatory access by unaffiliated ISPs; the FCC has recently initiated an inquiry to look at the issue of "open access." Speakers |
RecordingsFull AbstractSpeakers |
Full AbstractSURFnet, the national network for research and higher education in The Netherlands, is engaged in the GigaPort Project with the aim of building the next generation Internet in The Netherlands. SURFnet is handling all traffic for its research and higher education users, as opposed to the model in North America, where universities have to have a commercial ISP to handle commodity traffic and can have an Abilene and/or vBNS connection for just research traffic.
Speakers |
Full AbstractSpeakers |
Tuesday, October 24, 2000
Topic/Presenter |
---|
RecordingsFull AbstractThe FBI's National Infrastructure Protection Center (NIPC) has observed a recent increase in DDoS attacks, with many newly discovered amplifier systems in use. This talk will describe recent tool deployments and ask for attendee input about:
Presentation slides. Speakers |
RecordingsFull AbstractThe primary purpose of this presentation is to list and analyze the currently available Global Server Load Balancing (GSLB) methods. A new GSLB technique along with the testing results is presented that is shown to be the most efficient solution in some network setups. Various GSLB network scenarios are considered, ranging from a set of few GSLB'ed servers to global content delivery ASP network setups. What GSLB method should be used in what network setup is also discussed. Speakers Dmitri Krioukov, Nortel |
Full AbstractThis presentation describes an approach to IP multicast performance measurement on the NSF's very-high-speed Backbone Network Service (vBNS). Using OC-12c attached workstations acting as multicast senders or receivers distributed throughout the vBNS backbone, we create arbitrary topologies, generate synthetic IP multicast traffic and measure loss encountered. The presentation includes packet loss results as a function of time and router hop count and an analysis of the join latency incurred. Speakers |
|
RecordingsFull AbstractThis talk describes a tool for characterizing the TCP behavior of a remote host on the Internet. The specific goal in building this tool was to answer the question, "What fraction of web servers use NewReno instead of Reno or Tahoe TCP congestion control mechanisms, for TCP connections with non-Sack-enabled clients? The more general goal was to provide a tool for efficiently probing the TCP congestion control behaviors of remote hosts in the Internet. We report on both the tool and our experimental results. Speakers |
Full AbstractI am very interested in finding out anything about what fraction of routers in the Internet do or don't use active queue management (e.g., RED), and what experiences with RED have been like. While it is not so hard to run tests to find out about the TCP congestion control behaviors of web servers, I don't know of any way to find out, from the outside, about the current queue management behavior of routers. And it would be helpful to know more than I do now ... Please contact me at the meeting or send email if you'd like to exchange information about this topic. Speakers |
RecordingsFull AbstractSpeakers Van Jacobson, Packet Design Haobo Yu, Packet Design |
RecordingsFull AbstractSpeakers |