Re: Production-scale NAT64
On 26 August 2015 at 00:55, Mark Tinka wrote: > > On 20/Aug/15 15:44, Jawaid Shell2 wrote: > >> Who out there is using production-scale NAT64? What solution are you >> using? > > NAT64/DNS64 on Cisco ASR1006's distributed across the network. We're doing NAT64/DNS64 with Cisco ASR1002s, although it's for a IPv6-only server network, not for user eyeballs. The biggest downside has been the lack of SNMP (or similar) support for monitoring the NAT64 traffic and pool usage, at least on the IOS XE versions we're running. -Tom
Re: he.net down?
On 04/10/2011, at 10:08 AM, Brandon Kim wrote: > Since we're on the topic of DoS. What best practice actions can be taken > AFTER such an attack? Notifying NANOG/*NOG lists? ;)
SP / Enterprise design (dis)similarities
Hi all, Looking for some advice or experience in a small enterprise / hosting provider context. There's plenty of BCP information around for SPs in the network design realm, and I'm curious how much of this applies to enterprises too. Commonly advised items like: * pull-up statics created on core devices, not network border devices * using iBGP to carry customer prefixes, not an IGP * announcing defaults over iBGP or IGP In some cases I imagine it may be simpler to have all BGP finish at the network border devices and not have to worry about running both IGP and iBGP sessions inwards to the core and/or aggregation devices. I understand the limitations of putting our Internet prefixes in an IGP, but for a hosting provider style network where everything is ethernet connected and within data centres there's much less route flapping to deal with (there's no bouncing DSL lines, for example). In the case that there is both iBGP and IGP running internally, is there any reason to choose one or the other to originate a default route to our aggregation/access layers? At some point I imagine it's going to be redistributed into the IGP (or re-originated in the IGP), so would think it would be best to just always run the default in the IGP to keep things consistent. Finally - are there any reasons to avoid running next-hop-self on ibgp sessions? The upside is we get to avoid distributing all of our transit/peer upstream point to point links into the rest of the network. Again, I understand this may be undesirable from a SP perspective, but when our 'clients' are all a bunch of internal servers it makes sense to keep iBGP/IGP as clean as possible... Thanks, Tom
Re: Performance Issues - PTR Records
On 05/11/2011, at 1:14 PM, Paul Ebersman wrote: > tim> If PTR exists in zone file, serve it. Else, synthesize generic > tim> reverse. Jobsagoodun. > > If all we're doing is lying with some generic answer that we hack our > server to produce, why are we bothering? Because some applications rely on it working (for some definition of "working"). > My contention is that (at least for end hosts), PTR records are mostly > pointless and just overhead for DNS servers. If you haven't set up PTR records for your end hosts, realistically you're going to be serving NXDOMAINs for them anyway, so there's not really any overhead introduced by supplying something generic instead... Tom
Re: Performance Issues - PTR Records
On 07/11/2011, at 12:46 PM, Robert Bonomi wrote:
>> OK.. let's say you're a DSL provider. Are you going to have your
>> DHCP server populating the forward and reverse DNS? With what, the
>> account holder's name?somename.example.com ?
>
> I'll suggest that (a) IF the addresses do migrate among different customers
> of the ISP, (b) the addresses handed out are publicly routable, AND (c) the
> CPE has to 'authenticate' itself to the head-end, then it is _very_ useful
> *to*the*ISP* to have dynamically-assigned DNS records of the form:
> cust.{accountid}.{locationid}.ISP.{com/net/TLD}
> or something of the sort.
>
> Something of that sort can save a -lot- of time/effort in identifying the
> customer involved in a complaint.
Surely that's only useful if they're still allocated the address at the time of
investigating said complaint; a dynamically updating DNS record like this is
really no substitution for accurate accounting records in your RADIUS system.
Tom
Re: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?)
Hi, On 01/12/2011, at 12:45 PM, Mike Jones wrote: > Link-Local? > [snip] > Am I a complete idiot missing some obvious major issues with link > locals, or am i just the only one not thinking IPv4-think? Opinions? > :) In a DC / hosting provider context, we're doing this. We started out assigning all of our PtP links (where we had /31s in the IPv4 world) IPv6 /64s and addressing using ::1 and ::2 with /127 masks from these /64s (to address potential ND table overflow concerns), but have now settled on using automatic link-local addresses instead. Our IGP propagates the routers' /128 loopbacks and these are used for routing user traffic. Having the IGP table only contain the /128 loopbacks, and none of the PtP networks is nice. :) On 01/12/2011, at 12:52 PM, Ray Soucy wrote: > I for one get really irritated when my traceroutes and pings are > broken and I need to troubleshoot things. ;-) But I guess something > has to give. You don't have to give up working traceroute / ping to use link-local on your PtPs. Our traffic routes through globally reachable router loopbacks which looks pretty in traceroutes, are pingable and doesn't break PMTUD. Tom
