- NANOG - lists.nanog.org

DNS traffic sourced from my address space to myself.
by Drew Weaver 07 Jul '10

07 Jul '10

Howdy, Recently I have been noticing a good amount of totally bogus DNS traffic coming in on my transit links via my own IP addresses (spoofed). SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.145.161(0) -> x.x.145.235(0), 1 packet SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.146.74(0) -> x.x.145.235(0), 1 packet SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.146.70(0) -> x.x.145.235(0), 1 packet SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.146.57(0) -> x.x.145.235(0), 1 packet There are multiple different instances of this traffic, the pattern seems to be: -The source is always 'my own IPs' and obviously spoofed. -It's DNS traffic -The "source addresses" all seem to be randomly chosen from the same /23 as the destination address (they cycle through randomly). Has anyone else noticed anything similar coming in on their transit links or am I just lucky? Normally my iACL catches this but I've just been noticing more of it lately. -Drew

3 2

Overseas - Latency
by Eric Williams 07 Jul '10

07 Jul '10

We have several customers that are reporting horrible latency when coming from overseas (Israel, Europe, etc...) Looking at a few global maps for latency, I don't see any issues. Does anybody know of any fiber cuts or any issues currently going on? FYI, the customer in question at my datacenter currently uses Level3 and Cogent and we reside in St. Louis.

5 5

Mikrotik & OC-3 Connection
by Alan Bryant 07 Jul '10

07 Jul '10

I haven't seen much traffic on this list about Mikrotik or RouterOS, but I thought it was worth a shot as a last ditch effort to get this going. Does anyone know of a solution to connect a POS OC-3 to a router running Mikrotik's RouterOS? I have searched google extensively with varying phrases and nothing helpful comes out of it. -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan(a)gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405

16 22

Re: Mikrotik & OC-3 Connection
by Jonathon Exley 07 Jul '10

07 Jul '10

In terms of FOSS routing platforms, I think Vyatta has a better user interface than Mikrotik. IMHO if the CLI is awkward then there a higher risk of misconfiguration. I haven't used either enough to comment about stability. Jonathon. This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).

5 5

Penetration Test Vendors - The List
by George Bonser 06 Jul '10

06 Jul '10

Quite a varied list. As one respondent put it (possibly paraphrased) "security testing is like underwear, everyone has their own preference". In this case we are likely to go with one of the vendors suggested by our client who has done work for them before and who they feel comfortable with. Thanks for your feedback, everyone, and I hope I didn't miss any. VZB (Verizon Business) IBM ISS (multiple positive) SecureWorks MSS (multiple positive recommendations, multiple negative) Sysnet (sysnet.ie) Deloitte (reported poor result) British Telecom Managed Services Mandiant Inguardians (multiple positive) Metasploit Rapid7 BreakingPoint Counterpane MWR Infosec Corsaire KPMG (negative) Vulnerability Research Labs C2 Company Fishnet Security Neohapsis Trustwave/Ambiron (multiple positive, multiple negative) Terremark Qualys Foundstone Netcraft Patch Advisor Praetorian Global Netragard Enclave Core Security Technologies Matasano Stach & Liu Gotham Digital Science Secure Network Technologies

1 0

[NANOG-announce] NANOG 50 Call for Presentations now available
by David Meyer 06 Jul '10

06 Jul '10

Folks, Its time to start thinking about the presentation(s) you want to give at NANOG 50. NANOG 50 is our annual joint meeting with ARIN, so there will be great opportunities to present both the NANOG and ARIN communities. We had a great deal of content for NANOG 49 so if your talk wasn't accepted please consider resubmitting for NANOG 50. The Call for Presentations can be found on http://nanog.org/meetings/nanog50/callforpresent.php Looking forward to seeing all of you in Atlanta. Dave (for the NANOG PC) _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Re: XO feedback
by Net 05 Jul '10

05 Jul '10

