September 2014 - Test - lists.nanog.org

upstream support for flowspec
by Daniel Corbe 18 Sep '14

18 Sep '14

I was perusing RFC5575 after reading a presentation that ALU did (presumably during some previous NANOG conference). Reference: https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.sero… This seems like it would be a godsend for small operators like myself who don't have access to unlimited bandwidth and are put off by off-site scrubbing services. As far as I can tell though the only platforms that offer support are the 7750-SR and platforms made by Juniper. Is there anything in the air about widening the adoption base? Cisco? Brocade? And once that happens, what are the chances of services providers adopting this for their customers to make use of on as wide of a scale as (for example) blackhole community strings. I'd certainly *love* to have a way to mitigate an attack that doesn't involve me sacrificing one service on my network to save the rest. Best, Daniel

7 10

RE: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
by Brock Massel 18 Sep '14

18 Sep '14

Karsten, Thank you I am not sure why those 702 and 19294 old entries would still be there. We have engaged 812 for help. Shall I assume cleaning up the old entries will solve the problems? -----Original Message----- From: Karsten Elfenbein [mailto:karsten.elfenbein@gmail.com] Sent: Thursday, September 18, 2014 5:46 PM To: Brock Massel Cc: nanog(a)nanog.org Subject: Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO Hi, looks like you mainly use one transit provider (AS812) or your other transit providers correctly filter that prefix. According to https://stat.ripe.net/data/prefix-routing-consistency/data.json?preferred_v… there is no route object for the 192.250.24.0/22. As a result the AS6453(TATA COMMUNICATIONS (AMERICA) INC) seemed to have started filtering the prefix from AS812. Which reduced the visibility of that prefix. Check the BGplay from the last days: https://stat.ripe.net/192.250.24.0%2F22#tabId=routing so create the correct route object and the prefix should come up over the next day(s) Also get the more specific route objects removed which point to other AS. 192.250.24.0/23 AS702 192.250.24.0/24 AS19294 Karsten 2014-09-18 22:42 GMT+02:00 Brock Massel <BMassel(a)descartes.com>: > Hi folks, > I'm hoping someone can shed some light on the situation. > > The 192.250.24 addresses have been reachable for several months in the current configuration with no reported issues. Since the 16th we have been hearing reports that destinations in that block are unavailable for some. > > Several looking glass' report network not in table. > > Can someone lend a hand? What is the best way to improve this situation? How do we find where the problem is? > > B

2 1

Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
by Karsten Elfenbein 18 Sep '14

18 Sep '14

Hi, looks like you mainly use one transit provider (AS812) or your other transit providers correctly filter that prefix. According to https://stat.ripe.net/data/prefix-routing-consistency/data.json?preferred_v… there is no route object for the 192.250.24.0/22. As a result the AS6453(TATA COMMUNICATIONS (AMERICA) INC) seemed to have started filtering the prefix from AS812. Which reduced the visibility of that prefix. Check the BGplay from the last days: https://stat.ripe.net/192.250.24.0%2F22#tabId=routing so create the correct route object and the prefix should come up over the next day(s) Also get the more specific route objects removed which point to other AS. 192.250.24.0/23 AS702 192.250.24.0/24 AS19294 Karsten 2014-09-18 23:46 GMT+02:00 Karsten Elfenbein <karsten.elfenbein(a)gmail.com>: > Hi, > > looks like you mainly use one transit provider (AS812) or your other > transit providers correctly filter that prefix. > > According to https://stat.ripe.net/data/prefix-routing-consistency/data.json?preferred_v… > there is no route object for the 192.250.24.0/22. > As a result the AS6453(TATA COMMUNICATIONS (AMERICA) INC) seemed to > have started filtering the prefix from AS812. Which reduced the > visibility of that prefix. Check the BGplay from the last days: > https://stat.ripe.net/192.250.24.0%2F22#tabId=routing > > so create the correct route object and the prefix should come up over > the next day(s) > > Also get the more specific route objects removed which point to other AS. > > 192.250.24.0/23 AS702 > 192.250.24.0/24 AS19294 > > > > Karsten > > 2014-09-18 22:42 GMT+02:00 Brock Massel <BMassel(a)descartes.com>: >> Hi folks, >> I'm hoping someone can shed some light on the situation. >> >> The 192.250.24 addresses have been reachable for several months in the current configuration with no reported issues. Since the 16th we have been hearing reports that destinations in that block are unavailable for some. >> >> Several looking glass' report network not in table. >> >> Can someone lend a hand? What is the best way to improve this situation? How do we find where the problem is? >> >> B

