Re: TLD .so Partial Outage?

> I'm observing a near global outage of DNS services from d.nic.so. This > appears to be an AfriNIC anycast DNS service. >From my vantage point in Oslo, Norway, d.nic.so works just fine using IPv6 but not IPv4. Steinar Haug, Nethelp consulting, sth...@nethelp.no ---

Re: Cost-effectivenesss of highly-accurate clocks for NTP

> I was just thing about this WAN jitter issue myself. I'm wondering how many > folks put NTP traffic in priority queues? At least for devices in your > managed IP ranges. Seems like that would improve jitter. Would like to > hear about others doing this successfully prior to suggesting it for

Re: Death of the Internet, Film at 11

>From Dyn's statement, http://hub.dyn.com/static/hub.dyn.com/dyn-blog/dyn-statement-on-10-21-2016-ddos-attack.html we have "After restoring service, Dyn experienced a second wave of attacks just before noon ET. This second wave was more global in nature (i.e. not limited to our East Coast POPs),

Re: OSPF vs ISIS - Which do you prefer & why?

> I think you misunderstood his point: it's not the knobs, but the > vendors. Generally, when you're trying to integrate random crap into an > otherwise well-structured network, you'll find OSPF available, but very > rarely IS-IS. We never really want to talk IS-IS with random crap - in that c

Re: OSPF vs ISIS - Which do you prefer & why?

> Cisco is the only "real" IS-IS vendor. > > Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the > whitebox hardware or real SDN capable solutions, you're going to be on OSPF. Maybe you need to tell us what the other companies aren't getting? We're using IS-IS on (mostly) Junip

Re: [SPAM] Re: OSPF vs ISIS - Which do you prefer & why?

> > I think people were looking for specifics about the implementation > > deficits in the junos version which caused enough problems to justify > > the term "not getting it"? > > The only IS-IS implementation we struggle with is Quagga. > > For that, we run OSPFv2 and OSPFv3 on Quagga and redist

Re: AS205869, AS57166: Featured Hijacker of the Month, July, 2018

> I'd greatly appreciate it if readers of this post would help me to to confirm > that the non-routing of the above block is both universal and complete... > as it is, at least, from where I am sitting... but at this point I have > nothing and nobody to rail against. (Or so I thought! But while w

Re: AS205869, AS57166: Featured Hijacker of the Month, July, 2018

>> Dead for me via: >> HE >> NTT >> COX > > Likewise here, via a bunch of other transits. I saw them from HE this morning > but they appear to have been withdrawn now. Also gone from HE from my vantage point in Oslo, Norway. Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms,Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms

> Out of curiosity, which operating systems put anything useful (for use > in ECMP) into the flow label of IPv6 packets? At the moment, I only > have access to CentOS 6 and CentOS 7 machines, and both of them set the > flow label to zero for all traffic. FreeBSD 11.2-STABLE. Steinar Haug, Nethel

Re: Long AS Path

> Just wondering if anyone else saw this yesterday afternoon ? > > Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH=3D AS_SEQ(2= > ) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 234= > 56 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 2345

Re: Long AS Path

> > I see no valid reason for such long AS paths. Time to update filters > > here. I'm tempted to set the cutoff at 30 - can anybody see a good > > reason to permit longer AS paths? > > Well, as I mentioned in my Net Neutrality filing to the FCC, a TTL of 30 > is OK for intra-planet routing, but w

Re: IPv6 Loopback/Point-to-Point address allocation

> > Null-routing may not be sufficient, if the edge/border router has a > > route to that /128; the (forwardable) /128 entry will win from the > > blackholed /64 FIB entry since it is more-specific. > > just thought about it a bit. > As mentioned (in other post) I was thinking of a specific use ca

Re: IPv6 migration steps for mid-scale isp

> Thank you all for your Ideas. AFAIK one of the main decisions for IPv6 > transition and deployment is the choice of IPv6 IGP. I read somewhere > that its a good practice to use different IGP protocol for IPv6 and > IPv4. For example if IGP for IPv4 is IS-IS then use OSPFv3 for IPv6. > any comment

Re: AS PATH limits

> If you're on cogent, since 22:30 UTC yesterday or so this has been happening > (or happened). Still happening here. I count 562 prepends (563 * 262197) in the advertisement we receive from Cogent. I see no good reason why we should accept that many prepends. Steinar Haug, Nethelp consulting, st

