October 2010 - Test - lists.nanog.org

BGP next-hop
by Heath Jones 01 Oct '10

01 Oct '10

Hi all, Is there an easy way to see which iBGP routes are not being selected due to next-hop not being in IGP? Before and after IGP route added shown below, note both are marked as valid.. -- BEFORE IGP-- AS5000_LA#show ip bgp BGP table version is 5, local router ID is 10.0.0.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i100.10.0.0/16 10.0.0.10 0 100 0 2000 3000 ? *> 10.0.0.6 0 1000 3000 3000 ? -- AFTER IGP-- AS5000_LA#show ip bgp BGP table version is 6, local router ID is 10.0.0.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i100.10.0.0/16 10.0.0.10 0 100 0 2000 3000 ? * 10.0.0.6 0 1000 3000 3000 ? Cheers Heath ps. I've posted this to cisco-nsp also (a day ago) - so apologies in advance if you are on both and seeing it twice.

11 17

Re: RIP Justification
by Guerra, Ruben 01 Oct '10

01 Oct '10

I am with Scott on this one.. I took the initial question as a focus on the edge... not the CORE. RIP is perfect for the edge to commercial CPEs. Why would want to run OSPF/ISIS at the edge. I would hope that it would be common practice to not use RIP in the CORE.... peace -- Ruben Guerra --------- Sent from my Nokia N900 ----- Original message ----- > Haha It's all good :) > You are right about IS-IS being less resource intensive than OSPF, and > that it scales better! > > > > On 30 September 2010 23:50, Jack Carrozzo <jack(a)crepinc.com<mailto:jack@crepinc.com>> wrote: > > > > > > > > Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because > > > of the ISO addressing. Atleast thats my take on it.. > > > > Sorry, my mistake. I'll go sit in my corner now... > > -Jack >

2 1

(cisco, or any) acl *reducers* out there?
by George Michaelson 01 Oct '10

01 Oct '10