1 0

Outbound traffic from 208.89.136.0/22 going from L.A. to London?
by Todd Lyons 18 Sep '14

18 Sep '14

I'm seeing some weird routing outbound for *some* destinations. Testing from 208.89.139.252. google.com resolves for me to 74.125.239.112 and the outbound path is fast and appears to stay in the US. yahoo.com resolves for me to 98.138.253.109, but the outbound path goes through Savvis London, then to BT, then to Yahoo. # mtr 98.138.253.109 --report --report-cycles 10 HOST: mail.mrball.net Loss% Snt Last Avg Best Wrst StDev ...internal... 5. gw.iv.ivenue.com 0.0% 10 2.7 2.7 2.6 2.8 0.1 6. 64.70.17.121 0.0% 10 2.8 3.8 2.8 11.5 2.7 7. hr2-v3007.la1.savvis.net 0.0% 10 2.8 22.9 2.8 203.1 63.3 8. 204.70.203.90 0.0% 10 4.0 4.3 3.8 5.6 0.5 9. cr1-pos-0-0-0-0.londonuk1.sa 0.0% 10 177.1 157.9 151.1 179.7 11.5 10. esr1-xe-7-0-0.ams.savvis.net 0.0% 10 166.5 166.4 166.3 166.5 0.1 11. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13. ixp1-xe-11-0-0-0.us-ash.eu.b 80.0% 10 597.0 595.7 594.4 597.0 1.9 14. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 15. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 16. ae-5.pat1.nez.yahoo.com 90.0% 10 546.0 546.0 546.0 546.0 0.0 17. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 # mtr 98.138.253.109 -n --report --report-cycles 15 HOST: mail.mrball.net Loss% Snt Last Avg Best Wrst StDev ...internal... 5. 208.89.136.1 0.0% 15 2.6 2.7 2.6 2.9 0.1 6. 64.70.17.121 0.0% 15 2.8 8.9 2.8 57.5 16.2 7. 64.70.11.57 0.0% 15 2.8 2.9 2.8 3.2 0.1 8. 204.70.203.90 0.0% 15 4.4 5.4 3.7 23.5 5.0 9. 204.70.192.122 0.0% 15 151.2 154.7 151.1 172.9 7.0 10. 204.70.202.2 0.0% 15 166.4 168.8 166.3 202.7 9.4 11. ??? 100.0 15 0.0 0.0 0.0 0.0 0.0 12. 166.49.208.90 80.0% 15 508.3 507.2 505.9 508.3 1.2 13. 166.49.208.59 80.0% 15 589.8 589.8 588.9 590.6 0.9 14. ??? 100.0 15 0.0 0.0 0.0 0.0 0.0 15. 216.115.96.81 93.3% 15 521.8 521.8 521.8 521.8 0.0 16. ??? 100.0 15 0.0 0.0 0.0 0.0 0.0 17. 216.115.100.3 93.3% 15 537.4 537.4 537.4 537.4 0.0 18. 98.138.144.29 91.7% 12 537.1 537.1 537.1 537.1 0.0 19. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 20. 98.138.240.28 80.0% 5 537.9 537.9 537.9 537.9 0.0 21. ??? 100.0 4 0.0 0.0 0.0 0.0 0.0 22. 98.138.253.109 66.7% 3 537.9 537.9 537.9 537.9 0.0 Traffic served by Akamai appears to be fast and stays local (i.e. tested to www.apple.com) A call in to Savvis got attached to master ticket 4828052, which is for "large packet loss". Describes the symptom, not the cause. Is there anybody who has more info? Anybody who's a Savvis customer who sees the same weird outbound routing? Or are we the only ones? Feel free to traceroute to 208.89.139.252 to try and duplicate these results. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine

2 2

Re: [VoiceOps] ITFS Term vendor question
by Jay Ashworth 18 Sep '14

18 Sep '14