Thanks for reaching out Brian. We'll certainly keep Saavis in mind and advise as deemed fit. Regards, On 7/1/10, Bellis, Brian <Brian.Bellis(a)savvis.net> wrote: > Dear Funky Fun, > > Have you consider Savvis for IP transit. We are a Tier 1 IP backbone > provider operating AS-3561. We announce approximately 23% of all > internet routes on our backbone and are privately peered with all other > Tier 1 providers meaning we don't buy upstream to gain access to routes. > We are very price competitive and offer fixed and burstable pricing. We > are located in virtually every telehouse across the US and have PoPs in > London, Paris, Frankfurt and Amsterdam. > > No pressure here and no need to respond if you are not interested. Just > wanted to give you another option you may have not considered. Thank > you. > > Best regards, > > Brian > > > > Brian Bellis | Sr. Sales Director Service Providers > > > > Savvis > 2355 Dulles Corner Blvd, Herndon, VA 20171 > Office: 703.667.6254 | Mobile: 202.997.1336 | Fax: 703.880.7239 > > E-mail: brian.bellis(a)savvis.net > > www.savvis.net > > > > > -----Original Message----- > From: Net [mailto:funkyfun@gmail.com] > Sent: Thursday, July 01, 2010 7:52 AM > To: nanog(a)nanog.org > Subject: XO feedback > > Hi, > > We're currently looking to buy transit from XO for one of our DCs. > Their pricing is very competative compared to some of the other > providers we've considered to date. > > I'm hoping to get some feedback on their services, support, peering > arrangements and the overall stability of their core backbone network > from folks who've had experience or currently using them. > > Any info would be greatly appreciated. > > Thanks in advance > > -- > Sent from my mobile device > > > This message contains information which may be confidential and/or > privileged. Unless you are the intended recipient (or authorized to receive > for the intended recipient), you may not read, use, copy or disclose to > anyone the message or any information contained in the message. If you have > received the message in error, please advise the sender by reply e-mail and > delete the message and any attachment(s) thereto without retaining any > copies. > -- Sent from my mobile device

6 6

Re: Mikrotik & OC-3 Connection
by msokolov＠ivan.Harhan.ORG 05 Jul '10

05 Jul '10

Adrian Chadd <adrian(a)creative.net.au> wrote: > FreeBSD netgraph. It's clean, it's generalised, it's just not very well > documented. > [...] > Have a chat to the FreeBSD community. There's a powerpc port. Shoehorn > FreeBSD into it somehow, help tidy up the code to do whateveer you need > and start leveraging the very powerful network stack FreeBSD has. Thanks for the tip - that sounds very nice indeed, very much like what I had in mind. It's nice to know that *someone* in the generic free OS world has had the foresight to design this thing right. (Just to be clear, I have no political preferences between Linux and FreeBSD; to me it's all a matter of what works and what I'm familiar with.) But it won't matter until I build the hardware: I want to build the hardware first, the HW itself will be totally open source as in free schematics and full docs etc, and then we'll think about which free OS(es) we want to run on it. I still want to build my MPC866 router platform though: even if the software part has been solved by the fine FreeBSD folks, with the present situation (PCI as the expansion interface on FreeBSD/Linux-based routers) one still has the issue that the HDLC interface or the ATM SAR block has to be wheel-reinvented each time someone wants a different flavor of Layer 1 physical interface. The situation is even more pronounced when a given Layer 1 medium type (say, T1 or SDSL) exists in both HDLC and ATM flavors. I would really like to be able to have a single hardware card that supports both: it is trivial with MPC86x, but I expect it to be cost-prohibitive to do that on a PCI card. MS

1 0

Re: Mikrotik & OC-3 Connection
by msokolov＠ivan.Harhan.ORG 05 Jul '10

05 Jul '10

