#TheRoutingChurn
Showing results for 
Search instead for 
Do you mean 

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.

Read more...

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.

Read more...

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.      

Read more...

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

 

Read more...

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

 

 

Read more...

Per-prefix LFA

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

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

 

Read more...

LFA analysis with WANDL - Part II (topology refinement)

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

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

 

Read more...

LFA analysis with WANDL - Part I

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

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

 

 

Read more...

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!

Read more...

Granular BGP advertise-external for MPLS L3VPNs

by Juniper Employee ‎04-11-2014 04:09 AM - edited ‎04-21-2014 04:01 PM

In some BGP multi-homed environments between networks, it is possible to achieve shorter convergence times by using certain features beyond traditional [RFC4271] BGP rules. One of these features is the so-called BGP advertise-external or best-external, so that Autonomous System Border Routers (ASBRs) also advertise the best externally received path, even though it may not result as the ultimate best path from the selection algorithm.

 

This article leverages this BGP advertise-external feature offered by Junos OS and inspired by draft-ietf-idr-best-external-05, to enforce it in a granular fashion: on a per peer, VPN or even prefix basis. This implementation comes at the cost of more memory consumption to store additional redundant paths internally in the corresponding network, so it sometimes makes sense to restrain the service from being globally enabled and just offer it tactically or for those added-value customers requiring it.

 

Please feel free to chime in with comments either here or tweeting back to @go_nzo or using the #TheRoutingChurn hashtag.

Read more...

Announcements
Juniper TechCafe Ask the Author
Labels