Re: Long BGP AS paths

> Could you list which prefix(es) you saw were being announced with these > long AS paths? 186.177.184.0/23 - still being announced with 533 occurrences of 262197 in the AS path. Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: ccTLDs - Become a Registrar

> > I am hoping to find what other TLD operators may have similar requirements. > > > > .br also has such requirements. OpenSRS reference chart has a good hint of > which ccTLDs have such requirements: > http://bit.ly/OpenSRS_TLD_Reference_Chart It might be advisable to verify the data. For insta

Re: Waste will kill ipv6 too

> > My wild guess is if we'd just waited a little bit longer to formalize > > IPng we'd've more seriously considered variable length addressing with > > a byte indicating how many octets in the address even if only 2 > > lengths were immediately implemented (4 and 16.) > > Actually, that got heave

Re: IPv6 Unique Local Addresses

> > ULA at inside and 1:1 to operator address in the edge is what I've > > been recommending to my enterprise customers since we started to offer > > IPv6 commercially. Fits their existing processes and protects me from > > creating tainted unusable addresses. > > Oh, please. NAT all over again? T

Re: Yet another Quadruple DNS?

> > This also ignores the shift if every house in the world did its own > > recursion. TLD servers and auth servers all over the world would > > have to massively up their capacity to cope. > > With my TLD operator hat, I tend to say it is not a problem, we > already have a lot of extra capacity,

Re: Definitive Guide to IPv6 adoption

> > don't decide without thinking it through that you're assigning a > > customer a /64 a /60 a /56 or even /48. this should be defensible as > > part of a business plan, otherwise what's the point? > > > A /48 is defensible. It's the architecturally intended end-site configuration, > it is allowe

Re: RINA - scott whaps at the nanog hornets nest :-)

> Completely agree with you on that point. I'd love to see Equinix, AMSIX, > LINX, > DECIX, and the rest of the large exchange points put out statements indicating > their ability to transparently support jumbo frames through their > fabrics, or at > least indicate a roadmap and a timeline to whe

Re: RINA - scott whaps at the nanog hornets nest :-)

> RFC 4821 PMTUD is that "negotiation" that is "lacking". It is there. > It is deployed. It actually works. No more relying on someone sending > the ICMP packets through in order for PMTUD to work! For some value of "works". There are way too many places filtering ICMP for PMTUD to work consist

Re: RINA - scott whaps at the nanog hornets nest :-)

> > > RFC 4821 PMTUD is that "negotiation" that is "lacking". It is there. > > > It is deployed. It actually works. No more relying on someone sending > > > the ICMP packets through in order for PMTUD to work! > > > > For some value of "works". There are way too many places filtering > > ICMP f

Re: IPv6

> > That's what I'm hearing. Cogent refuses to peer with HE via IPv6. > > So cogent IPv6 Customers currently can not hit things at HE. And they can't > > do anything about it. Besides 6to4 tunneling and BGP peering with HE (or > > native, If they can). > > A few weeks ago I compared what cogent

Re: IPv6

> > Yahoo just dropped in on the IPv6 content party > > http://ipv6.weather.yahoo.com/ > > I just bookmarked it. Well done Yahoos. > > Well, > > ipv6.ycpi.ops.yahoo.net has IPv6 address 2a00:1288:f006:1fe::1000 > ipv6.ycpi.ops.yahoo.net has IPv6 address 2001:4998:f00b:1fe::1000 > ipv6.ycpi.ops.y

Re: AS6453 (Tata/Teleglobe/Globe Internet?) <-> various US ISP Outage?

> Anyone else seeing problems reaching AT&T/XO possibly others from > AS6453 in Europe? Seems to work okay from Norway: traceroute to 140.239.191.10 (140.239.191.10), 64 hops max, 40 byte packets 1 ge0-0-0-3000.br1.fn3.no.catchbone.net (193.75.4.1) 0.165 ms 0.179 ms 0.235 ms 2 if-6-0-0.co

Re: Network management software with high detailed traffic report

