Re: Questions about populating RIR with customer information.
On 8/1/07, Drew Weaver [EMAIL PROTECTED] wrote: Most of our customers are co-location and dedicated hosting customers and we are simply unsure whether or not there are implications (legal or otherwise) in publishing our customer data in a public RIR database. I would urge against publishing information about a customer in a WHOIS entry without discussing it with that customer first. WHOIS entries can be made without violating anyone's privacy, just be sure you get all necessary verifiable permission; don't just automatically publish information you have already gathered for internal purposes, when it wasn't previously your policy to publish the information. It is up to you as ISP to get the contact information that the customer wants published in WHOIS (maybe it's different from contact information they would use for other matters), at the time re-assignment of the ip addresses is being made, And make sure they know that the listing is going to be publicly viewable. You do have the option of refusing to sign up or renew a customer if they fail to provide good contact information for publication in WHOIS or fail to provide the necessary permission. I suggest you carefully read the policy manual of your applicable RIR. With regard to when you create SWIP or RWHOIS records, and what exactly you put in them. In the ARIN region, whenever an ISP re-assigns a /29 block or larger to a customer, in addition to maintaining documentation of the justification for assignment of the address(es) to the user, the ISP is already be required/supposed to publish that re-assignment is (as a matter of RIR policy) in SWIP or RWHOIS. See more here: http://www.arin.net/policy/nrpm.html#four2372 And it's a good idea to allow people who need a contact for abuse from a machine to go to the party responsibility over it, first, before having to bother you, a provider they happen to be using. Note that ARIN has a Residential Customer Privacy policy; for residential customers it is legitimate to substitute the name in your WHOIS response with Private Customer and Private Residence in place of street address. So I would say there IS some precedant for such a replacement of contact information. You need to check your particular RIR's policy manual to determine whether it is an acceptable practice in your region, to mask contact information for the particular type of customer. -- -J
Redistribute routes from EIGRP into BGP VRF
Hello all, Currently working on a solution at the moment where I receive specific /25 routes via a leased line into the global routing table via EIGRP on a Cisco 2801. I then need to inject these routes into a BGP VRF to be advertised onto BGP Peers within the VRF Network. The /24 routes for the Site LAN are injected via Radius on the DSL Routers so this task makes the /25 more favourable via the Leased Line Router. == IOS Version on 2801 (Router B) = Version 12.4(12a) BGP VRF Config: router bgp 65xxx no synchronization no bgp log-neighbor-changes bgp scan-time 10 no auto-summary ! address-family ipv4 vrf test1 redistribute connected redistribute static redistribute eigrp ... == Simple Diagram attached Routers C D do not see the redistributed routes from Router B via BGP. Not sure if this is an IOS Bug, but this should work?? Thanks Stephen Bailey
RE: Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast Onvoy
I've forwarded your message to the appropriate team within Comcast. - Alain. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig D. Rice Sent: Thursday, August 02, 2007 9:30 AM To: nanog@merit.edu Subject: Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast Onvoy For four months dozens of our users who are Comcast subscribers have had difficulty reaching St. Olaf College's and Carleton College's network services. We have worked through everything we can think of with our Onvoy (regional ISP) network engineers. We have isolated the problem a couple of Comcast's IP subnets, but need a contact within Comcast to further troubleshoot. The behavior in a nutshell: -- User A on Comcast Subnet B browses to www.stolaf.edu (http or https, other web sites on-site and @carleton.edu behave the same). Our access_log shows an initial GET / of our homepage, then very slow (if any) subsequent requests (for our stylesheet or homepage images). Ping's look fine; traceroute's look as reasonable. Telnet's to port 80 and other services do seem to respond, albeit very slowly. User A has the same problem with access @carleton.edu but can access everything else (including other Onvoy customers) without any trouble whatsoever. If User A then removes his Linksys router and connects his computer directly to the cable modem, he acquires an IP address in Comcast Subnet C. Then, everything works fine, including access to www.stolaf.edu and www.carleton.edu. He puts the Linksys router back in (which still has the IP address in Comcast Subnet B), and the problem returns. The problem IP subnets are completely consistent. Known WORKING IP Subnets: 75.72.0.0, 24.x Known NON-WORKING IP Subnets: 71.x, 73.x -- We have already attempted the usual troubleshooting and have eliminated user problems, computer problems, server problems, cable modem problems, and Linksys router problems. Traceroutes have been somewhat inconclusive since Onvoy blocks ICMP within its network. So, why just St. Olaf and Carleton services? We are on a shared physical link from Onvoy, though on different VLANs. Onvoy has verified everything they can (routing, packet loss, etc.) between them and us, and I'm not sure what additional questions I can ask of them to test. Suggestions? Maybe Comcast has a broken transparent proxy on part(s) of their network? But they have told us they have nothing like this anywhere on their network. Maybe there is some asymmetric routing somewhere, though all the investigation there has come up empty. A third possibility is some kind of packet loss, but there is little if any evidence of that. So, we are really at a loss and seek any suggestions you all might have. And a contact in Comcast network engineering would be especially useful to continue our troubleshooting. With thanks, Craig -- Craig D. Rice Associate Director of Information Systems [EMAIL PROTECTED]Information and Instructional Technologies +1 507 786-3631 St. Olaf College +1 507 786-3096 FAX 1510 St. Olaf Avenue http://www.stolaf.edu/people/cdr Northfield, MN 55057-1097 USA
Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast Onvoy
For four months dozens of our users who are Comcast subscribers have had difficulty reaching St. Olaf College's and Carleton College's network services. We have worked through everything we can think of with our Onvoy (regional ISP) network engineers. We have isolated the problem a couple of Comcast's IP subnets, but need a contact within Comcast to further troubleshoot. The behavior in a nutshell: -- User A on Comcast Subnet B browses to www.stolaf.edu (http or https, other web sites on-site and @carleton.edu behave the same). Our access_log shows an initial GET / of our homepage, then very slow (if any) subsequent requests (for our stylesheet or homepage images). Ping's look fine; traceroute's look as reasonable. Telnet's to port 80 and other services do seem to respond, albeit very slowly. User A has the same problem with access @carleton.edu but can access everything else (including other Onvoy customers) without any trouble whatsoever. If User A then removes his Linksys router and connects his computer directly to the cable modem, he acquires an IP address in Comcast Subnet C. Then, everything works fine, including access to www.stolaf.edu and www.carleton.edu. He puts the Linksys router back in (which still has the IP address in Comcast Subnet B), and the problem returns. The problem IP subnets are completely consistent. Known WORKING IP Subnets: 75.72.0.0, 24.x Known NON-WORKING IP Subnets: 71.x, 73.x -- We have already attempted the usual troubleshooting and have eliminated user problems, computer problems, server problems, cable modem problems, and Linksys router problems. Traceroutes have been somewhat inconclusive since Onvoy blocks ICMP within its network. So, why just St. Olaf and Carleton services? We are on a shared physical link from Onvoy, though on different VLANs. Onvoy has verified everything they can (routing, packet loss, etc.) between them and us, and I'm not sure what additional questions I can ask of them to test. Suggestions? Maybe Comcast has a broken transparent proxy on part(s) of their network? But they have told us they have nothing like this anywhere on their network. Maybe there is some asymmetric routing somewhere, though all the investigation there has come up empty. A third possibility is some kind of packet loss, but there is little if any evidence of that. So, we are really at a loss and seek any suggestions you all might have. And a contact in Comcast network engineering would be especially useful to continue our troubleshooting. With thanks, Craig -- Craig D. Rice Associate Director of Information Systems [EMAIL PROTECTED]Information and Instructional Technologies +1 507 786-3631 St. Olaf College +1 507 786-3096 FAX 1510 St. Olaf Avenue http://www.stolaf.edu/people/cdr Northfield, MN 55057-1097 USA
Re: Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast Onvoy
On 8/2/07, Craig D. Rice [EMAIL PROTECTED] wrote: We have already attempted the usual troubleshooting and have eliminated user problems, computer problems, server problems, cable modem problems, and Linksys router problems. Traceroutes have been somewhat inconclusive since Onvoy blocks ICMP within its network. Craig, This rings a bell. Do they block the mandatory ICMP fragmentation-needed messages? Try this: on your web server, reduce the MTU from 1500 bytes to 1400 bytes and see if the affected comcast users can now access your web server. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast Onvoy
At 09:30 AM 8/2/2007, Craig D. Rice wrote: For four months dozens of our users who are Comcast subscribers have had difficulty reaching St. Olaf College's and Carleton College's network services. We have worked through everything we can think of with our Onvoy (regional ISP) network engineers. We have isolated the problem a couple of Comcast's IP subnets, but need a contact within Comcast to further troubleshoot. (snip) Either your firewall/router or the customer's firewall/router is blocking PMTUD packets. Fragment needed, but don't fragment bit set. Look at your ICMP access list and make sure you are allowing: permit icmp any any unreachable from any Internet address. I suspect an overzealous firewall admin is blocking all icmp. Read the acronym to him/her and explain that some icmp is necesary for the Internet to work. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 Well done is better than well said. - Benjamin Franklin
BotHunter
All, SRI and Georgia Tech have been working on a pretty cool new tool that will quickly locate bot traffic inside a network. A government/military version of this software has been in use successfully for about a month, and a public version was made available this week. BotHunter introduces a new kind of passive network perimeter monitoring scheme, designed to recognize the intrusion and coordination dialog that occurs during a successful malware infection. It employs a novel dialog-based correlation engine (patent pending), which recognizes the communication patterns of malware-infected computers within your network perimeter. BotHunter is available for download at http://www.cyber-ta.org/BotHunter/ and runs under Linux Fedora, SuSE, and Debian distributions. There is also a highly interactive honeynet using BotHunter run by SRI you should look at. The URL is http://www.cyber-ta.org/releases/malware-analysis/public/. We are detecting dozens of new infections each day and this site is very helpful in understanding the behavior of the received malware. Also, it generates a nice list of potentially evil IP addresses and DNS queries. For both the BotHunter software and the honeynet we'd appreciate any feedback on ways to improve them. Contact details are in the download package and on the website. Marc -- Marcus H. Sachs, P.E. [EMAIL PROTECTED] SRI International 1100 Wilson Blvd Suite 2800, Arlington VA 22209 USA tel +1 703 247 8717 fax +1 703 247 8569 mob +1 703 932 3984
40Gbit private peer
SUnet (AS1653) and STUPI (AS1880) want to announce that we have brought up what we believe is the first private peer at 40G between two independent networks. It speaks IPv4, IPv6 both unicast and multicast. -Peter RP/0/RP0/CPU0:HFR1-F#sh int pos 0/3/0/0 POS0/3/0/0 is up, line protocol is up Interface state transitions: 2 Hardware is Packet over SONET/SDH Description: OC768 Private Peering to Sunet [EMAIL PROTECTED] Internet address is 193.11.20.146/30 MTU 4474 bytes, BW 39813120 Kbit reliability 255/255, txload 0/255, rxload 0/255 Encapsulation HDLC, crc 32, controller loopback not set, keepalive set (10 sec) Last clearing of show interface counters 1d00h 30 second input rate 77849000 bits/sec, 7236 packets/sec 30 second output rate 17464000 bits/sec, 5023 packets/sec 115627177 packets input, 155140727534 bytes, 0 total input drops 0 drops for unrecognized upper-level protocol Received 0 runts, 0 giants, 0 throttles, 0 parity 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 78946374 packets output, 34499886901 bytes, 0 total output drops 0 output errors, 0 underruns, 0 applique, 0 resets 0 output buffer failures, 0 output buffers swapped out RP/0/RP0/CPU0:HFR1-F#sh controllers soNET 0/3/0/0 Port SONET0/3/0/0: Status: Up Loopback: None SECTION LOF = 0 LOS= 0BIP(B1) = 0 LINE AIS = 0 RDI= 0 FEBE = 0 BIP(B2) = 0 PATH AIS = 0 RDI= 0 FEBE = 0 BIP(B3) = 0 LOP = 0 NEWPTR = 0 PSE = 0 NSE = 0 PLM = 0 TIM= 0 Detected Alarms: None Asserted Alarms: None Mask for Detected-Asserted: None Detected Alerts: None Reported Alerts: None Mask for Detected-Reported: None Alarm reporting enabled for: SLOS SLOF SF_BER PLOP Alert reporting enabled for: B1-TCA B2-TCA B3-TCA Framing: SONET SPE Scrambling: Enabled C2 State: Stable C2_rx = 0x16 (22) C2_tx = 0x16 (22) / Scrambling Derived S1S0(tx): 0x0 S1S0(rx): 0x0 / Framing Derived PATH TRACE BUFFER : STABLE Remote hostname : c1sth-re1 so-7/0/0 Remote interface: Remote IP addr : APS No APS Group Configured Protect Channel 0 DISABLED Rx(K1/K2) : 0x00/0x00 Tx(K1/K2) : 0x00/0x00 Remote Rx(K1/K2): 1/Remote Tx(K1/K2): 1/ BER thresholds: SF = 10e-3 SD = 10e-6 TCA thresholds: B1 = 10e-6 B2 = 10e-6 B3 = 10e-6 Optics type: VSR2000-3R2 (2km) Clock source: internal (actual) internal (configured) Optical Power Monitoring (accuracy: +/- 1dB) Rx power = 1.3796 mW, 1.4 dBm Tx power = 1.7380 mW, 2.4 dBm Tx laser current bias = 58.3 mA
Re: 40Gbit private peer
Hi Peter, Whilst I think there are some merits to for example the 40G to your mother's place via a new technology I'm not entirely sure what this represents. We know 40G interfaces exist and that any pair of interfaces will come up at 40G. Indeed you could have bonded 16x10G and claimed 160Gb peering. But with nothing behind them, you may as well add IPv8 and IPv9 and ipx as firsts too. :) Steve On Thu, Aug 02, 2007 at 06:44:32PM +0200, Peter Lothberg wrote: SUnet (AS1653) and STUPI (AS1880) want to announce that we have brought up what we believe is the first private peer at 40G between two independent networks. It speaks IPv4, IPv6 both unicast and multicast. -Peter RP/0/RP0/CPU0:HFR1-F#sh int pos 0/3/0/0 POS0/3/0/0 is up, line protocol is up Interface state transitions: 2 Hardware is Packet over SONET/SDH Description: OC768 Private Peering to Sunet [EMAIL PROTECTED] Internet address is 193.11.20.146/30 MTU 4474 bytes, BW 39813120 Kbit reliability 255/255, txload 0/255, rxload 0/255 Encapsulation HDLC, crc 32, controller loopback not set, keepalive set (10 sec) Last clearing of show interface counters 1d00h 30 second input rate 77849000 bits/sec, 7236 packets/sec 30 second output rate 17464000 bits/sec, 5023 packets/sec 115627177 packets input, 155140727534 bytes, 0 total input drops 0 drops for unrecognized upper-level protocol Received 0 runts, 0 giants, 0 throttles, 0 parity 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 78946374 packets output, 34499886901 bytes, 0 total output drops 0 output errors, 0 underruns, 0 applique, 0 resets 0 output buffer failures, 0 output buffers swapped out RP/0/RP0/CPU0:HFR1-F#sh controllers soNET 0/3/0/0 Port SONET0/3/0/0: Status: Up Loopback: None SECTION LOF = 0 LOS= 0BIP(B1) = 0 LINE AIS = 0 RDI= 0 FEBE = 0 BIP(B2) = 0 PATH AIS = 0 RDI= 0 FEBE = 0 BIP(B3) = 0 LOP = 0 NEWPTR = 0 PSE = 0 NSE = 0 PLM = 0 TIM= 0 Detected Alarms: None Asserted Alarms: None Mask for Detected-Asserted: None Detected Alerts: None Reported Alerts: None Mask for Detected-Reported: None Alarm reporting enabled for: SLOS SLOF SF_BER PLOP Alert reporting enabled for: B1-TCA B2-TCA B3-TCA Framing: SONET SPE Scrambling: Enabled C2 State: Stable C2_rx = 0x16 (22) C2_tx = 0x16 (22) / Scrambling Derived S1S0(tx): 0x0 S1S0(rx): 0x0 / Framing Derived PATH TRACE BUFFER : STABLE Remote hostname : c1sth-re1 so-7/0/0 Remote interface: Remote IP addr : APS No APS Group Configured Protect Channel 0 DISABLED Rx(K1/K2) : 0x00/0x00 Tx(K1/K2) : 0x00/0x00 Remote Rx(K1/K2): 1/Remote Tx(K1/K2): 1/ BER thresholds: SF = 10e-3 SD = 10e-6 TCA thresholds: B1 = 10e-6 B2 = 10e-6 B3 = 10e-6 Optics type: VSR2000-3R2 (2km) Clock source: internal (actual) internal (configured) Optical Power Monitoring (accuracy: +/- 1dB) Rx power = 1.3796 mW, 1.4 dBm Tx power = 1.7380 mW, 2.4 dBm Tx laser current bias = 58.3 mA
Re: Questions about populating RIR with customer information.
On Aug 1, 2007, at 7:10 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Does anyone have any thoughts on this? Sorry if this is the wrong place to ask. It would be better for you to join an organization like MAAWG http://www.maawg.org/home which is attempting to define best current practices for ISPs. I don't know whether or not they have dealt with this particular issue yet, but it sounds like something that falls under their umbrella. There were recent efforts made within ASRG with respect to black-hole lists. The AS, and not the IP address, indicates the responsible entity. For our service, some lists coalesce CIDRs into larger ranges based upon the presences of spam in a majority of the included IP addresses. This process is algorithmic, and not dependent upon other information. We now also offer a service where this escalation is not used in less aggressive listings. A customer can now change the active list at any time. : ) Reverse listing information may help in determining whether a CIDR is assigned to DUL only when the ISP is not responsive. For the DUL, the AS is authoritative with respect to what gets listed. As long as there is some communication with ISP, there should never be a problem with this list. We are adding a portal to make this process easier to manage. The other side of this issues is that we tend to deal with complaints from the ISP's customers who often feel their IP address should not be placed into this category. In those cases, these customers must be referred back to their provider, as only their provider is authoritative in this matter. Now that Microsoft joined the MAAWG board, security or operational concerns related to Sender-ID/SPF are being muted. While I admit to being biased about possible DDoS exploits, it is also clear MAAWG is somewhat biased about Sender-ID. : ( -Doug
Re: 40Gbit private peer
I hope they have good peering :) Blake Pfankuch wrote: I would be interested to see how a torrent reacts on a line like that :D -Blake -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leigh Porter Sent: Thursday, August 02, 2007 12:36 PM To: Peter Lothberg Cc: [EMAIL PROTECTED] Subject: Re: 40Gbit private peer Hey, BEcause you really need it ;-) 30 second input rate 77849000 bits/sec, 7236 packets/sec 30 second output rate 17464000 bits/sec, 5023 packets/sec Very nice though, it'll be great for all the P2P. -- Leigh Peter Lothberg wrote: SUnet (AS1653) and STUPI (AS1880) want to announce that we have brought up what we believe is the first private peer at 40G between two independent networks. It speaks IPv4, IPv6 both unicast and multicast. -Peter RP/0/RP0/CPU0:HFR1-F#sh int pos 0/3/0/0 POS0/3/0/0 is up, line protocol is up Interface state transitions: 2 Hardware is Packet over SONET/SDH Description: OC768 Private Peering to Sunet [EMAIL PROTECTED] Internet address is 193.11.20.146/30 MTU 4474 bytes, BW 39813120 Kbit reliability 255/255, txload 0/255, rxload 0/255 Encapsulation HDLC, crc 32, controller loopback not set, keepalive set (10 sec) Last clearing of show interface counters 1d00h 30 second input rate 77849000 bits/sec, 7236 packets/sec 30 second output rate 17464000 bits/sec, 5023 packets/sec 115627177 packets input, 155140727534 bytes, 0 total input drops 0 drops for unrecognized upper-level protocol Received 0 runts, 0 giants, 0 throttles, 0 parity 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 78946374 packets output, 34499886901 bytes, 0 total output drops 0 output errors, 0 underruns, 0 applique, 0 resets 0 output buffer failures, 0 output buffers swapped out RP/0/RP0/CPU0:HFR1-F#sh controllers soNET 0/3/0/0 Port SONET0/3/0/0: Status: Up Loopback: None SECTION LOF = 0 LOS= 0BIP(B1) = 0 LINE AIS = 0 RDI= 0 FEBE = 0 BIP(B2) = 0 PATH AIS = 0 RDI= 0 FEBE = 0 BIP(B3) = 0 LOP = 0 NEWPTR = 0 PSE = 0 NSE = 0 PLM = 0 TIM= 0 Detected Alarms: None Asserted Alarms: None Mask for Detected-Asserted: None Detected Alerts: None Reported Alerts: None Mask for Detected-Reported: None Alarm reporting enabled for: SLOS SLOF SF_BER PLOP Alert reporting enabled for: B1-TCA B2-TCA B3-TCA Framing: SONET SPE Scrambling: Enabled C2 State: Stable C2_rx = 0x16 (22) C2_tx = 0x16 (22) / Scrambling Derived S1S0(tx): 0x0 S1S0(rx): 0x0 / Framing Derived PATH TRACE BUFFER : STABLE Remote hostname : c1sth-re1 so-7/0/0 Remote interface: Remote IP addr : APS No APS Group Configured Protect Channel 0 DISABLED Rx(K1/K2) : 0x00/0x00 Tx(K1/K2) : 0x00/0x00 Remote Rx(K1/K2): 1/Remote Tx(K1/K2): 1/ BER thresholds: SF = 10e-3 SD = 10e-6 TCA thresholds: B1 = 10e-6 B2 = 10e-6 B3 = 10e-6 Optics type: VSR2000-3R2 (2km) Clock source: internal (actual) internal (configured) Optical Power Monitoring (accuracy: +/- 1dB) Rx power = 1.3796 mW, 1.4 dBm Tx power = 1.7380 mW, 2.4 dBm Tx laser current bias = 58.3 mA
Re: Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast Onvoy
Robert Boyle wrote: Either your firewall/router or the customer's firewall/router is blocking PMTUD packets. I suspect an overzealous firewall admin is blocking all icmp. Which you can't do anything about if the overzealous firewall admin is at the other end of the connection. My repeated, first-hand experience has been that several of the better-known web sites out there will happily send out 1500-byte packets with DF set, then ignore the DEST_UNREACH/FRAG_NEEDED icmp responses they get. If you're on the client end of this, you're sunk unless you initiate the connection specifying a lower MSS. Linux has a nifty iptables option (clamp-mss-to-pmtu) to rewrite the MSS in TCP SYN packets when forwarding a packet onto a link with a lower MTU than the MSS in the packet. Works like a charm. If every packet forwarding device on the Internet did this, PMTUD would not be needed. As is, PMTUD is simply broken, due to widespread firewall misconfiguration. As in so many other cases of Internet misbehavior, you can avoid being part of the problem, but you can't be the solution. Jim Shankland
Re: Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast Onvoy
On Thu, Aug 02, 2007, Jim Shankland wrote: Linux has a nifty iptables option (clamp-mss-to-pmtu) to rewrite the MSS in TCP SYN packets when forwarding a packet onto a link with a lower MTU than the MSS in the packet. Works like a charm. If every packet forwarding device on the Internet did this, PMTUD would not be needed. As is, PMTUD is simply broken, due to widespread firewall misconfiguration. As in so many other cases of Internet misbehavior, you can avoid being part of the problem, but you can't be the solution. .. non-TCP traffic? Adrian
Re: Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast Onvoy
Adrian Chadd wrote: On Thu, Aug 02, 2007, Jim Shankland wrote: Linux has a nifty iptables option (clamp-mss-to-pmtu) to rewrite the MSS in TCP SYN packets when forwarding a packet onto a link with a lower MTU than the MSS in the packet. Works like a charm. If every packet forwarding device on the Internet did this, PMTUD would not be needed. As is, PMTUD is simply broken, due to widespread firewall misconfiguration. As in so many other cases of Internet misbehavior, you can avoid being part of the problem, but you can't be the solution. .. non-TCP traffic? Hmm; I've never actually heard of anybody doing PMTUD on non-TCP traffic, though it's possible. Does anybody actually do it? Jim Shankland
Gwd: crypted document
WARNING!!! (from bach.merit.edu) The following message attachments were flagged by the antivirus scanner: Attachment [2.2] Message.scr, virus infected: W32/Bagle-CF. Action taken: deleted Ok. See attach. VIRUS WARNING Message (from bach.merit.edu) The virus W32/Bagle-CF was detected in email attachment [2.2] Message.scr. The infected attachment has been deleted.
Re: 365 Main reason for outage report published
On Wed, Aug 01, 2007 at 04:50:04PM -0400, J. Oquendo wrote: Sean Donelan wrote: The 365 Main San Francisco data center has published its report concerning the outage on July 24 after a utility problem. http://www.365main.com/status_update.html Other data centers using Hitec backup generators will want to review the 365's report and those with specific Hitec controllers may want to update them. www.infiltrated.net/hitecDDEC.jpg That JPEG is obscene! ;-) Register4Less recently reported a power failure in Montreal where the return of a single cycle from the utility tricked generators into shutting down all three cycles, throwing the data center onto UPS until the batteries died. They did not report make of generator or of the board that failed them. -- Joe Yao Analex Contractor
Re: Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast Onvoy
On Thu, 02 Aug 2007 18:33:16 PDT, Jim Shankland said:
Hmm; I've never actually heard of anybody doing PMTUD on non-TCP
traffic, though it's possible. Does anybody actually do it?
AIX 5.2 and earlier supported it for UDP (we're getting out of the AIX
business, so I can't speak to what 5.3 does). Basically, it would send out a
gratuitous 64K ICMP Echo Request with DF set, and waited to see what came back.
I ended up turning it off all over, simply because we didn't have enough
UDP-based services that actually hit frag issues to make a difference.
---
'man no' (Network Options) says:
no { -a | -d Attribute | -o Attribute [ =NewValue ] }
udp_pmtu_discover Enables or disables path MTU discovery for UDP applications.
UDP applications must be specifically written to utilize path MTU discovery. A
value of 0 disables the feature, while a value of 1 enables it. This attribute
only applies to AIX 4.2.1 or later. udp_pmtu_discover is a runtime attribute. In
versions prior to AIX 4.3.3, the default value is 0 (disabled); in AIX 4.3.3 and
later versions, the default value is 1 (enabled).
---
The manpage lies - It has to be specifically written to *benefit from* PMTUD.
It would go ahead and do it, and then 98% of the UDP programs wouldn't change
their behavior. So all you got was lots of gratuitous ICMP mobygrams.
It *may* have made a small difference during a short window, when NFS-over-TCP
support was still rare, and the 4500-octet FDDI MTU was sometimes to be found.
pgpM2BhhEjM7a.pgp
Description: PGP signature
price_03-Aug-2007
WARNING!!! (from bach.merit.edu) The following message attachments were flagged by the antivirus scanner: Attachment [2.2] latest_price03-Aug-2007.zip, virus infected: W32/Bagle-RC,W32/Bagle-QW. Action taken: deleted VIRUS WARNING Message (from bach.merit.edu) The virus W32/Bagle-RC,W32/Bagle-QW was detected in email attachment [2.2] latest_price03-Aug-2007.zip. The infected attachment has been deleted.
Fwd: [Err] Re: Gwd: crypted document
Uhhh...what??? -- Forwarded message -- From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Aug 2, 2007 7:26 PM Subject: [Err] Re: Gwd: crypted document To: [EMAIL PROTECTED] Transmit Report: [EMAIL PROTECTED] [EMAIL PROTECTED] 메일 발송을 2번 시도했지만 실패하였습니다. (실패 이유 : 554 Message rejected because it may contain Sober worm virus( 211.48.62.215)) 참고 실패 이유에 대한 설명 User unknown :메일을 수신할 사용자가 존재하지 않음 Socket connect fail:수신 메일 서버와 연결 실패 DATA write fail:수신 메일 서버로 메세지 송신 실패 DATA reponse fail :수신 메일 서버로부터 메세지 수신 실패 Final-Recipient: rfc822;[EMAIL PROTECTED] Diagnostic-Code: smtp; 554 error - Message rejected because it may contain Sober worm virus(211.48.62.215) Action: failed Status: 4.0.0 -- Forwarded message -- From: Hex Star [EMAIL PROTECTED] To: Cmadams [EMAIL PROTECTED], nanog@merit.edu Date: Thu, 2 Aug 2007 19:16:40 -0700 Subject: Re: Gwd: crypted document On 8/2/07, Cmadams [EMAIL PROTECTED] wrote: WARNING!!! (from bach.merit.edu) The following message attachments were flagged by the antivirus scanner: Attachment [2.2] Message.scr, virus infected: W32/Bagle-CF. Action taken: deleted Ok. See attach. VIRUS WARNING Message (from bach.merit.edu) The virus W32/Bagle-CF was detected in email attachment [2.2 ] Message.scr. The infected attachment has been deleted. Why would someone in the ISP industry try to spread a virus? Ironically I suppose a ISP admin may have their own computer infected... :P
Re: Gwd: crypted document
On 8/2/07, Cmadams [EMAIL PROTECTED] wrote: WARNING!!! (from bach.merit.edu) The following message attachments were flagged by the antivirus scanner: Attachment [2.2] Message.scr, virus infected: W32/Bagle-CF. Action taken: deleted Ok. See attach. VIRUS WARNING Message (from bach.merit.edu) The virus W32/Bagle-CF was detected in email attachment [2.2] Message.scr. The infected attachment has been deleted. Why would someone in the ISP industry try to spread a virus? Ironically I suppose a ISP admin may have their own computer infected... :P
Re: Gwd: crypted document
On Thu, 2007-08-02 at 19:16 -0700, Hex Star wrote: Why would someone in the ISP industry try to spread a virus? Ironically I suppose a ISP admin may have their own computer infected... :P Look at all the anti-spam software that uses perl yet the cpan mirror ops lists is throwing out a dozen or more PDF attachments each day now. -Jim P.
Re: Gwd: crypted document
Once upon a time, Hex Star [EMAIL PROTECTED] said: Why would someone in the ISP industry try to spread a virus? Ironically I suppose a ISP admin may have their own computer infected... :P Why would someone assume that the sender in a virus email is valid? Also, I want to thank all those with auto-responders that respond to list email for letting me know about this message to NANOG. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
RE: Gwd: crypted document
Hi Guys, It seems to me a lot of virus scanners picked up this behavior in the days of the I Love You and Melissa viruses, when virii tended to infect documents rather than be self-propagating worms. We haven't lived in a world where its likely a legitimate sender is unwittingly sending infected documents for awhile. It'd be nice if the AV/MTA vendors would take this feature out, or AV the message before they accept the DATA section and leave it to the sending mail server to bounce it. -J -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Adams Sent: Thursday, August 02, 2007 8:22 PM To: nanog@merit.edu Subject: Re: Gwd: crypted document Once upon a time, Hex Star [EMAIL PROTECTED] said: Why would someone in the ISP industry try to spread a virus? Ironically I suppose a ISP admin may have their own computer infected... :P Why would someone assume that the sender in a virus email is valid? Also, I want to thank all those with auto-responders that respond to list email for letting me know about this message to NANOG. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. !SIG:46b294c9156537812920785!
Re: Gwd: crypted document
On Thu, 02 Aug 2007 20:51:10 MDT, Jason J. W. Williams said: It seems to me a lot of virus scanners picked up this behavior in the days of the I Love You and Melissa viruses, when virii tended to infect documents rather than be self-propagating worms. We haven't lived in a world where its likely a legitimate sender is unwittingly sending infected documents for awhile. It'd be nice if the AV/MTA vendors would take this feature out, or AV the message before they accept the DATA section and leave it to the sending mail server to bounce it. What? And lose the free opportunity to spam you and tell you how good it is at finding viruses? (Particularly annoying when their products usually don't do anything useful on the platform that I actually send my mail from, but that's another rant) pgpzby98GqywD.pgp Description: PGP signature
Re: Gwd: crypted document
Once upon a time, Jon Lewis [EMAIL PROTECTED] said: If you could read the header, the question you would have asked is, What is Chris Adams doing in Korea sending virus mail to nanog? :) Especially as this particular Chris Adams is not well traveled and has never been west of the Mississippi! -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Gwd: crypted document
On Thu, 2 Aug 2007, Hex Star wrote: Why would someone in the ISP industry try to spread a virus? Ironically I suppose a ISP admin may have their own computer infected... :P If you could read the header, the question you would have asked is, What is Chris Adams doing in Korea sending virus mail to nanog? :) It's a shame there's no test before people subscribe. For the humor impaired, obviously, some PC in Korea is infected with the latest virus and has both Chris's and the nanog list's addresses handy. I wasn't kidding about the test thing though :) -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Gwd: crypted document
On 8/2/07, Jon Lewis [EMAIL PROTECTED] wrote: If you could read the header, the question you would have asked is, What is Chris Adams doing in Korea sending virus mail to nanog? :) It's a shame there's no test before people subscribe. For the humor impaired, obviously, some PC in Korea is infected with the latest virus and has both Chris's and the nanog list's addresses handy. I wasn't kidding about the test thing though :) Haha, good catch: Received: from BSLEE.net ([59.16.185.214]) by bach.merit.edu (MOS 3.8.2-GA) with SMTP id AEE75050; *inetnum*: 59.0.0.0 - 59.31.255.255 netname: KORNET descr:KOREA TELECOM descr:Network Management Center country: KR admin-c: IM76-AP http://wq.apnic.net/apnic-bin/whois.pl?searchtext=IM76-APform_type=advanced tech-c: IM76-AP http://wq.apnic.net/apnic-bin/whois.pl?searchtext=IM76-APform_type=advanced Thu, 2 Aug 2007 21:34:17 -0400 (EDT)
Re: Gwd: crypted document
On Thu, 2007-08-02 at 22:53 -0400, Jon Lewis wrote: On Thu, 2 Aug 2007, Hex Star wrote: Why would someone in the ISP industry try to spread a virus? Ironically I suppose a ISP admin may have their own computer infected... :P If you could read the header, the question you would have asked is, What is Chris Adams doing in Korea sending virus mail to nanog? :) It's a shame there's no test before people subscribe. For the humor impaired, obviously, some PC in Korea is infected with the latest virus and has both Chris's and the nanog list's addresses handy. I wasn't kidding about the test thing though :) Are we sure it's Chris? I could have very easily sent this email as from Jon Lewis... and mail.merit.edu would accept it an send it on through. -Jim P.
Re: Gwd: crypted document
On Aug 2, 2007, at 7:22 PM, Chris Adams wrote: Once upon a time, Hex Star [EMAIL PROTECTED] said: Why would someone in the ISP industry try to spread a virus? Ironically I suppose a ISP admin may have their own computer infected... :P Why would someone assume that the sender in a virus email is valid? A few, it's because the developers really are that stupid. Mostly, though, it's that they think that if they pretend to be that stupid then they can advertise their product via spam that's sent from a wide variety of places that can't all be easily blocked. (Most of the developers I've talked to say that they know it's stupid, but that's the product requirements they have to work with). Cheers, Steve
Please stop (Re: Gwd: crypted document)
On Thu, 2 Aug 2007, Chris Adams wrote: Once upon a time, Jon Lewis [EMAIL PROTECTED] said: If you could read the header, the question you would have asked is, What is Chris Adams doing in Korea sending virus mail to nanog? :) Especially as this particular Chris Adams is not well traveled and has never been west of the Mississippi! I think at this point, its fairly clear what happened (fake sender, reply that went to list etc) so continued discussion is rather fruitless. Lesson to be learned: You cannot protect from human factors. :( -alex (mlc chair)
Gwd: Incoming Message
WARNING!!! (from bach.merit.edu) The following message attachments were flagged by the antivirus scanner: Attachment [2.2] XXX_livebabes.scr, virus infected: W32/Bagle-CF. Action taken: deleted Ok. Here is the file. VIRUS WARNING Message (from bach.merit.edu) The virus W32/Bagle-CF was detected in email attachment [2.2] XXX_livebabes.scr. The infected attachment has been deleted.
RE: BotHunter
Not soon but maybe eventually. You could also install this on a low-end spare computer at home, and see if you are comfortable with it. Marc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Kadow Sent: Thursday, August 02, 2007 3:02 PM To: Nanog Cc: Marcus H. Sachs Subject: Re: BotHunter Any chance of a platform-independent source release of BotHunter? I have neither Linux nor Intel available, and a policy forbidding running unknown binaries. Kevin
price-03-Aug-2007
WARNING!!! (from bach.merit.edu) The following message attachments were flagged by the antivirus scanner: Attachment [2.2] latest_price03-Aug-2007.zip, virus infected: W32/Bagle-RC,W32/Bagle-QW. Action taken: deleted VIRUS WARNING Message (from bach.merit.edu) The virus W32/Bagle-RC,W32/Bagle-QW was detected in email attachment [2.2] latest_price03-Aug-2007.zip. The infected attachment has been deleted.