---- Original Message ----- > From: "Nick Crocker" <nick.crocker(a)gmail.com> > Can someone shed some light on how you might be accomplishing this, I have > a hard time believing that customers are being told they cannot dial TF > numbers in their own country. In the US, it's always been my understanding that what we call INWATS calls are dipped *at the originating CO*, and the actual toll call across the SS7/TDM backbone goes out using either the real 10D DN of the target line, or some fake 10D that routes to the appropriate trunk group somehow at the destination end. So it's not that unusual to me that a network that is interfacing at Class 4, instead of Class 5, might be unable to originate calls to TF DNs. I admit to not being sure this is a worldwide view of the issue, as our Wikipedian friends would say, though. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

2 1

Re: Scotland ccTLD?
by Larry Sheldon 18 Sep '14

18 Sep '14

On 9/16/2014 18:57, Masataka Ohta wrote: > What will happen to ".uk" if England is left alone? > > Masataka Ohta There are still at least 3 countries left in the UK if Scotland splits. The name change is that in that event, Great Britain (.gb country-code Reserved Domain - IANA) will refer only to the land mass (which it should any way, but if often used to refer to the three kingdoms on it. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes.

7 6

Re: Book / Literature Recommendations
by Larry Sheldon 17 Sep '14

17 Sep '14

On 9/16/2014 18:01, Miles Fidelman wrote: > Scott Weeks wrote: >> >>> On Sep 16, 2014, at 10:48 AM, James Bensley <jwbensley(a)gmail.com> wrote: >>> What is the single best book you have read on >>> networking? >> ----------------------------- >> >> >> Paper is soooo 20th century. C'mon, we're a decade and >> a half into the 21st century. :-) >> >> http://www.tcpipguide.com/free/t_toc.htm >> >> scott > Experience the power of the bookbook: > https://www.youtube.com/watch?v=MOXQo7nURs0 And I will tell you that when you are in a dark wiring closet trying to figure out how to "get into" an unfamiliar piece of equipment, a flashlight and the right collection of paper is priceless, while the cold, dark screen is worthless. I think of this "paperless" idiocy every time I write "20 reams of printer paper" on the grocery list. For the first half of my life -- maybe a little less -- I did not ever do that. Thanks, G*d, I no longer by 8½ X 11 and 11 X 17 fan-fold (½ of that green-bar). -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes.

5 6

Book / Literature Recommendations
by James Bensley 17 Sep '14

17 Sep '14

Hi All, What is the single best book you have read on networking? That's a wide topic so to clarify I'm talking about service provider networking but I do enjoy all aspects really and don't want to limit my self to one area of networking. I'm often reading technical books about technology X or protocol Y but they are generally explaining a new technology to me, how it works and how to use it (and how to configure it if its a book by a vendor like Juniper or Cisco). That is usually a learning exercise though required for an upcoming project or deliverable. I haven't read many vendor neutral books recently that explained concepts, or technologies, or paradigms that I found profound, radical and extremely useful. I feel like I'm just reading networking books these days to learn a new technology for a period of time (until a project completes) then moving on to the next technology (book). Longevity of the information doesn't seem as profound as it used to; BGP design principals will stay with me for decades until we reach the need for BGP v5 or similar, learning about 8b/10b encoding was interesting but not really required for my line of work more out of hobbyist interest and serves no practical purpose as a network engineer. Cheers, James.

14 14

Re: Book / Literature Recommendations
by Scott Weeks 16 Sep '14

16 Sep '14

> On Sep 16, 2014, at 10:48 AM, James Bensley <jwbensley(a)gmail.com> wrote: > What is the single best book you have read on > networking? ----------------------------- Paper is soooo 20th century. C'mon, we're a decade and a half into the 21st century. :-) http://www.tcpipguide.com/free/t_toc.htm scott

2 1

2000::/6
by Tarko Tikan 16 Sep '14

16 Sep '14

hey, 2000::/6 with aspath 3257 3549 has appeared in global routing table. Surely we can't be only ones seeing it. Looks like someone messed up interface/route config at 3549 by omitting 4 from the prefixlen. According to https://stat.ripe.net/2000%3A%3A%2F6#tabId=routing "2000::/6 is visible by 79% of 92 IPv6 RIS full peers." -- tarko

10 16