- NANOG - lists.nanog.org

AS4788 Telecom Malaysia major route leak?
by Tore Anderson 12 Jun '15

12 Jun '15

I see tons of bogus routes show up with AS4788 in the path, and at least AS3549 is acceping them. E.g. for the RIPE NCC (193.0.0.0/21): [BGP/170] 00:20:29, MED 1000, localpref 150 AS path: 3549 4788 12859 3333 I, validation-state: valid > to 64.210.69.85 via xe-1/1/0.0 Tore

13 22

Re: AS4788 Telecom Malaysia major route leak?
by Jürgen Jaritsch 12 Jun '15

12 Jun '15

http://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/ Jürgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: jj(a)anexia.at<mailto:jj@anexia.at> Web: http://www.anexia.at<http://www.anexia.at/> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

3 2

Huge Level 3 ipv4 issues?
by David Hubbard 12 Jun '15

12 Jun '15

Experiencing packetloss all over the place (chicago, tampa, atlanta) on Level 3's network; can't even reach them from Brighthouse residential. IPv6 seems to still be working fine, but of course Brighthouse doesn't offer that lol. Anyone seeing the same? David

6 5

New AS Number Blocks allocated to the RIPE NCC
by Ingrid Wijte 12 Jun '15

12 Jun '15

-------- Forwarded Message -------- Subject: New AS Number Blocks allocated to the RIPE NCC Date: Fri, 12 Jun 2015 10:54:14 +0200 From: Ingrid Wijte <ingrid(a)ripe.net> To: address-policy-wg(a)ripe.net, routing-wg(a)ripe.net, Menog(a)menog.net, afnog(a)afnog.org, sanog(a)sanog.org, nanog(a)nanog.org, uknof(a)lists.uknof.org.uk, lacnog(a)lacnic.net, discuss(a)enog.org Dear Colleagues, The RIPE NCC has received the following AS Number Blocks from the IANA on 11 June 2015. 202240-203263 203264-204287 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC

1 0

Greenfield 464XLAT (In January)
by Nicholas Warren 12 Jun '15

12 Jun '15

Sincere apologies if this e-mail is inappropriate for this audience, We are (going to be) a startup ISP building a new network from the ground up. I was hoping I could get an opinion, or two, on how everyone feels about 464XLAT. I saw what everyone was saying about it in the 'Android doesn't support DHCPv6' discussion, but what about in the wireline side of things? The main reason we are even considering 464XLAT as opposed to dual-stack (the latter is, in my ignorant opinion, the better option.) is the fear of IPv4 depletion that we think might hit ARIN between now and the start of next year; causing us to pay a premium for IPv4 in the gray market. So I guess the real question here would be: is our fear real, or is it just bug on the wall? If our fear is real, what should we implement so that our users can still get to the v4 internet, are we even thinking soberly by suggesting 464XLAT? Thanks, - Nich

8 13

Re: Android (lack of) support for DHCPv6
by Brandon Butterworth 12 Jun '15

12 Jun '15

> > On the other hand, if it becomes common and acceptable to use DHCPv6 to > > provide a single address only > > I encourage my competitor universities to design their networks that way. :) I'd be fine with android doing DHCPv6 plus refusing to use v6 if only one address is available. Covers the stated objective and lets those that will do the claimed right thing go ahead with v6 roll out. brandon

1 0

BGP in the Washngton Post
by William Herrin 11 Jun '15

11 Jun '15

Interesting story about BGP and security in the Washington Post today: http://www.washingtonpost.com/sf/business/2015/05/31/net-of-insecurity-part… -Bill -- William Herrin ................ herrin(a)dirtside.com bill(a)herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

21 41

Re: Android (lack of) support for DHCPv6
by Ted Hardie 11 Jun '15

11 Jun '15

On Wed, Jun 10, 2015 at 11:51 AM, Matthew Huff <mhuff(a)ox.com> wrote: > +1 > > One IP per device will almost most likely be the preference and > implementation in corporate/enterprise deployments. Too much procedure, > regulation and other roadblocks prevent any other solution. > > Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management, > custom software, and other roadblocks will certainly stall if not stop IPv6 > deployments in enterprises if there isn’t at least the choice of static, > single IPv6 addresses per device. SLAAC will probably be a complete > non-starter in many corporate environments. It is in ours. The more > ideologues preach about restoring peer-to-peer connectivity, dynamic IPs, > privacy addresses, etc… the less penetration IPv6 will happen in corporate > networks. > > > So, the critical piece of what you assert above appears to be "static", not "single". If a local address management system is always configured to hand out the same /N to the same device, there doesn't seem to be a requirement in the above that N=1. Lorenzo has detailed why N=1 doesn't work for devices that need to use xlat or which might want to tether other devices; he's volunteered to work with folks on a document and to write code for the case where a device successfully gets a useful value of N>1. Can you help me understand why that doesn't work for you? On the related topic of privacy addresses, I believe we should all be ready for increasing variability in MAC address emitted by devices, and that if you are intending to use MAC auth to assign that /N, you may now be or will soon be surprised. In addition to the work Apple has done and which can be done with Android, see the IEEE work here: http://www.ieee802.org/PrivRecsg/ regards, Ted

