- NANOG - lists.nanog.org

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

IP whois info
by Hank Nussbacher 11 Jan '01

11 Jan '01

When processing cflowd and wanting to resolve IP nets as well as ASNs as quickly as possible is there a trick to do the lookups rather than trying RIPE, ARIN, APNIC (and perhaps others) in a cyclical manner? Is there some static file that one can download that lists just the IP nets and ASN and who it belongs to (for all databases - not just ARIN)? Thanks, Hank

5 5

Re: UUNET peering policy
by smd＠clock.org 11 Jan '01

11 Jan '01

Rodney Joffe is being optimistic; the fact is that a network that exceeds the minimum requirements UUNET has published yet which has zero customers, is simply not going to get a no-settlement peering agreement with UUNET. "Zero" here is a relative term. Sean. | >If I understand the document correctly, anyone who meets their clear | >requirements will be able to exchange traffic with them at no charge. [...] | >Rodney Joffe | >CenterGate Research Group, LLC.

5 4

Re: DNS requests from 209.67.50.203
by Vern Paxson 11 Jan '01

11 Jan '01

> A good way to reduce this is to turn off recursion for > people not on your network for your dns server. This is fairly easy > to do with bind8/bind9. The attack isn't via recursive lookups (though recursion could help augment the attack). The reflection is in terms of the DNS reply to the purported requestor (really the victim). At lbl.gov, none of the requests result in further lookups from our nameserver. But the victim still receives the reply stream, which from a combined large number of name servers is very large. See my draft paper ftp://ftp.ee.lbl.gov/.vp-reflectors.txt for a discussion of reflector attacks. Vern

2 1

Re: net.terrorism
by Paul A Vixie 11 Jan '01

11 Jan '01

> After this mail, we contacted Above.net again. They basically told us it > was for our own protection no. > because that traffic from that host does not > comply to their AUP. yes. > We specifically told them we really don't mind them > blackholing that host but *announcing* a route for it. So far no response. you expect abovenet to cut uunet's /16 into pieces so as to avoid sending to its customers the parts which violate abovenet's acceptable use guidelines? even if this were a scalable approach (considering the number of /16's which have violating /32's inside them, or will in the future), it's something i'd expect the owner of the /16 to take issue with. why are we discussing this on nanog? Paul Vixie <pvixie(a)mmfn.com> CTO and SVP, MFN (NASDAQ: MFNX)

10 10

Exchange point peering
by Robbie Harrell 10 Jan '01

10 Jan '01

I have some questions regarding an IX point. If I go to PacBell and sign the multilateral peering agreement it anyone and everyone can peer with me and I can peer with everyone else. Now if I buy a DS3 UBR port then my cells/packets have to contend with everyone else who is trying to egress out to an upstream provider. If there is contention then my cells can be dropped and my packets are unable to be reconstructed by the router. Does anyone know how this works at the Chicago NAP? Is my PCR for my ATM port set at line speed for DS3 OC3 and OC12. How do they prevent random cell discard at the egress port to upstream providers, is there a graceful discard so that cells are dropped to maximize good "packets". How does Pacbell ensure that there is a level of fairness for packet traffic. I understand that it will be UBR, but if Pacbell is sending only cells to upstream that randomly make it through the egress queues, there is really no way to ensure that ANY packets can get through. All the cells could be partial packet info. Any insight into this would be helpful so that I do not purchase a service that is worthless.

2 1