I have been looking at acl management s/w in the freecode space and I can find lots of tools which manage/distribute and test ACLs in routers. I'm wondering if anyone has written a parser which can construct rule-trees and get rid of the cruft, unusable, order-misorder and other issues in a large ACL pool? Its possible this is NP in the wider sense, but even a partial improvement would be useful something which can take a couple of hundred basic and extended ACLs and tell you these <ten> don't work these <twenty> conflict the remaining <x> have a sequence and can reduce to this basic <x-y> set (we've got the usual "acquisition of rule by accretion" problem across 4 edge/core routers with a mix of public facing, internal, WiFi, guest rules, and I hate to think this is either start from scratch, or intractable. The evidence is that its FRAGILE) -G

8 13

First Data Corporation?
by Leo Woltz 01 Oct '10

01 Oct '10

Anyone on the list from First Data Corporation or familar with there network?

2 1

Re: LISP Works - Re: Facebook Issues/Outage in Southeast?
by Job W. J. Snijders 01 Oct '10

01 Oct '10

Dear Cameron, On Wed, Sep 29, 2010 at 3:27 AM, Cameron Byrne <cb.list6(a)gmail.com> wrote: >> The fact that LISP does help in IPv6 Transition solutions (due to its inherent AF agnostic design), is compelling. As you say, real edge 2 edge is the goal - and LISP helps here, regardless of the AF. (you'll will still want to do multi-homing in IPv6, and ingress TE, and mobility, etc.). >> > > Sorry, when i said e2e w.r.t IPv6 i was talking about end to end, not > edge to edge. I think there is a big difference. Oops, i meant end to end too, don't know why I typed edge2edge. :-) > IMHO, ILNP is the more interesting solution and avoids expensive > encapsulation and questionable assumptions about ISP MTU, all my ISP > links are GigE and 10GigE and they are all set to default 1500 bytes > ... good or bad, this is just how they roll off the line from every > ISP in every city i buy transit... and LISP tunnels do not work so > well with 1500 byte MTU. I beg to differ, LISP works excellent with 1500 byte MTU. But you point out a significant aspect of LISP; hosts behind LISP rely a bit on path MTU discovery, with all it's benefits and drawbacks. But that's not a show stopper i've seen on the lisp beta network. We live in a world where PMTUD is daily practice, ILNP will not make PMTUD go away. My major concern with ILNP is that eventually all hosts need to be upgraded/changed to take advantage of ILNP. If we take a hard look at something like SCTP... it never was really populair in the wild even though it's in the Linux kernel. I'd rather load new software on hundreds CPE's then change ten thousands of hosts, with all variations, versions, servicepacks. Another example: the rate at which IPv6 has been adopted in operating systems is horrible, we cannot wait another 10 or so years. So I actually consider it one of the best features of LISP that hosts don't need to be changed and the scope has been reduced to just the 'edge' or 'CPE'. In this sense one might even consider LISP to be more backwards compatible then ILNP. :-) Last, ILNP has no viable plan for IPv4, an address family we cannot easily discard. The critique in draft-irtf-rrg-recommendation-14 on ILNP's hIPv4 is heavy, and can be summerized with: "It appears that hIPv4 involves major practical difficulties which mean that in its current form it is not suitable for IETF development.." Kind regards, Job Snijders

2 3

AS27626, AS6061, AS10392, AS11296 - Hijacks Gone Wild!
by Ronald F. Guilmette 01 Oct '10

01 Oct '10

[[ NOTE: This information is being made available to information content providers, or others, as part of the technical means to restrict access to material with may be deemed by some to be obscene, lewd, lascivious, filthy, excessively violent, harassing, or otherwise objectionable, in accordance with 47 USC 230(c)(2)(B). ]] Whew! Now that I got THAT out of the way... I _had_ planned on dribbling out this info, one AS at a time, because I thought that might yield a slightly more ponderous effect, but since another big batch of this info was already made (semi-)public today on another mailing list I'm on, there doesn't seem to be any real point in dragging this out anymore. So here is the whole enchalada... at least with respect to THIS whole interconnected mess. (Yes, there are others. We'll get to them. Be patient.) AS27626, aka Joytel of Jacksonville, Florida, would appear to be at the heart of a rather sizable AS and IP block hijacking campaign, the likes of which, in my experience, the net has never before seen. I mean the total amount of IP space that's been jacked may be smaller than some past big-time hijacks, but this one takes the cake, I think, for the number of separate different IP blocks involved... a number which has actually even been growing stedily over the past week. (These turkeys appear to be in a race to corner the market on abandoned IP blocks. Jeeeesh!) In addition to a metric buttload of jacked blocks being announced by Joytel ltself, AS27626, (see below) there are _three_ other ASes that also appear to be jacked, and each of these also appears to be separately announcing routes to yet more jacked IP blocks. But all of these machinations appear to be to be tied together, if in no other way, then at least by the common thread of the same single common snowshoe spamming company (in Victoria, BC) being the primary (but probably not the only) ultimate beneficiary of all of this hijacking. I have already reported here on two of these other ASes, i.e. AS11296 and AS10392. I now report on a third apparently hijacked AS, i.e. AS6061. See details below. Note that the routes that were being announced by AS11296 have already been withdrawn, but the old route announcements are still listed below, for the sake of completeness. Additionally, I am reporting here on three somewhat stealthy IP blocks that appear to have been legitimately obtained by Joytel... two on Level3 and one on Cogent... all of which appear to me to be infested with/by _some_ snowshoe spammer. (Perhaps someone or something other than the previously mentioned company in Victoria, BC. I haven't actually checked that yet, one way or the other.) As indicated below, the various blocks that I've annotated as "jacked" are in fact, and exclusively, very old, and most probably abandoned IP blocks. That's why they were chosen, specifically, i.e. because it was thought that nobody would miss them, and nobody would even notice that they had been ``liberated''. And that probably would have been true, if it were not for the fact that some of them were then filled up with snowshoe spam domains. As I mentioned previously, spamming is THE most public of crimes. It's hard to make any money at it unless you are annoying millions of people at a time, and thus alerting them to your presence. And when you do that, you are going to draw attention to yourself, big time. I'm not going to even make any sort of suggestion to people, this time, as to what they might want to do with all of the information below, since people gave me a hard time when I did that before. So I'll just leave it as this: You are all clever people here. Use your imagination. I have included below a very partial NS dump for one of the blocks being announced by AS10392 that shows some of the snowshoe pattern there. If people want to see the complete NS dumps for all of the blocks listed below, so that they can independently verify the snowshoey-ness of all this stuff, then ask and you shall receive. One last thing... AS11296 (Interpath) was (is?) only connected to the net via AS27524 (Xeex). Since it is no longer announcing any routes, this is moot, and a non-issue at this time. Everything else you see below all represents open issues. I would like to especially beg, plead, and cajole any customers of AS3491, aka Beyond The Network America, Inc. who may be reading this to PLEASE contact your provider and demand an answer to this simple question: WTF do they think they are doing by peering with AS6061 and AS10392, and who the bleep is actually writing them monthly checks for that? Beyond The Network America, Inc. needs to answer for this too, since they are unambiguously facilitating this ongoing crime. As regards to the ongoing situation with AS27626, aka Joytel, you can readily see here who is keeping _them_ alive and connected: http://www.robtex.com/as/as27626.html#graph AS3356 -- Level3 AS33132 -- FPL FiberNet, LLC If you are a customer of either of these providers, or even a peer, I do encourage you to contact them, and ask them WTF they are thinking. I, for one, sure would like to know. Regards, rfg ============================================================================= AS27626 (Joytel.net, Jacksonville, FL): 24.230.0.0/19 NET-24-230-0-0-1 jacked - empty 68.67.64.0/20 NET-68-67-64-0-1 legit -- GoRack, LLC (Jacksonville, FL) 192.100.5.0/24 NET-192-100-5-0-1 jacked - empty 192.100.88.0/24 NET-192-100-88-0-1 jacked - empty 192.100.134.0/24 NET-192-100-134-0-1 jacked - empty 192.100.143.0/24 NET-192-100-143-0-1 jacked - empty 192.101.177.0/24 NET-192-101-177-0-1 jacked - empty 192.101.187.0/24 NET-192-101-187-0-1 jacked - empty 192.235.32.0/19 NET-192-235-32-0-1 jacked - empty 198.13.16.0/20 NET-198-13-16-0-1 jacked - empty 198.14.16.0/20 NET-198-14-16-0-1 jacked - empty 198.143.128.0/19 NET-198-143-128-0-1 jacked - empty 198.183.32.0/19 NET-198-183-32-0-1 jacked - mucho snowshoe ns 198.210.32.0/19 NET-198-210-32-0-1 jacked - empty 198.241.64.0/18 NET-198-241-64-0-1 jacked - mucho snowshoe ns 198.252.64.0/18 NET-198-252-64-0-1 jacked - empty 199.34.128.0/18 NET-199-34-128-0-1 jacked - empty 199.46.32.0/19 NET-199-46-32-0-1 jacked - empty 199.84.64.0/19 NET-199-84-64-0-1 jacked - empty 199.198.160.0/19 NET-199-198-140-0-1 jacked - empty 204.48.64.0/19 NET-204-48-64-0-1 jacked - empty 204.107.208.0/24 NET-204-107-208-0-1 jacked - just two spammer ns'es 205.144.0.0/20 NET-205-144-0-0-1 jacked - mucho snowshoe ns 206.224.160.0/19 NET-206-224-160-0-1 jacked - empty 206.227.64.0/18 NET-206-227-64-0-1 jacked - empty 208.93.220.0/22 NET-208-93-220-0-1 Actually does belong to Joytel! 216.49.0.0/18 NET-216-49-0-0-1 jacked - empty 216.245.64.0/18 NET-216-245-64-0-1 jacked - empty ============================================================================= AS6061 (Datalytics, Inc - connected only via AS3491 -- Hijacked AS?): 198.187.64.0/18 NET-198-187-64-0-1 198.187.64.0/20 jacked - mucho snowshoe ns 198.187.80.0/20 jacked - mucho snowshoe ns 198.187.96.0/20 jacked - empty 198.187.112.0/20 jacked - empty 209.201.128.0/17 NET-209-201-128-0-1 209.201.128.0/20 jacked - empty 209.201.144.0/20 jacked - empty 209.201.160.0/20 jacked - empty 209.201.176.0/20 jacked - empty 209.201.192.0/20 jacked - empty 209.201.208.0/20 jacked - empty 209.201.224.0/20 jacked - empty 209.201.240.0/20 jacked - empty ============================================================================= AS10392 (GlassCity Internet, Inc. - connected only via AS3491): 192.171.64.0/19 NET-192-171-64-0-1 jacked - some snowshoe 204.137.224.0/19 NET-204-137-224-0-1 jacked - empty 205.164.0.0/18 NET-205-164-0-0-1 205.164.0.0/20 jacked - mucho snowshoe ns 205.164.16.0/20 jacked - empty 205.164.32.0/20 jacked - empty 205.164.48.0/20 jacked - empty 192.171.64.156 1 ns1.carnhamandassochaddel.info 6 youworkinginternationalco.info topgunandinmcb.info picallilyaframeco.info peacondeliverycopcogas.info chillonagabrainpower.info enabledsearchingforcrossco.net 192.171.64.157 1 ns2.carnhamandassochaddel.info 6 youworkinginternationalco.info topgunandinmcb.info picallilyaframeco.info peacondeliverycopcogas.info chillonagabrainpower.info enabledsearchingforcrossco.net ... ============================================================================= AS11296 (Interpath - Routed only via AS27524 Xeex aka NR Software/Nishant Ramachandran): http://www.thefreelibrary.com/USi+Completes+Restructuring,+Receives+$81+Mil… http://www.att.com/gen/press-room?pid=5097&cdvn=news&newsarticleid=22973 63.247.160.0/19 NET-63-247-160-0-1 jacked - empty -- popularfh.com -- all MXes DoA 199.241.64.0/19 NET-199-241-64-0-1 jacked - snowshoe ns @ 199.241.95.253 -- no email! 206.226.64.0/18 NET-206-226-64-0-1 jacked - snowshoe ns @206.226.96.{2,3} seikotsi.com -- Grand Cayman 11-20-2009 206.226.64.0/24 206.226.65.0/24 206.226.66.0/24 206.226.67.0/24 206.226.68.0/24 206.226.69.0/24 206.226.70.0/24 206.226.71.0/24 206.226.72.0/24 206.226.73.0/24 206.226.74.0/24 206.226.75.0/24 206.226.76.0/24 206.226.77.0/24 206.226.78.0/24 206.226.79.0/24 206.226.96.0/19 ============================================================================= Legitimate semi-stealth allocations: Joytel on Level3: 8.22.200.0/21 (snowshoe) Joytel on Level3: 8.24.224.0/20 (snowshoe) Joytel on Cogent: 38.124.176.0/20 (snowshoe) =============================================================================

1 0

Re: NANOG Digest, Vol 32, Issue 119
by DMFH 01 Oct '10

01 Oct '10

Thu, 30 Sep 2010 14:22:07 +0000 nanog-request(a)nanog.org fuream loqour : >If your network is of a scale where it exceeds the utility of static, >then, it is almost certainly of a scale >and topology where it exceeds the utility of RIP. I'd agree that RIP is old, aged, and we all can probably go on with personal horror stories of how a broadcast-only-based routing protocol created a small or large pocket of disaster alone or combined with some other technology below or above its layer in the stack. However, like some other speakers in this thread mentioned, situation + simplicity + engineering = success. RIP certainly has it's place in small pockets now, I still use it in places mostly just to float a few loopbacks or statics around with old equipment, or firewalls I don't trust doing a more robust routing protocol. I see routing protocols, operating systems too, as different tools. If the tool works, fits, and rarely breaks where it's used, cool - I like simple & predictable, which includes predictable failure as well as predictable success. RIP also has the advantage of being around for a long while, so most devices will "get it right" - more complex routing protocol code, found in other IGPs, etc. - exceptions / vendor implementations still rule. I've never done a multicast network with RIP though... *winks* =) /dmfh -- __| |_ __ / _| |_ 01100100 01101101 / _` | ' \| _| ' \ 01100110 01101000 \__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx

1 0