- Test - lists.nanog.org

Re: California hits stage 3 power emergency
by Sean Donelan 11 Jan '01

11 Jan '01

On Thu, 11 January 2001, Dalvenjah FoxFire wrote: > I haven't seen Sean post about this yet, so figured I would. About 4am this morning I thought about posting something, but thought the power companies would mysteriously find some extra power at the last minute again. > California's been getting hit with a nasty storm since yesterday that's > taken out some more major power plants; the CAISO declared a Stage 3 > (rolling blackouts all around) power emergency just before 9 AM PST today. > > See http://www.caiso.com/SystemStatus.html for pretty graphs. No rolling blackouts are currently planned, but 15,000 Megawatts is currently off-line (1/3 of normal capacity). If there are rolling blackouts, most likely would occur between 4pm and 8pm. CAL-ISO declared a "Stage 3" emgergency, but called for a reduction of 0MW (that's a zero) of interruptiable load. So I'm guessing the purpose of declaring the stage 3 was to activate some other programs, such as shutting down the water pumps between northern and southern california again. Something which apparently is only done during a State 3 emergency. Diablo Canyon nuclear power plant is operating at 20% capacity due to high surf conditions. (http://www.nrc.gov/NRR/DAILY/psr.htm) > Have you test-run your backup generators and transfer switches lately? }:> Actually, most modern colo's have better emergency/standby power systems than your typical goverment emergency operations center or hospital. A simple rolling blackout isn't going to cause problems for most ISPs, colos, or carriers. A wise ISP might decide to have a "No Touch" period between 4pm and 8pm, and reschedule any electrical work at another time so you don't create a fault at the same time the utility grid is under stress. But ISP customers won't notice, or even know, if their ISP does this. The NRC and DOE found the best schedule for testing generators and transfer switches isn't necessarily the one everyone uses.

2 1

RE: IPIP-tunnel with 1500 MTU
by Mikael Abrahamsson 11 Jan '01

11 Jan '01

On Thu, 11 Jan 2001, Bulger, Tim wrote: > There is an 'ip mtu' option in the tunnel interface config on Cisco routers > that you can set to 1500.. This will cause the tunnel packets themselves to > be ip fragmented outbound on the router, hence shifting the fragmentation > away from your internal network packets and over to the tunnel packets. I > know that this works with GRE and IP/IP on Cisco routers running 12.x code. (config-if)#tunnel mode gre ip (config-if)#mtu 1500 % Interface Tunnel1 does not support adjustable maximum datagram size I believe this is only true if you have serial links that support MTU > 1500 all the way between the two routers doing the tunneling, right? -- Mikael Abrahamsson email: swmike(a)swm.pp.se

2 1

RE: MPLS deployment
by Irwin Lazar 11 Jan '01

11 Jan '01

Bala, Many of the larger service providers have already rolled out MPLS in their networks to perform IP Traffic Engineering. A very short list includes UUNET (in Europe), Global Crossing, and British Telecom. The secondary usage for MPLS is to establish network-based virtual private network services in which MPLS is used to create tunnels (or closed user groups) across IP networks. AT&T is already offering a service based on this approach (IP Enabled Frame Relay). Other service providers are looking at rolling out MPLS-based VPN services in the next year. In terms of multi-vendor MPLS deployments, most of the early deployments have been in Cisco/Juniper environments. As such, RSVP-TE is the protocol of choice for MPLS Traffic Engineering and label switch path creation. For additional information, please feel free to visit my web site, the MPLS Resource Center at www.mplsrc.com. There is a very active discussion list on MPLS operational issues that you might want to join. We also have an MPLS FAQ that addresses many of your questions. irwin -----Original Message----- From: Bala Rajagopalan [mailto:BRaja@tellium.com] Sent: Thursday, January 11, 2001 5:12 PM To: 'nanog(a)merit.edu' Subject: MPLS deployment Hello, I am trying to get some information on the extent to which MPLS has been deployed in ISP networks. Specifically, - what's the largest MPLS deployment (in terms of size of the network)? - what's the largest multi-vendor MPLS deployment? - what's the status of MPLS-based TE? is it being used now? Thanks in advance. Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja(a)tellium.com

1 0

Re: IPIP-tunnel with 1500 MTU
by Mikael Abrahamsson 11 Jan '01

11 Jan '01

On Thu, 11 Jan 2001, Brian Moore wrote: > Who is setting the DF flag and why? If an end host is doing it, All windows machines do this by default. > check to see if P-MTUd is set on the end host and turn it off. > Several OSs try to do this by default (Solaris, HP-UX, etc). > >From my past experience with P-MTUd (dates back a few years), > almost no vendor understood how to implement it. http://www.cisco.com/warp/public/105/56.html Even cisco recognises the problem and offer no solution :/ -- Mikael Abrahamsson email: swmike(a)swm.pp.se

1 0

IPIP-tunnel with 1500 MTU
by Mikael Abrahamsson 11 Jan '01

