This blog keeps the book MPLS in the SDN Era alive between its first and its (hopefully) second edition.
Check the configuration repository in this page, it keeps growing!
Advertisements
This blog keeps the book MPLS in the SDN Era alive between its first and its (hopefully) second edition.
Check the configuration repository in this page, it keeps growing!
Possible errata: in the text describing Figure 1-3, Basic ISP topology, “On the other hand, PE3, PE4, BR1, and BR2 are ASBRs….” — there are no BR1, BR2 in the figure, only BR3, BR4.
LikeLike
Indeed. Thanks for pointing out this tip error! Please submit further errata directly on O’Reilly site http://shop.oreilly.com/category/customer-service/faq-errata.do
LikeLike
“In this example, CEs and BRs advertise their own loopacks to one single eBGP peer:
CE1 advertises 192.168.10.1/32 to PE1 only.
CE2 advertises 192.168.10.2/32 to PE2 only.”
Figure 1-4 has eBGP Single-Hop Sessions between CE1 & PE2, and CE2 and PE1, so I’m a bit confused.
LikeLike
In the text :
In this example, it is simulated by selectively blocking the local loopback advertisement from
CE1 and CE2 (eBGP export policies), and by only configuring one eBGP session at
each BR.
LikeLike
Thanks!
By the way, I’m not a networking engineer; rather an Enterprise Architect; even so I find what I’ve read so far to be really good and understandable!
LikeLike
You are welcome!. And we are happy to hear that.
LikeLike
hi guys – the book is, as expected, a rare gem. I have come across just one thing: at page 593 it says ‘OSPF lacks this flexibility, as there is no way to suppress the advertisement of link addresses with OSPF’. Am I totally off track or it is what the following IOS command (
prefix-suppression) is meant to achieve ? http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t15/ht_osmch.html
LikeLike
Indeed, good catch. Do you know, if this is available for IOS XR as well? Or only IOS? This book is based on IOS XR, and we couldn’t find prefix suppression there (http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r5-3/routing/command/reference/b-routing-cr53xcrs/b-routing-cr53xcrs_chapter_0101.html)
LikeLike
Hi there,
Good point !! As far as I have found it is only available for ISIS.
Slide 82 (2015) of the following ppt https://clnv.s3.amazonaws.com/2015/usa/pdf/BRKRST-3363.pdf
says in fact the following:
XE: OSPF prefix suppression
XR/XE: ISIS advertise passive-only
I guess when you guys mentioned the OSPF lack of flexibility you meant the fact that suppressing a prefix in ISIS is easier to enforce than in OSPF as it involves manipulating prefixes within a TLVs as opposed to manipulating Link-types within LSA1 and LSA2 ?
LikeLike
We have been looking at Junos and IOS XR only. And neither in Junos, nor in IOS XR we didn’t found the way to suppress link prefixes for OSPF. Therefore the book states lack of flexibility for OSPF (we didn’t checked any other OSes, like IOS, for example). For ISIS it is possible to create route-policy, to specify what should and what shouldn’t be advertised. So, suppression of link prefixes is possible.
LikeLike
Gotcha! it makes perfectly sense. Will keep blissfully reading. Thanks again guys for this outstanding piece of work.
LikeLike
First of all I want to say you guys did a great job with writing this book.
I have a question and hopefully you can help me with that.
I am interested in the configuration snippets of chapter 8. Specially the combination of a a MC-LAG configuration on Juniper PE nodes with an EVPN configuration. It would be great if this can be shared
LikeLike
Thanks for your patience, we will definitely do ASAP.
LikeLike
Actually, mc-ae configuration stanza is not supported with EVPN. That was not clearly articulated, so we will make some more clear text in the next editions.
LikeLike
Another errata: on p.132, ex.3-9 there’s output from “show bgp ipv6 unicast neighbors 10.2.0.4 routes” (or similar) rather than “show bgp ipv6 unicast fc00::10:2:34:0/112” as stated in the book.
Correct me if I’m wrong.
The book is absolutely great, BTW, thank you.
LikeLike
Hi Vitaly, the command was correct but the keyword “brief” was missing. Please submit further errata directly on O’Reilly site at http://shop.oreilly.com/category/customer-service/faq-errata.do . Thanks for your nice comments.
LikeLike
Hy all,
first of all I have to say that MPLS in SDN Era is a great book, because it joins both theory and both practical examples.
I have a couple of technical questions that I submit you in the following:
–Question#1–
Chapter 2 Section BGP LU in Data Center.
At page 108 is written:
<>
I don’t udenstand why we must assure to not readvisertise labeled routes as unlabeled
Can you provide an example to better understand what would happen in IOS XR in this case?
–Question#2– (to get confirm of my understanding)
Chapter 2 Section BGP LU in Data Center.
Page 115 -(Juniper MPLS enabled Server device)
In S1 we must set up the two vanilla BGPv4 sessions towards the RRs/Spines.
In order to let Srv nodes to do that, Srvs nodes must known how to reach them.
For this reason we perform a local copy, thanks to rib group, of the Spines LB from inet.3 towards inet.0.
My question is:
in the output of the following commands:
juniper@Srv1> show route 172.16.1.1/32 detail
There will be as next-hop for 172.16.1.1 the label towards the leaf L1? (learned from the inet.3)
LikeLike
Chapter 2 Section BGP LU in Data Center.
At page 108 is written:
<>
LikeLike
At page 108 is written:
”
This careful community scheme is due to the fact that IOS XR keeps labeled and
unlabeled IP routes in the same global table, so it is important not to readvertise
labeled routes as unlabeled routes, or vice versa. Said differently, you need to pay spe‐
cial attention so that the SAFI=1 and SAFI=4 worlds remain independent.
“
LikeLike