> Does any one know the NMS (network management software) which can do the > fallowing: > > 1. Monitor on Cisco Routers/Switches interface utilization every 5-10 > seconds and send e-mail alarm when utilization low or high of predefined > thresholds. > 2. Collect net-flow statistics (at least src/

Re: Are you ready for RPKI in your BGP?

> I guess router vendors need to start supporting > and I'd > imagine that'll take 6-12 months after it's even feature commit, so seeing > deployment of this in 2011 seems highly doubtful? > > It's one of those features I doubt would

Re: Alleged backdoor in OpenBSD's IPSEC implementation.

> > More to the point, I think it wouldn't be an NDA, but a security > > classification on the knowledge of the backdoors, and probably one not > > subject to automatic downgrading. > > Please pardon my ignorance on the matter as I am not involved in any way > with Open Source development, but it

Re: NIST IPv6 document

> All the same, beware of the anycast addresses if you want to use a smaller > block for point-to-point and for LANs, you break stateless autoconfig and > very likely terminally confuse DHCPv6 if your prefix length isn't /64. Breaking stateless autoconfig such that it *cannot* ever work, on my r

Re: IPv6 - real vs theoretical problems

> Are there any large transit networks doing /64 on point-to-point > networks to BGP customers? Who are they? What steps have they taken > to eliminate problems, if any? Our Global Crossing IPv6 transit is on a /64 Ethernet point-to-point. Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: Using IPv6 with prefixes shorter than a /64 on a LAN

> > IPv6 is classless; routers cannot blindly make that assumption for > > "performance optimization". > > > Blindly, no. However, it's not impractical to implement fast path switching > that > handles things on /64s and push anything that requires something else > to the slow path. Any vendor

Re: [arin-announce] ARIN Resource Certification Update

> > - Hosted solutions offer a low barrier entry to smaller organizations > > who simply cannot develop their own PKI infrastructure. This is the > > case where they also lack the organizational skills to properly manage > > the keys themselves, so, in most cases at least, they are *better off* > >

Re: random dns queries with random sources

> Premature send - I meant to add 'Or against the authoritative servers for > 5kkx.com?' > > We've been seeing a spate of reflected (not amplified) DNS attacks against > various authoritative servers in Europe for the past week or so, bounced > through some type of consumer DSL broadband CPE wi

Re: random dns queries with random sources

> It has been ongoing for a week or so (but not constant). The domain > names have a pattern but are comprised of components that appear to be > randomly generated. The source IP addresses for the queries appear to be > non duplicated and randomly generated. > > query logs are available for uni

Re: Filter NTP traffic by packet size?

> The business model seems clearer when offering filtering as a service > to downstream networks, the effects are narrowly scoped, and members > have control over the traffic they accept from the exchange, e.g. I > don't want to accept NTP traffic to any destination that exceeds > 1Gbit/s, or is so

Re: IPv6 Security

> > No, it is LESS robust, because the client identifier changes when the > > SOFTWARE changes. Around here, software changes MUCH more often than > > hardware. Heck, even a dual-boot scenario breaks the client > > identifier stability. Worse yet, DHCPv6 has created a scenario where > > a client

Re: IPv6 Security

> > DHCPv6 as defined in RFC 3315 does not offer client MAC address at all > > (thus making the job more difficult for a number of organizations). > > Yes it does… > > What do you think “Link Layer Address” (RFC 3315, Section 9.1 Type 3) > is? From RFC-3315 Section 9.4, it seems pretty clear that

Re: US patent 5473599

> So, then the only problem, perhaps, is that noone has apparently > bothered to explicitly document that both VRRP and CARP use > 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the > "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID > (VHID)" in CARP, providing a

Re: Hurricane Electric packet loss

> We$,1ry(Bve been customers of Hurricane Electric for a number of years now > and always been happy with their service. > > In recent months packet loss on some of their major routes has become a very > common (every few days) occurrence. Without knowledge of their network I am > unsure what

Re: The stupidity of trying to "fix" DHCPv6

> > Ethernet is not designed for huge LANs. If you want that you need > > to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/ > > Hm: > > "Our object is to design a communication system which can grow smoothly to > accommodate several buildings full of personal computers and the

Re: The stupidity of trying to "fix" DHCPv6

> "Ethernet doesn't scale because of large amounts of broadcast traffic." > > We started to introduce multicast, and multicast-aware switches in > IPv4; in IPv6 there is no broadcast traffic. We won't be able to > scale networks up until we can turn off IPv4, In other words, probably not for ano

Re: The stupidity of trying to "fix" DHCPv6

> Are you not using managed switches? Certainly. > It takes me about 1 second to find exactly which device and which port > a device is connected to. Once you know that; you have a pretty nice > collection of statistics and log messages that usually tell you > exactly what is wrong. Here is whe

Re: MX 80 advantages and shortcomings

> Can anyone enlighten me on the pros and cons of MX 80 platform There's been quite a bit of discussion about the MX80 on the juniper-nsp list, and I recommend asking on that list instead (if you don't find what you already need in the list archives). As a general rule, people are more likely to

Re: dynamic or static IPv6 prefixes to residential customers

> 3) I think people do some of both. I think that if people can get static for > the > same price, they will choose static over dynamic. I think that some > will even choose to use their dynamic to run tunnels where they > can get static. You can get free static tunnels for IPv6

