During a project recently, I was promptly reminded about the construction of Junos route export (i.e. route redistribution) policies. Specifically when filtering prefixes during the export/redistribution. The logic goes something like this:
a) Create prefix-list of prefixes to export
b) Create policy which references the protocol and prefix list to export
c) Attach policy to protocol
An example is here:
policy-options { prefix-list CUST_A { 192.0.2.1/32; } policy-statement REDISTRIBUTE_STATICS_CUST_A { /* FROM PREFIX-LIST TEST TO METRIC TYPE 1 FOR CUST A */ term 1 { from { prefix-list CUST_A; } to protocol ospf2; then { external { type 1; } accept; } } } } protocols { ospf { export REDISTRIBUTE_STATICS_CUST_A area 0.0.0.0 { interface x-x/x/x.x } } }
With Junos export policies for routing, if you want to export more prefixes of the same type, adding an additional policy which also references the same protocol for the export will just not work. If you do the below, then you’re out of luck.
policy-options { prefix-list CUST_A { 192.0.2.1/32; } prefix-list CUST_B { 192.0.2.2/32; } policy-statement REDISTRIBUTE_STATICS_CUST_A { /* FROM PREFIX-LIST TEST TO METRIC TYPE 1 Continue reading
Let’s take one look back over the IETF before we move on to the next piece of the infrastructure of the ‘net. Why does it take so long for a single document to get through the process, and result in a standard? There is, of course, the formal process, which requires the document to proposed, […]
The post HTIRW: Reality at the Mic (3) appeared first on Packet Pushers Podcast and was written by Russ White.
MPLS traffic engineering has many use cases and it helps to solve the problems in an MPLS enabled networks. These use cases are in general; QoS guarantee, End to End SLA , Fast reroute, Admission control and so on. All of them at the end is done for the COST SAVING. The real reason behind MPLS Traffic… Read More »
The post What is the real reason behind IP and MPLS Traffic Engineering ? appeared first on Network Design and Architecture.
You might remember my blog post claiming we had a system with SDN-like properties more than 20 years ago.
It turns out SDN is older than that – Rob Faulds found an old ComputerWorld ad from 1989 promoting AT&T SDN service, and it seems SDN was in operation as early as 1985.
This article provide a practical and workable definition of "What Is a Network Service ?"
The post Basics: What Is a Network Service ? appeared first on EtherealMind.
The Packet Pushers are recording a live show on SDN WAN on May 13 in New York in partnership with Viptela. Please join us.
The post Upcoming Event: Packet Pushers at ONUG Talking Software Defined WAN appeared first on Packet Pushers Podcast and was written by Greg Ferro.
I just read story on Medium. It’s a great use of Social Media to achieve something truly useful.
I wish more people would think differently in my line of work. Some days the resounding echoes of “we’ve always done it this way” really give me a headache.
Liked our NV Report? You'll love the new 2015 NFV Report! Download it Today.
I have great respect for my previous company, Cisco Systems, and truly believe that the company has successfully brought a disruptive approach of applying network technologies to answer major business challenges.
Working at Cisco was like being conferred with an honorary doctorate from an Ivy League school in engineering, management, leadership and entrepreneurship simultaneously . The experience of working in multiple lines of businesses was helpful in shaping the mindset on how best to manage innovations and productize them so that it was mutually beneficial to the customers and the company. This productization often required an intense validation process, which resulted occasionally in some really cool technology ideas not ever seeing the light of day. Thoughts presented for the rest of this blog are an attempt to share my experience and possibly dispel some myths in the industry.
Myth – One Vendor Can Answer All Networking Requirements
Network vendors for the longest time have enjoyed a monopoly (or duopoly). If an organization had some IT infrastructure requirements, there were a handful of vendors that would satisfy all their needs. This was great for everyone! As a measure of risk mitigation, a famous unwritten policy surfaced that “you would not lose your Continue reading