OK, I'll bite and add my 2 Russian kopecks to the Cisco vs. Linux router thread. To make it clear where I'm coming from, I see the networking world from the viewpoint of non-Ethernet WAN interfaces. A world consisting of nothing but Ethernet is too bland and boring for me to live in, and I choose not to live in such an Ethernet-only world. I do indeed like the good old ifconfig & route better than Cisco IOS stuff: it's simpler, makes more sense to me, and fits my simple needs. However, this model works well for Ethernet because it's very simple: with Ethernet one generally has a 1:1 correspondence between the physical hardware unit and the logical "network interface" unit visible to ifconfig and the rest of the BSD/Linux network stack. But that is most definitely not the case for non-Ethernet WAN interfaces, and that is where I see a big shortcoming in what's currently available in the Linux router world. With non-Ethernet WAN interfaces one really needs an extra layer of highly configurable software functionality sandwiched in between the hardware interface unit and the ifconfig layer. The physical hardware interface is a synchronous serial bit stream processor that sends and receives either HDLC frames or ATM cells, and that is where the hardware-dictated part ends. Let's take the case of HDLC as it's more pleasant than ATM: in the case of HDLC the software layer between the HDLC controller and the ifconfig layer needs to do the following: * Let the user choose the encapsulation, and there are many choices: Cisco HDLC, straight PPP (RFC 1662), Frame Relay, PPP over FR (RFC 1973), ATM FUNI, etc. * If it's a Frame Relay encapsulation, let the user configure DLCIs. Oh, and there can be more than one, hence there may be multiple ifconfig-able entities on the same FR interface. * RFC 1490 (FR) and RFC 1483 (ATM) both allow bridged/MAC-encapsulated and true routed circuits; our software layer should support both, as as well as the possibility of mixing the two on different FR interfaces or different DLCIs on the same interface. These two modes need to look different to the ifconfig layer: if it's a bridged encapsulation, ifconfig needs to see a virtual Ethernet interface ("virteth0" or "macwan0"); if it's a true routed encapsulation, ifconfig needs to see a MAC-less and ARP-less point-to-point interface like "ipwan0". * Now let's support both HDLC and serial ATM (bit-by-bit cell delineation) if the underlying hardware is capable of both (like Freescale MPC862 and MPC866). Let's provide a user to switch between the two with a simple software command, and let's provide as much commonality as possible between the two configurations: let's support all RFC 1483 encapsulations on HDLC via FUNI, but make the configuration commands look just like ATM. Let's also support FRF.5 by allowing one to take an ATM PVC and treat its payload as a virtual HDLC interface, with possibly many FR DLCIs inside. I would love to be corrected on this, but I am not aware of anyone having implemented all of the above for Linux (or for any BSD variant) in a clean and generalized manner. Instead what we see is that each vendor of a PCI card for some non-Ethernet WAN interface has their own ad hoc solution which typically comes nowhere close to what I've outlined above in terms of generality and flexibility. Now here is something I'd like to build which will attempt to solve this mess. I'd like to build a modular WAN router based on the MPC866 chip from Freescale, former Motorola. MPC866 is a PowerPC with one very neat twist: it has 4 serial communication controller (SCC) cores on chip. Each SCC has a traditional 7-wire serial interface coming out of it (Rx data, Rx clock, Tx data, Tx clock, RTS, CTS and CD) and supports both HDLC and serial ATM. (The serial ATM mode supports both bit-by-bit cell delineation for a raw bit stream and octet-by-octet cell delineation for use with a framer that provides octet boundaries.) My modular router would be rather unique in that the interface to the pluggable WAN modules would not be PCI or anything of that sort, instead it would be the 7-wire serial interface coming from an MPC866 SCC, and there would be 4 possible daughtercard slots corresponding to the 4 SCCs. When the interface for pluggable WAN modules is something like PCI, the HDLC or ATM (including SAR) core has to be reimplemented anew by everyone who wants to build a new WAN module for a different flavor of Layer 1 physical interface, and I find it wasteful. The proliferation of such reinvented-wheel HDLC/ATM reimplementations is precisely the reason why there is no universally-accepted standardized framework for non-Ethernet WAN interfaces in Linux or *BSD. But if the cores implementing HDLC and ATM SAR reside inside the CPU chip like they do with MPC86x processors, we can have ONE well-written generic driver for these cores, and it will work exactly the same way and provide exactly the same array of configurable Layer 2 options to the user regardless of which Layer 1 interface is used: we can build daughtercards for T1/E1, for SDSL, for T3/E3, etc, and the specialized circuitry on each of these daughtercards will only concern itself with Layer 1, not with HDLC or ATM SAR. I would greatly appreciate any leads/ideas/suggestions as to who might possibly be interested in funding such a project. :-) MS

2 1

The Economist, cyber war issue
by Gadi Evron 04 Jul '10

04 Jul '10

The upcoming issue will be about cyber war. Check out the front page image: http://sphotos.ak.fbcdn.net/hphotos-ak-snc3/hs488.snc3/26668_410367784059_6… Gadi.

6 8