Re: dynamic or static IPv6 prefixes to residential customers

> > Experience from IPv4 suggests otherwise. We (as an ISP) normally hand > > out dynamic IPv4 addresses to residential customers, and static IPv4 > > addresses to business customers. > > > > - We have plenty of business customers who *want* dynamic addresses, > > even if static is available as a

Re: dynamic or static IPv6 prefixes to residential customers

> > - Dynamic address: Customer connects PC (defaults to DHCP) or router/ > > firewall with DHCP for the WAN interface plus NAT for the LAN side. > > Necessary configuration: Small to none. > > DHCP doesn't imply dynamic address. It implies customer doesn't have to > configure an address him/he

Re: IPv6 end user addressing

> > And your average home user, whose WiFi network is an open network named > > "linksys" is going to do that how? > > Because the routers that come on pantries and refrigerators will probably be > made by people smarter than the folks at Linksys? One could argue that routing and access control i

Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates

> To pop up the stack a bit it's the fact that an organization willing to > behave in that fashion was in my list of CA certs in the first place. > Yes they're blackballed now, better late than never I suppose. What does > that say about the potential for other CAs to behave in such a fashion? I'd

Re: ouch..

> Slander means falsehood. Cisco tells lies ? If you believe any vendors out there are white knights (telling no lies) you may need a reality check. Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: Performance Issues - PTR Records

> > The practice of filling out the reverse zone with fake PTR record > > started before there was wide spread support for UPDATE/DNS. There > > isn't any need for this to be done anymore. Machines are capable > > of adding records for themselves. > > How do I setup this for DHCPv6-PD? Say, I d

Re: Recent DNS attacks from China?

> > I am wondering if anyone else is seeing a sudden increase in DNS attacks > > emanating from chinese IP addresses? Over the past 24 hours we've seen a > > sudden rash of chinese IPs attacking our DNS servers in the order of 5 to 10 > > million PPS for periods of 5 to 10 mins, repeated every 20

Re: OOB core router connectivity wish list

> I don't think you can get ethernet and transport out-of-the-area in > some places at a reasonable cost, so having serial-console I think is > still a requirement. TDM is disappearing quickly in at least some parts of the world. We may not be quite there yet, but I think it's entirely reasonable

Re: Line cut in Mediterranean?

> Getting reports from a third party vendor that there's been a line cut in the > Mediterranean that is affecting some Internet traffic. Anyone have any > details? See the outages list: https://puck.nether.net/pipermail/outages/2013-March/005386.html Steinar Haug, Nethelp consulting, sth...@n

Re: Any tools to help network security

> We discover there are so many (source) ip not belonging to our network > to go to outside. > > We can block it but don't know how to locate the source. > > Any tools can be easily found out. http://lmgtfy.com/?q=unicast+rpf Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: subnet prefix length > 64 breaks IPv6?

> I am not sure if this is the reason as this only applies to the link > local IP address. One could still assign a global IPv6 address. So, > why does basic IPv6 (ND process, etc) break if i use a netmask of say > /120? As long as you assign addresses statically, IPv6 works just fine with a netma

Re: subnet prefix length > 64 breaks IPv6?

> > prefixes on the same link.  Choosing to make use of a 120-bit prefix > > (for example) will do nothing to protect against a rogue RA announcing > > its own 64-bit prefix with the A flag set. > > > > I could not find any "A flag" in the RA. Am i missing something? It's part of the Prefix Infor

Re: subnet prefix length > 64 breaks IPv6?

