UUNET issues?

Speaking on Deep Background, the Press Secretary whispered:

>
>>>> "Could you be any less descriptive of the problem you are seeing?"
>>> the internet is broken. anyone know why?
>> Did you ping it?
>
> is that what broke it?

I'm sure it just needs to be rebooted.

Is this the day we disconnect everything and blow all the dirt out?

David Lesher wrote:

Speaking on Deep Background, the Press Secretary whispered:

"Could you be any less descriptive of the problem you are seeing?"

the internet is broken. anyone know why?

Did you ping it?

is that what broke it?

I'm sure it just needs to be rebooted.

Is this the day we disconnect everything and blow all the dirt out?

You only *think* you are joking. I still remember the Day of the Great Restart when everyone on the ARPAnet had to shut down the IMPs and TIPs, and reload the control software. Why? There were literally thousands of rogue packets flying around the net, eating up bandwidth (and in those days, we are talking 56 kbps links!) and boy were those tubie-thingies plugged up!

Shortly after that cusp event, per-packet TTL field was added to the NTP protocol, which is why TCP/IP has the TTL field in the IP packet.

The network had added to it a self-cleaning function. Think of it as one long continuous sneeze.

David Lesher wrote:
> Speaking on Deep Background, the Press Secretary whispered:
>>>>>> "Could you be any less descriptive of the problem you are seeing?"
>>>>> the internet is broken. anyone know why?
>>>> Did you ping it?
>>> is that what broke it?
>> I'm sure it just needs to be rebooted.
> Is this the day we disconnect everything and blow all the dirt out?

You only *think* you are joking. I still remember the Day of the Great
Restart when everyone on the ARPAnet had to shut down the IMPs and TIPs,
and reload the control software. Why? There were literally thousands
of rogue packets flying around the net, eating up bandwidth (and in
those days, we are talking 56 kbps links!) and boy were those
tubie-thingies plugged up!

Shortly after that cusp event, per-packet TTL field was added to the NTP
protocol, which is why TCP/IP has the TTL field in the IP packet.

I assume you mean NCP rather than NTP.

Anyway, I don't think that would have helped if you're talking about the
same incident I'm thinking of. There were application-level
retransmissions of (corrupted) packets, complete with building new bad
packets from bad data structures, all over the net

The problem is documented in RFC 789 It and "The Bug Heard 'Round the
World" are two of my favorite "how complex systems fail" papers; all
system designers should read, memorize, and undertand both.

The network had added to it a self-cleaning function. Think of it as
one long continuous sneeze.

    --Steven M. Bellovin, Steven M. Bellovin

Anyway, I don't think that would have helped if you're talking about the
same incident I'm thinking of. There were application-level
retransmissions of (corrupted) packets, complete with building new bad
packets from bad data structures, all over the net

The problem is documented in RFC 789 It and "The Bug Heard 'Round the
World" are two of my favorite "how complex systems fail" papers; all
system designers should read, memorize, and undertand both.

I actually asked Stephen if he was referring to the LSA corruption problem and he said he was referring to an earlier issue (circa 1972).

As for the LSA issue- rebooting would have fixed the problem, assuming it was done by all nodes at the same time. All of the Link State tables would have been rebuilt from scratch by the IMPs and the corrupt announcements would have been gone.

As I recall the IMP software was actually patched to ignore the problematic announcements from IMP 51.

-Don

As for the LSA issue- rebooting would have fixed the problem, assuming it was done by all nodes at the same time. All of the Link State tables would have been rebuilt from scratch by the IMPs and the corrupt announcements would have been gone.

Turns out this is actually mentioned on page 14 of RFC 789.

As I recall the IMP software was actually patched to ignore the problematic announcements from IMP 51.

Not that it matters- but it was IMP 50 not 51.

-Don

I've got a client looking to upgrade their edge routers and they want to consider all of their options.

Right now we're looking at Cisco, Juniper and Foundry. I'd like to hear what other people have to say about the vendors, their offerings and their support. Do their products have particular strengths or weaknesses? Also, if anyone has another vendor we should be considering- we are open to suggestions.

In this case the router requirements are small- 5 GigE interfaces, BGP, OSPF, VRRP and the ability to handle as many PPS as possible so as to avoid a router DoS in the event of an attack (10 Mpps minimum).

I have my own opinions about each vendor but I'd like another perspective this time around.

Thanks in advance,
-Don