11 Jan '01

I would like to tunnel IP packets over an IP network, and this IP network has 1500 MTU (regular ethernet MTU). In the cisco tunnel (and most others) the tunnel MTU ends up being 1450-something bytes. This is not acceptable, I need something that is able to split the packet up into two packets so that the tunnel MTU will be 1500. Does anyone know of a product that does this? I do not want any kind of unix/pc solution, everything that consists of PC hardware or has a harddrive is by default ruled out. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

3 3

MRTG and BB for sensorArray?
by Mike Jackson 11 Jan '01

11 Jan '01

Hi, I am new to the list, but I did search the list archives and found nothing. Has anybody here configured mrtg and/or bb to work with the sensorArray device? My end goal is to have bb poll the device and send me a text message if the temperature goes over a certain limit. Thanks, Mike

1 0

should use firewall when peering?
by bgp4cn 11 Jan '01

11 Jan '01

Hi,everyone, yesterday our parner tell me that almost all carriers in North America implementing firewalls when they interlink with another carriers. I do not think so.But he came from one of US's carriers,and who insist on that opinion and suggest our new-building carrier network to use firewalls between Chinanet and Internet. who came from Sprint/MCI/UUNET or other ISP's,can you tell me what really the things? And our parner also said we can use private IP on our carrier's networks,who said that we use NAT on the internet access router(runing BGP,and have our own public AS),I think NAT is too low performance to use at the inter-ISP link router,and have problems of multi-ISPs interlink's torlance,and have problems with some applications which go to another ISP,do you think so? Bye the way, I came from China,any suggestion will be appreciated. Regards, miao laisheng miaols(a)bridge.net.cn ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ÄãÑ¡ÊÖ»úÎÒÂòµ¥£¡(http://mall.sina.com.cn/yesmobile/)

2 1

Re: should use firewall when peering?
by Sean Donelan 11 Jan '01

11 Jan '01

On Thu, 11 January 2001, bgp4cn wrote: > yesterday our parner tell me that almost all carriers in North America > implementing firewalls when they interlink with another carriers. I do not know of a single major US carrier which inserts a "firewall" in its inter-carrier connections. Generally "firewalls" are used between the Internet and "terminal" networks, not between transit carriers. For historical reasons, traffic between most US commercial transit providers occurs on an "AUP-free" basis. However, the word "firewall" is one of those marketing terms which has variable meanings depending on the speaker and on the customer. Most carriers do have certain technical filters (i.e. a list of valid or invalid IP addressese) they apply to their inter-carrier peering links. For example, they won't accept a route with an address of 0.0.0.0 (i.e. default route) between backbones. Because a firewall by its nature imposes policy on all downstream connections, any carrier wanting to be a major international transit provider would not use a firewall on its peering links. Different countries have very different ideas what is or is not acceptable, international transit providers don't make that decision at the backbone level. Likewise they don't make that decision at the connections between major international transit providers. Even Singapore, which has fairly strict domestic controls, has an AUP-free policy for traffic between carriers at its international exchange point.

1 0

Re: should use firewall when peering?
by Sean Donelan 11 Jan '01

11 Jan '01

On Thu, 11 January 2001, bgp4cn wrote: > yesterday our parner tell me that almost all carriers in North America > implementing firewalls when they interlink with another carriers. I do not know of a single major US carrier which inserts a "firewall" in its inter-carrier connections. Generally "firewalls" are used between the Internet and "terminal" networks, not between transit carriers. For historical reasons, traffic between most US commercial transit providers occurs on an "AUP-free" basis. However, the word "firewall" is one of those marketing terms which has variable meanings depending on the speaker and on the customer. Most carriers do have certain technical filters (i.e. a list of valid or invalid IP addressese) they apply to their inter-carrier peering links. For example, they won't accept a route with an address of 0.0.0.0 (i.e. default route) between backbones. Because a firewall by its nature imposes policy on all downstream connections, any carrier wanting to be a major international transit provider would not use a firewall on its peering links. Different countries have very different ideas what is or is not acceptable, international transit providers don't make that decision at the backbone level. Likewise they don't make that decision at the connections between major international transit providers. Even Singapore, which has fairly strict domestic controls, has an AUP-free policy for traffic between carriers at its international exchange point.

1 0

Re: UUNET peering policy
by Sean Donelan 11 Jan '01

11 Jan '01

On Mon, 08 January 2001, Deepak Jain wrote: > This makes it very clear for those networks that want to consolidate their > operations and reduce their overall transit costs. For example: a > midsized access and a midsized web host could easily meet these > requirements for AS701 peering; depending on your definition of a midsized > host. You'll find that meeting the peering "requirements" and actually obtaining a peering agreement are two different things. Sprint had several sets of peering requirements, nevertheless it didn't prevent them from not setting up a single new peering agreement with a variety of networks which met those requirements for over three years if you believe Sprint's product manager.

6 5