> On the other hand there's also the rule that IPv6 is classless and therefore > routing on any prefix length must be supported, although for some > implementations forwarding based on > /64 is somewhat less efficient. Can you please name names for the "somewhat less efficient" part? I've seen t

Re: subnet prefix length > 64 breaks IPv6?

> Most vendors have a TCAM that by default does IPv6 routing for netmasks <=64. > > They have a separate TCAM (which is usually limited in size) that does > routing for masks >64 and <=128. Please provide references. I haven't seen any documentation of such an architecture myself. > TCAMs are ex

Re: subnet prefix length > 64 breaks IPv6?

> > Can you please name names for the "somewhat less efficient" part? I've > > seen this and similar claims several times, but the lack of specific > > information is rather astounding. > > Well, I do know if you look at the specs for most newer L3 switches, > they will often say something like "m

Re: subnet prefix length > 64 breaks IPv6?

> If every route is nicely split at the 64-bit boundary, then it saves a > step in matching the prefix. Admittedly a very inexpensive step. My point here is that IPv6 is still defined as "longest prefix match", so unless you *know* that all prefixes are <= 64 bits, you still need the longer match

Re: subnet prefix length > 64 breaks IPv6?

> IPv6 CEF appears to be functioning normally for prefixes longer than > 64-bit on my 720(s). > > I'm not seeing evidence of unexpected punting. > > The CPU utilization of the software process that would handle IPv6 > being punted to software, "IPv6 Input", is at a steady %0.00 average > (with sp

Re: subnet prefix length > 64 breaks IPv6?

> "Note: An IPv4 route requires only one TCAM entry. Because of the > hardware compression scheme used for IPv6, an IPv6 route can take > more than one TCAM entry, reducing the number of entries forwarded > in hardware. For example, for IPv6 directly connected IP addresses, > the d

Re: Common operational misconceptions

> If you want to know if your resolver talks IPv6 to the world and > supports 4096 EDNS UDP messages the following query will tell you. > > dig edns-v6-ok.isc.org txt > > Similarly for IPv4. > > dig edns-v4-ok.isc.org txt Both PowerDNS recursor 3.3 and Nominum CNS 3.

Re: Attack on the DNS ?

> Anyone seen signs of this attack actually occurring ? > > http://www.nytimes.com/2012/03/31/technology/with-advance-warning-bracing-for-attack-on-internet-by-anonymous.html?_r=1 >From my vantage point in Oslo, Norway, there is no sign of any attack occurring. Steinar Haug, Nethelp consulting,

Re: Attack on the DNS ?

