Re: Production-scale NAT64
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. Boxes deployed, traffic minimal as we still have IPv4 addresses as well (AFRINIC region). Mark.
Re: Peering + Transit Circuits
On 19/Aug/15 01:12, Patrick W. Gilmore wrote: Normally a router gets a packet and sends it on its way without looking at the source. However, if you have a router at the IX which has _only_ peer routes and your routes, that solves the problem. If I send you a packet for Comcast, your peering router will drop it and send an ICMP Network Unreachable. No filters to manage, no RIRs to sync, nothing to code, etc. This is what we do, and to make it more interesting, we have 0/0 and ::/0 on these dedicated peering routers pointing to Null0. Mark.
Re: Production-scale NAT64
On 26 August 2015 at 00:55, Mark Tinka mark.ti...@seacom.mu 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: Production-scale NAT64
* William Herrin On Thu, Aug 20, 2015 at 1:22 PM, Ca By cb.li...@gmail.com wrote: On Thu, Aug 20, 2015 at 9:36 AM, William Herrin b...@herrin.us wrote: Seriously though, if you want to run a v6-only network and still support access to IPv4 Internet resources, consider 464XLAT or DS-Lite. NAT64 is a required component of 464XLAT. Sort of, technically, but not really. Yes really. See below. 464XLAT does not require DNS64 and provides client software with an IPv4 interface. IPv4 software that has no idea IPv6 exists sends IPv4 packets which get translated to IPv6 packets. Those packets are routed to the carrier NAT box which then translates these specially crafted IPv6 packets back to IPv4 packets. What do you think the «carrier NAT box» in 464XLAT is, exactly? No need to guess, we can check the 464XLAT specification: http://tools.ietf.org/html/rfc6877#section-2 PLAT: PLAT is provider-side translator (XLAT) that complies with [RFC6146]. It translates N:1 global IPv6 addresses to global IPv4 addresses, and vice versa. Let's check that reference: http://tools.ietf.org/html/rfc6146#section-1 This document specifies stateful NAT64, a mechanism for IPv4-IPv6 transition and IPv4-IPv6 coexistence. Lo and behold! Your 464XLAT «carrier NAT box» (a.k.a. «PLAT») *is* a NAT64 box. Thus, if you intend to deploy 464XLAT in production, you'll going to need a production scale NAT64 implementation. To answer the Jawaid's original question, I'm very happy with Jool (http://jool.mx) for my NAT64 (and SIIT) needs, which is a open-source Linux-based software solution. It has no problems handling several Gb/s of traffic using a couple of years old x86 server without any tuning, so if the capacity required is moderate this might be a cost-effective alternative to a dedicated boxes from the one of the router/network appliance vendors. Tore
Re: BGP advertise-best-external on RR
Hi, In your case I¹d recommend to use diverse path, due to its simplicity and non disruptive deployment characteristics. As you know - diverse path requires additional BGP session per additional (second, next, etc) path, in most cases not a problem, however mileage might vary. To my memory, in Cisco land - it has only been implemented in IOS, not XR, please check. Cheers, Jeff -Original Message- From: Diptanshu Singh diptanshu.si...@gmail.com Date: Monday, August 24, 2015 at 10:53 PM To: Mohamed Kamal mka...@noor.net Cc: nanog@nanog.org nanog@nanog.org Subject: Re: BGP advertise-best-external on RR Yes . In the case of diverse path , shadow route reflector will be the one wherever you enable commands to trigger diverse path computation. Good thing with diverse path is that the RR-Clients don't have to have any support but bad thing is that it can only reflect One additional best-path( second best path ) . Sent from my iPhone On Aug 24, 2015, at 2:31 PM, Mohamed Kamal mka...@noor.net wrote: It's only supported on the 15.2(4)S and later not the SRE train. I might consider an upgrade. One more question regarding this, can you configure the RR to be the main and shadow RR? Mohamed Kamal Core Network Sr. Engineer On 8/24/2015 9:16 PM, Diptanshu Singh wrote: BGP Add-Path might be your friend . You can look at diverse-path as well .
Re: [c-nsp] Peering + Transit Circuits
On 18/Aug/15 15:31, Tim Durack wrote: Not sure if I really want to get into using DSCP bits for basic IP service though. There are use-cases, but they would mostly be internal. Mark.
Re: [c-nsp] Peering + Transit Circuits
On 18/Aug/15 18:02, Tim Durack wrote: Can I ask why you terminate peering and transit on different routers? (Not suggesting that is bad, just trying to understand the reason.) Easier policy enforcement for us. Lowers the chance of you dealing with traffic in ways you don't intend (although that can always be fixed). Spreading both commercial and technical risk, depending on whether you value transit more than peering, or vice versa. Avoiding kinky things with VRF's. Mark.
Re: [c-nsp] Peering + Transit Circuits
On 25/Aug/15 13:58, Scott Granados wrote: If you’re not enabling URPF at the peering routers and edges how do you handle things like RTBH? D/RTBH still works fine. S/RTBH would be an issue, but one could enable uRPF temporarily for that. Mark.
Re: [c-nsp] Peering + Transit Circuits
On 18/Aug/15 14:29, Tim Durack wrote: Question: What is the preferred practice for separating peering and transit circuits? 1. Terminate peering and transit on separate routers. We do this. Makes policy enforcement easier. Mark.
Re: [c-nsp] Peering + Transit Circuits
On 18/Aug/15 22:43, Nick Hilliard wrote: i'd advise being careful with this approach: urpf at ixps is a nightmare. We don't generally do uRPF at exchange points, for the simple reason that the router is dedicated (meaning it does not carry a full table), and peers leaking your routes to the Internet (which breaks uRPF in this scenario) is a constant scenario. *sigh* Mark.
LTE
Is there anybody here who is fluent in LTE/3GPP networks and the standards that govern them? I'm not sure where else to look. I have a very specific question about UEs, UICCs, and the security negotiation (integrity ciphers) that occurs during attachment both on the AS and NAS layers, and so far I have not found our vendor to be very helpful. If there is somebody out there that knows something about this area, and is willing to chat with me about it, feel free to drop me a line off-list. Thanks much, -- Nathan Anderson First Step Internet, LLC nath...@fsr.com
Re: LTE
Nathan, I know someone. Contact me off list and I will get you and he connected. Bryan On Tue, Aug 25, 2015 at 4:33 PM Nathan Anderson nath...@fsr.com wrote: Is there anybody here who is fluent in LTE/3GPP networks and the standards that govern them? I'm not sure where else to look. I have a very specific question about UEs, UICCs, and the security negotiation (integrity ciphers) that occurs during attachment both on the AS and NAS layers, and so far I have not found our vendor to be very helpful. If there is somebody out there that knows something about this area, and is willing to chat with me about it, feel free to drop me a line off-list. Thanks much, -- Nathan Anderson First Step Internet, LLC nath...@fsr.com
