- Test - lists.nanog.org

Re: New MAE-EAST
by Richard Irving 10 Dec '97

10 Dec '97

Noemi Berry wrote: > > > Our nets *Scream*. > > > > Another question, in response to another email you'd sent to NANOG > and I subsequently deleted: :( > > You mentioned that your ATM switch at MAE-EAST supports CBR, VBR-RT, > VBR-NRT and UBR. What ATM-connection type do you use to connect peers? > Well at MAE-E , FDDI ;) (We have a pending deal to move some exchange neighbors to direct ATM OC-3/DS3, to route around the MAE) However, passing back into the our national fabric, we tend to run VBR-NRT, with a few UBR's, and a few RT-VBR tunnels. > Actually, I'm probably misunderstanding what you use your ATM switch > for. What is its function at the NAP, anyway? It becomes an Exchange Fabric in and of itself. See Ameritech VNAP, and OneCall's IndyX offerings. > > very curious, > noemi > -- > Noemi Berry > Network Operations > Covad Communications

1 0

Re: New MAE-EAST
by Richard Irving 10 Dec '97

10 Dec '97

Noemi Berry wrote: > > > > > I'd certainly be interested in seeing anything > >> > anyone has on fragmentation related delays going from a large MTU > switched > >> > environment to a small MTU switched environment though. Overall, I've > >> > been less-than-pleased with latency when I've been transited that way. > >> > > > > > Uh... Doctor , it hurts when I do this. > >Doctor: So don't do that! > > > > Hint, it is *pretty* foolish to run mixed MTU's on switched fabric. > > *Most* people on ATM exchanges run with common MTU's. > > Getting to my NANOG mail kinda late here.... I will say. *grin* > > But WHAT are you guys talking about WRT to MTUs through an ATM switch? > The MTUs almost always refer to the layer 3 and up MTUs, which the ATM > switches themselves have no visibility to. We are discussing Router ATM cards. (Layer 2/3).... > It's righter to say that > most people on *any* exchange run with common MTUs. Don't I wish. > > If you're going from a "large MTU switched environment" to a "small MTU > switched environment", then you must be passing through a router or some > other device that understands and sets its own MTU. The ATM layer has > nothing to do with that. MTU issues are independent of what layer 2 > technology is used to connect the peers. The point ? You would have a hard time setting an MTU of 4470 on ethernet... The object of the game ? If you must fragment, do it *after* transmission. (If possible) (Less WAN bandwidth than otherwise) > > I know a thing or two about ATM, but not NAPs, so please correct me if my > terminology is screwy and I missed something. > Try reading RFC-1626. We are talking about MTU for the IP PLCP card into the ATM fabric. FDDI to ATM to Ethernet, try it , you won't like it. PS Don't forget ATM is not the only switched fabric in town.... You will find there is a whole PDU and SDU maxsize declaration for SAR to use on AAL5 based framing. However, these are *not* the limits you want to be using..... I know non-mixed MTU's seem obvious, but some don't get it. On the other hand, I have neighbors who have the CHI-NAP fabric declared as /24, and *cannot* be made to understand why this is bad. ;) (One Quote: Its the internet, I can do as I want! ) Sigh........ Cheers ! > thanks, > noemi > -- > Noemi Berry > Network Operations > Covad Communications > > p.s. (all that said, it's not *entirely* true that the ATM layer has no > visibility to the higher-layer MTUs: early- and partial- packet discard peeks > into the ATM cells to see the start and end of AAL5 frames that encapsulate > layer 3 packets, but it does no fragmentation nor otherwise manipulate the > layer 3 packet).

1 0

PPP Question
by George Janosik 10 Dec '97

10 Dec '97

A quick protocol question. Is a PPP frame size static or elastic? RFC 1661 states: Information Field The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the Protocol field. The maximum length for the Information field, including Padding, but not including the Protocol field, is termed the Maximum Receive Unit (MRU), which defaults to 1500 octets. By negotiation, consenting PPP implementations may use other values for the MRU. Padding On transmission, the Information field MAY be padded with an arbitrary number of octets up to the MRU. It is the responsibility of each protocol to distinguish padding octets from real information. This is somewhat ambiguous. If I read it straight it sounds like PPP frames are static and that padding is used to maintain the MRU between endpoints. But, it also says the the Information field "MAY" be padded up to the MRU. I have hard time believing that a PPP frame would be static. Very truly yours, George J Janosik Senior Systems Engineer Torrent Networking Technologies gjanosik(a)torrentnet.com 412-851-1103