8 16

eBay is looking for network heavies...
by John Fraizer 11 Jun '15

11 Jun '15

Hello All, eBay is looking for folks to join our Site Network Engineering team. eBay Site Network Engineering is responsible for the eBay SITE network from ToR to Peering Edge. You won't be bored. You will be challenged. You will have fun! This position is located in San Jose, California @ eBay HQ although exception may be made for extremely well qualified candidates. *Qualifications:* - 7+ years of experience in network design and implementation - 7+ years working at the highest level of technical escalation - Expert level multi-vendor experience in routing & switching with Arista, Cisco, Juniper, Nexus platforms - Expert level understanding of IPv4 & IPv6. Bonus points if you can tell me about IPv8. (The old guard will get that joke.) - Expert level BGP and OSPF - Understanding of multicast technologies such as PIM-SM and PIM-BiDir - Understanding of QoS and implementation strategies - Experience with L2 technologies such as MLAG and VPC - Experience with cloud architectures and network automation - Experience with SDN technologies such as VXLAN, NVGRE and Open vSwitch - Expert level troubleshooting skills - Functional knowledge of and comfort working in *nix environments - Ability to script in Bash, Perl, or other relevant languages. (Bonus for Python) - Excellent communications and documentation skills Head of line for CCIE / JNCIE but knowledge and experience trumps a piece of paper every time! BSCS or other 4-year degree desired - may be substituted with relevant work experience Translation of the above: Are you considered an expert by your industry peers? We know your family thinks you're a genius. Do your peers in the networking community agree? Do you want work on the bleeding edge of technology, playing with the biggest, baddest and bestest toys? Are you a team player who can also work alone providing creative solutions to complex problems using your "out of the box" thinking? Are you tired of being the "smartest guy in the room" when you're at work? Well then, I've got the job you're looking for! The above qualifications are the "wish list". That should give you a feel of whether or not you're qualified for this position though. You know your own skill set better than anyone else. Just be advised: Please don't be a "buzzword bandit" on your CV. If you list a skill or experience, its fair game to ask you about these - in depth - during your phone screen and any subsequent in-person interviews. Interested and Qualified candidates, please forward your CVs to jfraizer at ebay dot com. eBay, Inc is an Equal Opportunity Employer -- John Fraizer MTS2 - eBay Site Network Engineering

41 60

Looking for information on IGP choices in dual-stack networks
by Victor Kuarsingh 11 Jun '15

11 Jun '15

Nanog Folks: Philip Matthews and I are co-authors on an active draft within the IETF related to IPv6 routing design choices. To ensure we are gathering sufficient data we are looking for an expanded set of input from operator forums as well (vs. just the v6ops IETF list). The draft is found here -(https://tools.ietf.org/html/draft-ietf-v6ops-design-choices). We are looking for information on the IGP combinations people are running in their dual-stack networks. We are gathering this information so we can document in our draft which IGP choices are known to work well (i.e., people actually run this combination in production networks without issues). The draft will not name names, but just discuss things in aggregate: for example, "there are 3 large and 2 small production networks that run OSPF for IPv4 and IS-IS for IPv6, thus that combination is judged to work well". If you have a production dual-stack network, then we would like to know which IGP you use to route IPv4 and which you use to route IPv6. We would also like to know roughly how many routers are running this combination. Feel free to share any successes or concerns with the combination as well. We are looking particularly at combinations of the following IGPs: IS-IS, OSPFv2, OSPFv3, EIGRP. If you run something else (RIP?) then we would also like to hear about this, though we will likely document these differently. [We suspect you run RIP/RIPng only at the edge for special situations, but feel free to correct us]. And if you have one of those modern networks that carries dual-stack customer traffic in a L3VPN or similar and thus don’t need a dual-stacked core, then please email us and brag ... If you are on multiple lists at RIPE, NANOG or the IETF, we appologize for any redundant emails you may get (we are just attempting to reach the widest audience possible). Philip Matthews Victor Kuarsingh

12 24