Re: [j-nsp] Transfer some task from MX to VRR
On 2 Dec 2014, at 12:41 am, Robert Hass robh...@gmail.com wrote: I think vMX can forward data. vMX indeed will be full-featured router. But my questions was related to move part of control-plane (basically whole BGP part of rpd) to external server. Maybe OpenFlow somehow helps here ? How openflow take care of eBGP to customers ? Session should be on router or on OpenFlow controller ? OF v1.3 just has been implemented in JunOS 14.x releases for MX series. This is completely doable without the need for Openflow. The vMX is delivered as two VMs - a vRE and vPFE and logically they communicate in the same way as the RE and PFE do in an MX today eg: an internal ethernet switch sends control-plane information down to the forwarding engine. Whether this happens on a single host machine across a vSwitch, or across a physical network is now completely irrelevant, normal constraints not withstanding (congestion/loss etc). It's not a big stretch to imagine being able to one day ditch the vPFE and take a bunch of head-less MXs (hardware-based) acting as remote FPCs to a pair of centralised vREs - like JCS/TXM but on more commoditised server hardware, or even a Q-Fabric with MXs as nodes and commodity directors/interconnect. Given that control-plane traffic is pretty minimal, and with all the cool FIB localisation knobs coming down in 14.x, the scaling/design implications of this get pretty interesting. Heck - it should be possible to one day take the much-maligned MX80 RE and replace it with a remote intel-based monster, and get 64-bit Junos in the mix. Emulating the backplane for inter-FPC traffic is going to be a barrel of fun though! Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Transfer some task from MX to VRR
Quoting Eric Van Tol e...@atlantech.net -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Robert Hass Sent: Monday, December 01, 2014 7:30 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Transfer some task from MX to VRR Hi Just readed release notes for 14.2 and I found that starting this release I can transfer some task to external VRR. So my idea is to move all BGP from MX80 to VRR. But how it can be performed for external BGP sessions where I have just /30 or /31 subnets to customers ? (of course without ebgp multihop). I'm pretty sure the VRR is mostly for solving the problem of iBGP session scaling. If that's not the case, I'm sure someone will correct me. You don't have much choice with eBGP if you don't want to use multihop, unless you want to backhaul every customer circuit via L2 to your VRR, in which case the VRR is basically the gateway for the customer's circuit. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone Original message From: Eric Van Tol e...@atlantech.net Date:12/01/2014 8:09 AM (GMT-05:00) To: juniper-nsp@puck.nether.net Cc: Subject: Re: [j-nsp] Transfer some task from MX to VRR ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Transfer some task from MX to VRR
On Monday, December 01, 2014 03:09:15 PM Eric Van Tol wrote: I'm pretty sure the VRR is mostly for solving the problem of iBGP session scaling. If that's not the case, I'm sure someone will correct me. I think vMX can forward data. It will come down to how well it optimizes the CPU, and how good the CPU actually is. You don't have much choice with eBGP if you don't want to use multihop, unless you want to backhaul every customer circuit via L2 to your VRR, in which case the VRR is basically the gateway for the customer's circuit. Agree. Your design can get complicated if you separate routing from forwarding for a particular device or downstream-set. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Transfer some task from MX to VRR
I think vMX can forward data. vMX indeed will be full-featured router. But my questions was related to move part of control-plane (basically whole BGP part of rpd) to external server. Maybe OpenFlow somehow helps here ? How openflow take care of eBGP to customers ? Session should be on router or on OpenFlow controller ? OF v1.3 just has been implemented in JunOS 14.x releases for MX series. BTW. Are anyone participating in vMX beta-trial ? Rob On Mon, Dec 1, 2014 at 3:06 PM, Mark Tinka mark.ti...@seacom.mu wrote: On Monday, December 01, 2014 03:09:15 PM Eric Van Tol wrote: I'm pretty sure the VRR is mostly for solving the problem of iBGP session scaling. If that's not the case, I'm sure someone will correct me. I think vMX can forward data. It will come down to how well it optimizes the CPU, and how good the CPU actually is. You don't have much choice with eBGP if you don't want to use multihop, unless you want to backhaul every customer circuit via L2 to your VRR, in which case the VRR is basically the gateway for the customer's circuit. Agree. Your design can get complicated if you separate routing from forwarding for a particular device or downstream-set. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Transfer some task from MX to VRR
On Monday, December 01, 2014 04:41:54 PM Robert Hass wrote: vMX indeed will be full-featured router. But my questions was related to move part of control-plane (basically whole BGP part of rpd) to external server. Maybe OpenFlow somehow helps here ? How openflow take care of eBGP to customers ? Session should be on router or on OpenFlow controller ? OF v1.3 just has been implemented in JunOS 14.x releases for MX series. That's a little too cutting edge (even) for me :-). My guess is vRR is a function of vMX. No point in having two products. I could be wrong... Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Transfer some task from MX to VRR
I'm pretty sure the VRR is mostly for solving the problem of iBGP session scaling. I asked, as solving problems of iBGP is obvious. Terminating customers sessions on VRR using ebgp-multihop is also possible but it's needs reconfiguration at customer side. It's time consuming and too many questions and it's a small complication. I already saw some EFT code coming from other well-known network vendor where BGP traffic coming to router control-plane was tunneled to VRR like Virtual-Machine and processed there. All BGP related commands was also redirected to VRR but router receives FIB from VRR instead of RIB. Rob On Mon, Dec 1, 2014 at 2:09 PM, Eric Van Tol e...@atlantech.net wrote: -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Robert Hass Sent: Monday, December 01, 2014 7:30 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Transfer some task from MX to VRR Hi Just readed release notes for 14.2 and I found that starting this release I can transfer some task to external VRR. So my idea is to move all BGP from MX80 to VRR. But how it can be performed for external BGP sessions where I have just /30 or /31 subnets to customers ? (of course without ebgp multihop). I'm pretty sure the VRR is mostly for solving the problem of iBGP session scaling. If that's not the case, I'm sure someone will correct me. You don't have much choice with eBGP if you don't want to use multihop, unless you want to backhaul every customer circuit via L2 to your VRR, in which case the VRR is basically the gateway for the customer's circuit. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Transfer some task from MX to VRR
On 12/1/14, 2:41 PM, Robert Hass robh...@gmail.com wrote: I think vMX can forward data. vMX indeed will be full-featured router. But my questions was related to move part of control-plane (basically whole BGP part of rpd) to external server. Maybe OpenFlow somehow helps here ? How openflow take care of eBGP to customers ? Session should be on router or on OpenFlow controller ? OF v1.3 just has been implemented in JunOS 14.x releases for MX series. Juniper as far as I know plans on maintaining two versions of the vMX at least to start with. The vRR version is similar to the one used for things like lab testing and uses 1 VM with both the vRE and vPFE integrated. The vRR is not meant to be in the forwarding path just like the vRR offerings from ALU and Cisco. You would not really want to use it to terminate eBGP sessions. There is another higher speed forwarding version of the vMX which requires using Intel 10GE NICs. It doesn't really support high speed 1G since it uses the Intel DPDK/SR-IOV specific to those 10G cards. ALU has the same exact thing with their VSR series. Now that version of the vMX would be one which could terminate customer circuits and EBGP sessions. The perfect scenario for it is terminating lower-speed Ethernet Internet customers since those usually don't require much advanced processing like NAT, etc. Long-term most of the vendors have plans to externalize the control planes. Juniper has experience with this since they have done it with the TX-Matrix and the old EX8200 virtual chassis stuff previously. I think you will see all vendors headed this way though especially when it comes to things like subscriber management/bras functionality. No reason to limit those things to a router RE anymore. Phil BTW. Are anyone participating in vMX beta-trial ? Rob On Mon, Dec 1, 2014 at 3:06 PM, Mark Tinka mark.ti...@seacom.mu wrote: On Monday, December 01, 2014 03:09:15 PM Eric Van Tol wrote: I'm pretty sure the VRR is mostly for solving the problem of iBGP session scaling. If that's not the case, I'm sure someone will correct me. I think vMX can forward data. It will come down to how well it optimizes the CPU, and how good the CPU actually is. You don't have much choice with eBGP if you don't want to use multihop, unless you want to backhaul every customer circuit via L2 to your VRR, in which case the VRR is basically the gateway for the customer's circuit. Agree. Your design can get complicated if you separate routing from forwarding for a particular device or downstream-set. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Transfer some task from MX to VRR
On Monday, December 01, 2014 05:27:23 PM Phil Bedard wrote: Juniper as far as I know plans on maintaining two versions of the vMX at least to start with. The vRR version is similar to the one used for things like lab testing and uses 1 VM with both the vRE and vPFE integrated. The vRR is not meant to be in the forwarding path just like the vRR offerings from ALU and Cisco. You would not really want to use it to terminate eBGP sessions. Don't know about the ALU offering, but Cisco don't have a vRR-type solution. CSR1000v is a full-fledged router. What you can do and how much traffic you can forward through it is all controlled by what license you buy. I find this a better use of vendor resources than maintaining two separate tracks. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Transfer some task from MX to VRR
They sell XRv now specifically as a vRR, you can find the deployment guides on their website. The throughput on it isn't very good and they suggest using the CSR if you really want a software router. The only other thing they have XRv for is testing. Juniper doesn't really have two tracks, its the same RE software, just think of it like using two different line modules in the same router. I just don't think they have quite made it seamless at this point. Phil -Original Message- From: Mark Tinka mark.ti...@seacom.mu Sent: 12/1/2014 11:52 AM To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Cc: Phil Bedard phil...@gmail.com; Robert Hass robh...@gmail.com Subject: Re: [j-nsp] Transfer some task from MX to VRR On Monday, December 01, 2014 05:27:23 PM Phil Bedard wrote: Juniper as far as I know plans on maintaining two versions of the vMX at least to start with. The vRR version is similar to the one used for things like lab testing and uses 1 VM with both the vRE and vPFE integrated. The vRR is not meant to be in the forwarding path just like the vRR offerings from ALU and Cisco. You would not really want to use it to terminate eBGP sessions. Don't know about the ALU offering, but Cisco don't have a vRR-type solution. CSR1000v is a full-fledged router. What you can do and how much traffic you can forward through it is all controlled by what license you buy. I find this a better use of vendor resources than maintaining two separate tracks. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Transfer some task from MX to VRR
On Monday, December 01, 2014 07:49:36 PM Phil Bedard wrote: They sell XRv now specifically as a vRR, you can find the deployment guides on their website. That's right. Development of XRv has not been as great as CSR1000v (not sure why, to be honest). We have workshops that use XRv for MPLS workshops, but I wouldn't recommend anything more production-grade on it, even with the XRv production image as a route reflector. Juniper doesn't really have two tracks, its the same RE software, just think of it like using two different line modules in the same router. I just don't think they have quite made it seamless at this point. Okay. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