1 0

PPP Question
by George Janosik 10 Dec '97

10 Dec '97

A quick protocol question. Is a PPP frame size static or elastic? RFC 1661 states: Information Field The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the Protocol field. The maximum length for the Information field, including Padding, but not including the Protocol field, is termed the Maximum Receive Unit (MRU), which defaults to 1500 octets. By negotiation, consenting PPP implementations may use other values for the MRU. Padding On transmission, the Information field MAY be padded with an arbitrary number of octets up to the MRU. It is the responsibility of each protocol to distinguish padding octets from real information. This is somewhat ambiguous. If I read it straight it sounds like PPP frames are static and that padding is used to maintain the MRU between endpoints. But, it also says the the Information field "MAY" be padded up to the MRU. I have hard time believing that a PPP frame would be static. Very truly yours, George J Janosik Senior Systems Engineer Torrent Networking Technologies gjanosik(a)torrentnet.com 412-851-1103

1 0

UUNET POP Down
by Dan Hubbard 10 Dec '97

10 Dec '97

NOC says the problems are still there but we can route through there LA POP now so it must be a routing issue on there end. >UUNET has a "router hardware" problem in there LA POP. Has been down since around 10:35AM PST. They currently are working on it from the NOC --> ticket # UU570970. > > > --------------- Dan Hubbard The Palace Inc.

1 0

ARIN will begin operations 12/22/97
by Kim Hubbard 10 Dec '97

10 Dec '97

The American Registry for Internet Numbers (ARIN) will initiate operations December 22, 1997, to provide Internet Protocol (IP) number administration and registration services for North America, South America, the Caribbean and sub-Saharan Africa. On this date, the Internet Assigned Numbers Authority (IANA) will transfer the authority for IP number administration from Network Solutions, Inc., administrator of the InterNIC, to ARIN. All IP requests received by the InterNIC, that are not processed prior to the close of business on Friday, December 19, will be forwarded from the InterNIC to ARIN. The InterNIC will make every attempt to complete all requests received by this date. As prepayment is a requirement for ARIN registration services, we encourage ISPs that have previously received address space directly from the InterNIC to pre-establish a customer account with ARIN. The account establishment process will open on December 10, 1997, and is limited to those ISPs that have previously received IP addresses directly from the InterNIC. This prerequisite is due to the fact that ARIN registration fees are based on the previous year's total allocation. All other organizations should establish customer accounts after they have been approved for address space from ARIN. To establish a customer account, use the Customer Account Procedures and Form or for more information about ARIN, please visit the ARIN website located at www.arin.net.

1 0

UUNET POP Down
by Dan Hubbard 10 Dec '97

10 Dec '97

UUNET has a "router hardware" problem in there LA POP. Has been down since around 10:35AM PST. They currently are working on it from the NOC --> ticket # UU570970. --------------- Dan Hubbard The Palace Inc.

1 0

Re: smurf
by Paul Ferguson 10 Dec '97

10 Dec '97

This is also mentioned in the *-03.txt version of the ingress filtering draft: ftp://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-03.t… - paul At 03:13 PM 12/8/97 -0800, Craig A. Huegen wrote: > >It's a requirement per the RFC: > >(from my smurf paper) > >RFC 1812, >"Requirements for IP Version 4 Routers", Section 5.3.5, specifies: > >--- > A router MAY have an option to disable receiving network-prefix- > directed broadcasts on an interface and MUST have an option to > disable forwarding network-prefix-directed broadcasts. These options > MUST default to permit receiving and forwarding network-prefix- > directed broadcasts. >--- >

1 0

I'm looking for an event-driven DNS resolver (public-domain source)
by George Powers 10 Dec '97

10 Dec '97

I'm looking for some code to crib that'll give me an event-driven (non-blocking) DNS resolver, preferably one that caches. I've looked at the BSD bind resolver, but it is is process-based, and blocks while waiting for a reply.

3 2

charge for bgp feeds?
by Hui-Hui Hu 10 Dec '97

10 Dec '97

quick, probably off-subject question--but, do you know any backbone provider that charges to set up a bgp feed? private replies appreciated so as not to pollute the list. I always thought they were gratis but apparently I may not be up with the times. -h

1 0