> We already have this type of attack in Bucharest/Romania since last > Friday. The targets where IP's of some local webhosters, but at one > moment we event saw IP's from Go Daddy. > Tcpdump will show something like: > 11:10:41.447079 IP target > open_resolver_ip.53: 80+ [1au] ANY? isc.org. > (

Re: Cheap Juniper Gear for Lab

> Anyway, not the best devices for an edge router that is for sure. > Which is too bad... for very small DC edge applications, the J6350 > was a pretty cool router in earlier versions of JunOS that didn't > decide to re-engineer your network and transit for you. We have 3 J2320s in the lab, all r

Re: [IPv6] Monitoring BGP IPv6 Sesions

> There's new mib support in new IOS's and ASR9k stuffs but there's > still not feature parity with IPv4. It seems the current prevailing > winds indicate less support for SNMP and more for NETCONF. So maybe > we should all get cozy with XML rather than OIDs... All I've seen of Netconf so far

Re: HE.net BGP origin attribute rewriting

> I disagree. Origin is tremendously useful as a multi-AS weighting > tool, and isn't the blunt hammer that AS_PATH is. If you think of AS_PATH as a blunt hammer, how would you describe localpref? We use AS_PATH in many cases *precisely* because we don't consider it to be a blunt hammer... Stei

Re: DDoS using port 0 and 53 (DNS)

> The port number of the Layer 4 connection cannot be determined without > executing IP fragment reassembly in that case.Routers normally > reassemble fragments they receive, if possible. No, routers normally do *not* reassemble fragments. This is typically done by hosts and firewalls. Steina

Re: Does anyone use anycast DHCP service?

> I think it would be far more reliable to simply have two independent > DHCP servers with mutually exclusive address ranges, and have one > system be secondary and "delay" its responses by 2s so it always > "loses" when the primary is up and running well. > > Yes, you lose the ability for clients

Re: HSRP vs VRRP for IPv6 on IOS-XE - rekindling an old flame

> Yeah I see the disconnect. I'm assuming that what I see is what I get. > Which means I'm going to stick with HSRP. If our AS team gives me any > good feedback that I can share I will do so. Thanks Nick. > > XE: v4: HSRPv1, HSRPv2, VRRPv6: HSRPv2 Not particularly relevant to th

Re: MTU issues s0.wp.com

> Is anyone else experiencing similar issues? Not from here (AS 2116, Norway). No problem getting up the web page, tcpdump shows MSS 1440. > My traceroute shows they are employing a CDN for s0.wp.com, so not > everyone might be affected. > > 7 asd2-rou-1022.NL.eurorings.net (2001:680:0:800f:

Re: Whats so difficult about ISSU

> > as to whether ios/xe is rtc, you may want to see my preso at the last > > nanog. > > NANOG56? I only found RPKI Propagation by you. Direct URL would be > appreciated. Look towards the end of the presentation and you'll find run to completion... Steinar Haug, Nethelp consulting, sth...@nethel

Re: Big day for IPv6 - 1% native penetration

> > Again, where're the compelling IPv6-only content/apps/services? > > > > To answer your rhetorical question, http://www.kame.net/ has a dancing > kame. To my knowledge, that's the most compelling IPv6-only content. Don't forget http://loopsofzen.co.uk/ - that's definitely the most compelling

Re: Interesting problems with using IPv6

> There are decades of mailing lists archives at nanog and others that have > the same thing -- 1) stressed out ops guy 2) buggy code (tac says need to > load latest code as first step) 3) L2 mess -- most of those examples of > epic failure are ipv4 related, but many are just ethernet fails. > >

Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO

> > 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.

Re: Why is .gov only for US government agencies?

> Wondering if some of the long-time list members > can shed some light on the question--why is the > .gov top level domain only for use by US > government agencies? Where do other world > powers put their government agency domains? > > With the exception of the cctlds, shouldn't the > top-level

Re: BGP Security Research Question

> In real life people use - bgp ttl security, md5 passwords, control plane > protection of 179 port, inbound/outbound routes filters. So far this has > been enough. These mechanisms do little or nothing to protect against unauthorized origination of routing information. There are plenty of example

Re: BGP Security Research Question

> Let me disagree - Pakistan Youtube was possible only because their uplink > provider did NOT implement inbound route filters . As always the weakest > link is human factor - and no super-duper newest technology is ever to help > here . Agreed, the uplink absolutely should have implemented prefix

Re: PMTUD for IPv4 Multicast - How?

> > > At first, I thought this was a bug, but then learned that RFCs 1112, 1122 > > > and 1812 all specify that ICMP unreachables not be sent in response to > > > multicast packets. > > > > > I'm struggling to grok the rationale behind not sending unreachables in > > > response to multicast packets

Re: /27 the new /24

> Keep in mind that IPv6 has IPSec VPN built into the protocol. It doesn't need > to be in the router. > > Unlike IPv4, where the IPSec VPN protocol is an add-on, optional service, > with IPv6 it's built into every device, because IPsec is a mandatory > component for IPv6, and therefore, the I

Re: IGP choice

> > The differences between the two protocols are so small, that people > > really grasp at straws when 'proving' that one is better over the > > other. 'IS-IS doesn't work over IP, so its more secure'. 'IS-IS uses > > TLVs so new features are quicker to implement'. While these may be > > vaguely v

Re: DHCPv6 PD & Routing Questions

> > The DHCP relay could also have injected routes but that is a second > > class solution. > > DHCP relays *are* second class solutions :) Unfortunately they cannot > always be avoided in the semi-L2-environments like ISP access networks > often are. Each to his own, I guess. Some of us are usi

Re: IX ARP Timeout

> So I'm looking at the policies, recommended configurations, etc. of other > IXes. We try to model a lot of ourselves on what the Europeans do (even if we > come up short in some areas). I was reading through the AMS-IX guide. > > https://ams-ix.net/technical/specifications-descriptions/config

Re: sFlow vs netFlow/IPFIX

