Showing results for 
Search instead for 
Do you mean 

Tunnel Localization for higher scale

by Juniper Employee on ‎08-03-2017 10:20 AM

Tunneling was invented to connect networks separated by other independent networks. One classic example is the VPN use case where remote access users connect to a variety of network resources (corporate home gateways or an internet service provider) through public data networks. Tunneling is simply encapsulating a packet in another packet. In this, the devices at the network entry and exit points play a pivotal role of doing the encapsulation and de-capsulation respectively, and hence are responsible for building/maintaining the necessary state that facilitates this tunneling, while the rest of the devices in the network seamlessly transport based on the outer headers.


Due to the complexity involved in the encapsulation/de-capsulation (tunneling) process this functionality is offloaded[1] from the forwarding and typically implemented in software on external servers. For operational and economic reasons, vendors came up with tunneling service offerings tethered locally on so called service blades present locally on the chassis. With the advent of powerful forwarding ASICs, the tunneling functionality started getting absorbed into packet forwarding and vendors started offering it in line with the regular forwarding. Though the per-tunnel capacity and overall forwarding capacity for tunneling has increased, the tunnel scale was limited due to the tunneling state that needs to be maintained on the chassis. This didn’t seem to be a problem until now as the tunneling was used primarily for traffic aggregation. But of late the number of use cases of tunneling in the Data Centers and service-providers wholesale network offerings have proliferated due to their enormous advantages. With ever increasing traffic demands vendors are making bigger chassis with more and more forwarding line-cards but the tunnel scale hasn’t kept up the pace due to the large amount of memory footprint required for tunneling. Though the forwarding is distributed across the forwarding-engines/line-cards, the state required for encapsulation and de-capsulation is kept on all the forwarding-engines/line-cards limiting the capacity to what can be supported on a single forwarding-engine/line-card.


In this blog we propose a solution called tunnel-localization (aka tunnel-anchoring) using this the chassis tunnel-scale can be increased linearly with line-cards. We also discuss various forwarding aspects that one needs to consider when using tunnel-localization.


[1] This technique was adopted to avoid impact to the line-rate forwarding.


The security enforcent delegation to the service provider is one of interesting option expetially in case of volumetric DDoS attacks. The traffic re-direction to cleaning devices (cluster) and then re-insertion into network need to be done in a way that prevents routing loops. Commonly used techniques base on either (A) Filter/ACL based forwarding /policy-routing (B) L3VPN instances on ASBRs and/or Edge routers or (C) IP/GRE tunnels between cleaning devices and CPE.


This blog present the alternative method. The proposed architecture do not requires L3VPN nor VRF/VR instances on ASBR and Edge routers, Filter/ACL nor any customer specific configuration on ASBR, peering nor Edge router. It leverage dynamic control plane of IP/MPLS networks to track CPE availability and direct traffic from cleaning cluster to best CPE (multi-homing), honors customer routing attributes (e.g. MED or communities). There is no requirements on CPE other that basic IP forwarding, however if CPE use basic eBGP for communication w/ SP Edge, full potential of solution could be achived.


Self-Driving MPLS Rings

by Juniper Employee ‎03-14-2017 12:08 PM - edited ‎03-14-2017 06:07 PM

Self-Driving MPLS Rings are here! Want to see them in action?  Talk to us at the MPLS World Congress 2017.


There are various fast re-route schemes that are vailable in LDP network. This article compares and contrasts several of them such as LFA, R-LFA, TI-LFA and TI-FRR. It also shows why a particualr fast re route scheme is much simpler than others and how it provides topology independent local protection - That is, how it provides local protection in any topology so long as there is an alternate path in the network avoiding the failed network resource such as link and node.      


python-show-flow-filter.jpgThis article continues my previous DevOps against DDoS I: Programming BGP FlowSpec with Junos PyEz post by providing basic machinery to monitor BGP Flow Specification route installation and enforcement.


This monitoring tool chest is also based on Junos PyEz and I will be leveraging YAML views and operational tables to provide a more programmatic, scalable and intuitive solution baseline.



DevOps against DDoS I: Programming BGP FlowSpec with Junos PyEz

by Juniper Employee ‎04-21-2015 06:03 AM - edited ‎04-27-2015 03:42 PM

DDoSDistributed Denial of Service (DDoS) attacks are increasingly important in the networking industry. Their sophisticated magnitude, crafted impact and widely spread side-effects beyond a specific objective are leading to unexpected and severe economical consequences for both enterprises and service providers.




Per-prefix LFA

by Juniper Employee ‎02-19-2015 04:28 AM - edited ‎02-23-2015 10:05 AM

per-prefix.pngIn previous articles at #TheRoutingChurn, we have reviewed academic aspects and analyzed the Loop Free Alternates (LFA) or IP Fast Reroute (FRR) applicability for a given network with diverse simulation options.


I am covering now some concrete Junos OS tidbits in our usual Junosphere topology in the coming posts to understand the particular influence of certain LFA features.


Herewith I am using first the per-prefix-calculation extension for LFA to illustrate where it makes more sense to apply it and for which use cases.



LFA analysis with WANDL - Part II (topology refinement)

by Juniper Employee ‎02-09-2015 07:33 AM - edited ‎02-09-2015 03:39 PM

WANDL-ECMP-case.pngFollowing up my previous LFA analysis with WANDL - Part I

post, I am reviewing now different Loop-Free Alternate (LFA) academic definitions and references for most applicable topologies and continue the analysis with the WANDL IP/MPLSView toolset.


This WANDL IP/MPLSView platform allows simulation of topology changes and recomputing the LFA analysis.


These simulation results turn out to be aligned with theoretical expectations derived from mathematical calculations and standard models.



LFA analysis with WANDL - Part I

by Juniper Employee ‎01-27-2015 05:06 AM - edited ‎01-27-2015 02:08 PM

WANDL-initial-simple-links.pngLoop Free Alternates (LFA) or IP Fast Reroute (FRR) crystallized some years ago with a basic specification in [RFC5286] as a noteworthy concept to provide standalone backup path calculations just based on route inequalities.




Tweaking BGP add-paths

by Juniper Employee on ‎06-26-2014 08:18 AM


This post follows-up my previous article Granular BGP advertise-external for MPLS L3VPNs with the intention to tweak and illustrate the BGP add-path feature implementation in Junos OS for IPv4 unicast and IPv6 labeled-unicast (6PE) routes. BGP add-paths provide a more comprehensive path diversity approach than diverse paths or advertise-external and in my view, multiple applications can be based on Junos OS BGP add-path tactical deployment in default instance tables.


From convergence improvement to diverse load balancing schemes, BGP add-paths can be applied in a granular fashion in Junos OS to address the usual tradeoff with resource consumption. With this post, I want to review the basic BGP add-path concepts and standards, and tweak the feature in Junos OS by means of another Junosphere topology to illustrate some gotchas and tidbits.


I also want to challenge readers and see if anybody can share any lessons learned: have you evaluated, deployed or tested BGP add-paths? Have you rolled out the feature or taken another design approach? Please chime in over here or using the #TheRoutingChurn Twitter hashtag!