> > That's interesting, given that most larger routers don't support 1:1. > > I find that strange, because if you're doing in in HW, doing hash > lookup for flow and adding packets and bytes to the counter is cheap. > It's expensive having lot of those flows, but incrementing their > packet and by

Re: Current state / use of OSPF-TE

> What is the current state/use of OSPF-TE? > > Something you don't hear about much, for sure. Is this something that > wasn't designed well, supported well, or was it just superseded by label > based switching by the vast Telco market? I assume you mean RFC 3630 "Traffic Engineering (TE) Exten

Re: subrate SFP?

> I actually emailed RAD, MethodE and Avago yesterday and pitched the idea. > > MiTOP is my exact justification why it should technically be feasible. > > I guess it would be easier to pitch, if there would be commitment to buy, > but I don't personally need many units, just 1-2 here and there.

Re: common method to count traffic volume on IX

> But isn't this all just neo-colonialism? Establish a market in the colony, > but ensure through restrictive trade practices that all trade routes lead > back via the mother country. > > Or can I buy myself connectivity to AMS-IX Amsterdam when i'm present at the > LINX Harare exchange? Ther

Re: Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond

>> Using a 1/10th of a second interval is rather anti-social. >> I know we rate-limit ICMP traffic down, and such a >> short interval would be detected as attack traffic, >> and treated as such. ... > For what it is worth, I used to think the same, until I saw several > providers themselves sugges

Re: NSA able to compromise Cisco, Juniper, Huawei switches

> I think there needs to be some clarification on how these tools get used, > how often they're used, and if they're ever cleaned up when no longer part > of an active operation. Of course we'll never get that. Highly unlikely, I'd say. > The amount of apologists with the attitude "this isn't a

Re: NSA able to compromise Cisco, Juniper, Huawei switches

> The best response I've seen to all this hype and I completely agree with > Scott: > > "Do ya think that you wouldn't also notice a drastic increase in outbound > traffic to begin with? It's fun to watch all the hype and things like > that, but to truly sit down and think about what it would act

Re: Experiences with IPv6 and Routing Efficiency

> Was just trying to get more info from large networks about whether how some > of the things that make theoretical logical sense actually work out in > practice that way e.g. whether fixed header size and the fewer headers > required to decode to read an IPv6 packet (with respect to IPv4) really m

Re: interop show network

> The suggestion was to run a "v6 only network". Does anyone on the NANOG > list believe that v6 is at all ready to be run without any v4 > underpinnings and provide a real service to a customer base? If you're an MPLS provider (as we are), the lack of IPv6 LDP is a major showstopper. Steinar

Re: Rate of growth on IPv6 not fast enough?

> There is also an aspect of this transition I don't think we've seen > before (in networking). A large percentage of end users are on > technologies (cable modem, dsl, even dial up) who's configuration > is entirely driven out of a provisioning database. > > Once the backbone is rolled out, the

Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

> What ISP would put a 'lifetime' on your ipv6 prefix? That seems insane > to me... they should give you a /48 and be done with it. Even the free > tunnel brokers do that. > > But then I never understood dynamic ipv4 either Dynamic IPv4 isn't too difficult to understand. There are two main

Re:

> > - Dynamic addresses is a way to differentiate residential customers > > (who pay less) from business customers (who pay more). > > > Which is both specious and obnoxious. It is a business choice, which you may or may not agree with. > Given a choice between a provider which does this and one

Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

> > I was hoping that wasn't going to be your answer. So do you expect > > every residential customer to get a PI from an RIR? > > No, won't be necessary. Typical leases on v4 are extremely stable. I > see no reason why they should be less so -- bar implementation hickups > -- in v6. My "dynamic"

Re: Dial Concentrators - TNT / APX8000 R.I.P.

> I've heard of some LECs starting to mull dropping frame relay as a > supported service as well... The provider I work for stopped selling Frame Relay four years ago. However, we didn't throw out the last Nortel Passport switches until about one year ago. Steinar Haug, Nethelp consulting, sth..

Re: Broadband initiatives - impact to your network?

> > you are comparing LAN to WAN, never a bright idea > > Even ATM years ago blurred that arbitrary line. > > Why does there even need to be a line between local and wide in > terms of networking? As far as IP is concerned, there is no > difference. Even as far as Ethernet is concerned, there i

  1   2   >