Expiring in 2 Weeks? JNCIE-SP #1999

I have now reached the point where I am in a 2 week countdown until my JNCIE-SP expires. I had been toying with the idea of letting it do so since I spend as much time coding these days as I do network engineering things and more of my energy is on the coding side.

But this morning I changed my mind.

I have decided to renew it for another 3 years as insurance. Increasingly, I dream of a sabbatical. And if I have to provide for this myself, that will mean taking myself out of the work force and then finding a way back in. Having a certification will help.

Renewing involves taking the JNCIP-SP written exam: JN0-660.

My guess is that I can make myself ready after a few days of of study. I plan to put in a couple of hours each day studying and then take and fail the exam a week's time or less. There is no shame in this.

Veterans of the JNCIE-SP practical examination are well aware that failing the actual test is a key part of preparation. This is true for the written tests as well. There is not a good substitute to get you into the flow of thinking like the test other than doing it.

Incidentally, many things in life are like this. The only way to get real and hard data is to actually do something with the understanding that it may not work, but that in attempting to do it, you will learn things.

So... Expiring in 2 weeks? Probably not.

image.jpg

#JNCIE-SP: Using "Show TED Database" to Troubleshoot CSPF

I’ve generally found the output of show TED database to be a bit cryptic. But I ran into an issue today which forced me to really buckle down and figure out what it means and I think I’ve got something worked out.

fluong@SPOCK-re0> show mpls lsp
10.0.0.110  0.0.0.0      Dn     0       -                SPOCK-to-SULU

It was a sad sight. The LSP was down and the log from show mpls lsp extensive only had one line:

     1 Jun 27 14:27:20.553 CSPF failed: no route toward 10.0.0.110[927 times]

I sanity checked my loopback addresses and made sure that family mpls was configured on all backbone interfaces and was included in protocols rsvp and mpls. Everything looked good on SPOCK.

So I started looking at “show ted database”.

fluong@SPOCK-re0> show ted database 10.0.0.110
TED database: 44 ISIS nodes 44 INET nodes
ID                            Type Age(s) LnkIn LnkOut Protocol
SULU.00(10.0.0.110) Rtr    475     1      2 IS-IS(1)
    To: KIRK-re0.00(10.0.0.5), Local: 10.0.0.170, Remote: 10.0.0.171
      Local interface index: 329, Remote interface index: 456
    To: SCOTTY.00(10.0.0.111), Local: 10.0.0.168, Remote: 10.0.0.169
      Local interface index: 327, Remote interface index: 3

Okay… looks like we’re getting to SULU via a couple of routers, KIRK and SCOTTY. So I logged into the next router down the line, KIRK, and I found that it’s LSP to SULU was also down. So I started sanity checking config.

fluong@KIRK-re0> show mpls lsp ingress 
10.0.0.110  0.0.0.0     Dn     0       -                KIRK-to-SULU

fluong@KIRK-re0> show interfaces descriptions ae1
Interface       Admin Link Description
ae1             up    up   To SULU, ae1

fluong@KIRK-re0> show interfaces terse ae1 | match mpls
                                   mpls    

fluong@KIRK-re0> show mpls interface       
Interface        State       Administrative groups (x: extended)
ae1.0            Up         <none>

fluong@KIRK-re0> show rsvp interface ae1
 <no output>

Bingo! Missing RSVP interface configuration.

It occurs to me that this could be very useful as a quick way to narrow down what interfaces may be missing MPLS configs. Here is my method:

If an LSP is down CSPF reports no route:

  • verify loopback address and router-id on the far end
  • use the output “show ted database” to trace through performing sanity checks on interface-specific MPLS configs.
    • show interface terse (check for family mpls)
    • show mpls interface (make sure backbone interfaces are present)
    • show rsvp interface (make sure backbone interfaces are present)
    • show ldp interface (if applicable, make sure relevant backbone interfaces are present)

I did it! #JNCIE-SP #1999! (and 5 tips on how to prepare for it)

The wait is over. I heard today that I passed the JNCIE-SP exam. Hooray!

I expect that I will get this question a lot so I’ll do my best to answer it here.

Franco, what tips can you share about how to prepare for this exam?

  1. Read the Exam Objectives. Sounds obvious but this is your roadmap for knowing what topics are covered for the exam. Print it. Pin it up. Read it regularly.

  2. Take the JNCIE-SP Bootcamp. When I first took this class, I wasn’t able to keep up with the material but I was able to get a taste of some of the topics that are covered and how to interpret the wording. Over time, I was able to go into the labs in detail at my own pace. If you’re flush with cash, consider taking it before you begin your prep and take the bootcamp again just before you sit for the exam. Above all else, remember that the Bootcamp doesn’t cover 100% of what you need to know but it’s most of the way there and illustrates some of the complex details.

  3. Read some of my previous blog posts. The stuff I’ve written covers some of the less obvious details that are easy to overlook but they are best as a supplement to the Bootcamp material. Other people have also documented similar things that have helped them most during the exam. Use what you can, but remember to bring along your grain of salt and that the details may change with new versions of Junos.

  4. Practice more than Study. You will either need a home lab or you will need to book time on Junosphere to practice configuration and troubleshooting. Once you’ve taken the JNCIE-SP bootcamp, you have a great springboard for performing deep exploration and making modifications to cover the things you think are lacking. Don’t be afraid to go into the weeds. Studying is good but it should supplement your practice and not the other way around. You can’t get good at the things you need to get good at to pass by spending most of your time reading and taking notes.

  5. Fail the Exam. At $1k per attempt, this one is expensive but ultimately there is no substitute for having the experience of the real test itself. When you have gotten pretty far along with your practice, take the exam and see how you do. Keep good notes on what you observed, what was confusing, and what you want to do better next time. Any configuration that really stumped you needs to be explored in depth until you are satisfied that you have a good way to solve it. Use your experience with the exam to build more complex exercises for yourself in your practice.

These are my tips. I hope they serve you well.

-Franco

#JNCIE - One Practice Strategy: Configure It Quickly, Fix It Slowly

Studying and practicing for your JNCIE examination means that you have a couple of conflicting things you need to work on. You need to practice for your speed of execution, but you also need to practice looking at outputs and developing your intuitive sense of where to look for problems when your protocols aren’t coming up or traffic is not flowing.

It can be hard to imagine the many different ways a protocol can break but the good news is you have an ally in this department: your lousy memory and your bad typing skills! :)

When I was sitting for my exam yesterday, I was missing a bit of configuration for a VPN I was configuring and the output was really a bit mystifying. It took me a while to sort it out. And it occurred to me that a person could really use their configuration mistakes to their own advantage while doing practice runs by patiently troubleshooting them without reaching for the books and looking things up right away.

So here’s the strategy I came up with:

  1. Pick a technology you want to work on from the Exam Objectives. The more convoluted the better. Try to find ways to “tie one hand behind your back”, for instance by adding a restriction like VPN route-reflectors that don’t have MPLS running, or IGP total stub areas that require an aggregate route.

  2. Configure the scenario as quickly as you can with as little configuration as possible. Don’t make mistakes on purpose but do rush it. Test with pings from the CE devices (end-to-end) if possible.

  3. Assuming everything didn’t come up, start troubleshooting and really linger over the show commands. Do this especially when you have just found the problem looking at the before and after and seeing how the outputs are different.

  4. Assuming everything did come up. You can still try to break it by removing an ingredient and comparing what the outputs look like while it is broken. (e.g. remove an interface from “protocols mpls” or remove an address family from the interface).

  5. Make notes to yourself on what you learned in Evernote.

This will let you practice implementing things with speed while making an opportunity to practice spotting problems in your outputs when the network has missing or invalid configs.

photo credit: wifebot

#JNCIE-SP: When Configuring Labeled Unicast Peers, Configure The Interface For MPLS First

Ran into an interesting situation with inter-provider VPNs.

When setting up the ASBR peering, I got the BGP setup before adding family mpls to the interface. And when I checked IBGP advertisements, I got this:

 lab@R3&gt; show route advertising-protocol bgp 172.27.255.1 

 inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)
   Prefix                  Nexthop              MED     Lclpref    AS path
 * 95.100.255.2/32         Self                 1       100        60001 I

 inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
   Prefix                  Nexthop              MED     Lclpref    AS path
 * 95.100.255.2/32         Not advertised       1       100        60001 I

Uh Oh… “Not Advertised”… Let’s check to see what’s up.

lab@R3&gt; show route advertising-protocol bgp 172.27.255.1 extensive 

 inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

 * 95.100.255.2/32 (1 entry, 1 announced)
 BGP group internal type Internal
      BGP label allocation failure: family mpls not enabled on interface
      Nexthop: Not advertised
      Flags: Nexthop Change
      MED: 1
      Localpref: 100
      AS path: [3895077211] 60001 I

Hmmmm… That’s strange. I thought I enabled it…

 [edit interfaces ge-0/0/4]
 lab@R3# show 
 description "Connection to P-1";
 unit 0 {
     family inet {
         address 172.27.0.57/30;
     }
     family mpls;
 }

Yeah… there it is. What if I try to clear soft-in?

 lab@R3&gt; clear bgp neighbor 172.27.0.58 soft-inbound 

 inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

 * 95.100.255.2/32 (1 entry, 1 announced)
 BGP group internal type Internal
      BGP label allocation failure: family mpls not enabled on interface
      Nexthop: Not advertised
      Flags: Nexthop Change
      MED: 1
      Localpref: 100
      AS path: [3895077211] 60001 I

Nope… no go. Looks like we get to wait 30+ seconds. :)

 lab@R3&gt; clear bgp neighbor 172.27.0.58                                
 Cleared 1 connections

Now to go get some coffee…

 lab@R3&gt; show route advertising-protocol bgp 172.27.255.1 extensive    

 inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)
 * 95.100.255.2/32 (1 entry, 1 announced)
 BGP group internal type Internal
      Nexthop: Self
      Flags: Nexthop Change
      MED: 1
      Localpref: 100
      AS path: [3895077211] 60001 I

 inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

 * 95.100.255.2/32 (1 entry, 1 announced)
 BGP group internal type Internal
      Route Label: 299952
      Nexthop: Self
      Flags: Nexthop Change
      MED: 1
      Localpref: 100
      AS path: [3895077211] 60001 I

That looks much better!

JNCIE-SP: For Class-of-Service Know Your Defaults and Be Ready to Do Some Conversion

My exam prep continues. I spent a bit of time sitting with class-of-service this weekend and I think I have a good strategy for CoS that I want to share.

Preparation

I’m going to assume that you’re studying how to configure all of the basics of class-of-service for the exam. This post won’t cover much about configuration. You should know how to create custom classifiers, rewrite rules, forwarding-classes, schedulers, and scheduler-maps. You should know how to apply these to your interfaces.

You need to study that. I’m not here to talk about it. Instead, I wanted to discuss a couple of points that are a bit more subtle and strategic in nature that I think I worked out this weekend.

Know your Defaults

If you’re not asked to implement any special forwarding classes, using the default forwarding classes, rewrite-rules, classifiers, and schedulers can be a huge time saver during the exam. The assumption here is that you’re doing some work at the edge to get the traffic marked into the specified forwarding classes. After you have it classified on the first box, you may have some additional work to do to make sure the rest of the network knows how to handle your classifications.

So here’s my big tip: Learn your defaults and be prepared to modify or over-configure them.

So what do I mean by “Learn Your Defaults”? Basically, you need to be able to answer these questions:

  • What forwarding-classes exist by default?
  • What classifiers and rewrite rules are configured by default?
  • What is the difference between classifiers: ipprec-default and ipprec-compatibility?
  • What schedulers are configured by default?
  • What show commands can I use to look at these if I forget?

Because it’s too lengthy to include here, I’ll just link to an Evernote Shard with a whole bunch of outputs and links to the documentation.

You can augment your bit of memorization work by using “show class-of-service…” commands available. This is good for me because I am lazy but there is another good reason to use the show command output. Because the details of what configuration is default may change as you go from one version of JUNOS to another, (and you may not be practicing on the exact version used on in the exam environment) knowing how to verify the defaults from show command outputs can save you in case of any differences between.

With any luck, the requirements will permit you to apply some default classifiers and rewrite rules to get you carried through your backbone.

Be Ready to Do Some Binary Conversion

You’re gonna need to be able to check your work.

Ping lets you set the ToS bit, which is handy to create DSCP or IP-Precedence marked traffic, but the value has to be specified as a decimal number. This may require math or a calculator or a bit of memorization. If you’re not verifying against IP header code points, you will have to do some temporary config changes with MF classifiers to test your configs. I don’t discuss that in detail here, just the IP ToS verification.

Knowing your basics for how ToS/IPPrec/DSCP are mapped is crucial knowledge here:

  • IP Precedence is a 3-bit value occupying the high order bits of the ToS field in the IP header. You can convert IP precedence to a decimal TOS value by multiplying by 32 (or 2^5) (e.g. 101 == 5 // 5*32 = 160).
  • DSCP is a 6-bit value occupying the high order bits of the ToS field in the IP header. Incidentally, this makes it mutually exclusive vs. IP Precendence. You can convert these to a decimal ToS value by converting to decimal and then multiplying by 4 (2^2). My brain is tired just thinking about this, so…

If you don’t want to do math at all, use the “Programmer” mode of the calculator app that comes with Windows to do the conversion. You still need to know that the value occupies the high order bits of an 8-bit field to do this. Pad IPPrec with 5 zeros to the right or DSCP with 2 zeroes to the right and you are good to go. Example follows for IP Precendence value 101:

binary

decimal

If you are going to verify with pings, be able to do this conversion quickly.

Exam Strategies

  1. Read the requirements in detail and correlate with any requirements from other sections that may impose restrictions on what methods you may use to achieve these goals.

  2. Classify at the ingress edge. To classify by behavior aggregate code-points, use a classifier. Only use multifield classification if it is required for classification based on other packet characteristics.

  3. If you need to police certain classes based on code-points, you’re already classified and you can simply use “from forwarding class”.

  4. If you have to add a firewall filter, including counters in the filter can be handy for verification.

  5. If possible, use the available “default” forwarding-classes, classifiers, and rewrite rules to your advantage and either over-configure them (meaning, explictly configure defaults) or know how to verify them quickly. Apply these to backbone interfaces. This will be handy if you need forwarding classes to be handled on every router in the backbone.

  6. Verify with pings through to your designated destinations, if you can. Use the calculator to work out ToS values if you need to. Use any firewall counters you have applied and “show interfaces queue” outputs. Test as many traffic classes as you can to verify you have the requirements met.

The Wording Will Get You

Something to watch out for: If the requirements tell you to preserve the “markings” through the network, I suppose you may not be able to achieve that using defaults. I’d ask the proctor on that note.

JNCIE-SP: IPv6 NLRIs over IPv4 BGP Peering When You're Not Using Mapped Addresses.

I previously posted about a way to configure BGP for IPv6 Unicast NLRI over an IPV4 session. Well, sometimes you don’t get to choose the address that the interface is running and it may be the ::1.2.3.4 ipv4-compatible style instead of the the ::ffff:mapped style.

This post is about how you get it to work.

In this scenario we have our PE, R1 and the CE, R3.

This is R1’s config.

 set interfaces ge-0/0/2 unit 0 family inet address 172.27.0.5/30
 set interfaces ge-0/0/2 unit 0 family inet6 address ::172.27.0.5/126
 set protocols bgp group ebgp type external
 set protocols bgp group ebgp family inet unicast
 set protocols bgp group ebgp family inet6 unicast
 set protocols bgp group ebgp peer-as 3
 set protocols bgp group ebgp neighbor 172.27.0.6

This is R3’s config

 set interfaces ge-0/0/2 unit 0 family inet address 172.27.0.5/30
 set interfaces ge-0/0/2 unit 0 family inet6 address ::172.27.0.5/126
 set protocols bgp group ebgp type external
 set protocols bgp group ebgp family inet unicast
 set protocols bgp group ebgp family inet6 unicast
 set protocols bgp group ebgp export export-ebgp
 set protocols bgp group ebgp peer-as 701
 set protocols bgp group ebgp neighbor 172.27.0.5
 set policy-options policy-statement export-ebgp term 1 from protocol aggregate
 set policy-options policy-statement export-ebgp term 1 from rib inet6.0
 set policy-options policy-statement export-ebgp term 1 from route-filter 3333:3333::/32 exact
 set policy-options policy-statement export-ebgp term 1 then accept

This is the sad situation on R1 and R3:

 lab@R1&gt; show bgp summary
 172.27.0.6                3         51         53       0       0       20:31 Establ
   inet.0: 0/0/0/0
   inet6.0: 0/0/0/0

 lab@R1&gt; show log messages | grep sanity
 Feb 13 17:15:01  R1 rpd[1131]: bgp_nexthop_sanity: peer 172.27.0.6 (External AS 3) next hop ::ffff:172.27.0.6 unexpectedly remote, ignoring routes in this update

 lab@R3&gt; show log messages | grep sanity
 Feb 13 21:46:27  R3 rpd[1135]: bgp_nexthop_sanity: peer 172.27.0.5 (External AS 701) next hop ::ffff:172.27.0.5 unexpectedly remote, ignoring routes in this update

Per standard, BGP sets the next-hop to it’s IPv4 address using ::ffff ipv4-mapped addressing. If we add “accept-remote-nexthop” R1’s BGP config, we get this:

 lab@R1# activate protocols bgp group ebgp accept-remote-nexthop

 [edit]
 lab@R1# commit and-quit
 commit complete
 Exiting configuration mode

 lab@R1&gt; show bgp summary
 172.27.0.6                3         58         61       0       0       23:06 Establ
   inet.0: 0/0/0/0
   inet6.0: 0/1/1/0

 lab@R1&gt; show route resolution unresolved
 Tree Index 1
 Tree Index 2
 Tree Index 3
 3333:3333::/32
         Protocol Nexthop: ::ffff:172.27.0.6
         Indirect nexthop: 0 -

We now see the route but it is not resolvable. So to fix it, we need to change the next hop to the inet6 address assigned to our peering interface. I’m going to fix both directions from R1’s policy since I am assuming no control over R3.

 ## the route we are advertising to R3 comes from IBGP, so we simply adjust the next-hop
 set policy-options policy-statement export-ebgp term reset-v6-nexthop from protocol bgp
 set policy-options policy-statement export-ebgp term reset-v6-nexthop from rib inet6.0
 set policy-options policy-statement export-ebgp term reset-v6-nexthop then next-hop ::172.27.0.5

 ## we do similar handing for routes received from R3
 set policy-options policy-statement import-ebgp from protocol bgp
 set policy-options policy-statement import-ebgp from rib inet6.0
 set policy-options policy-statement import-ebgp from next-hop ::ffff:172.27.0.6
 set policy-options policy-statement import-ebgp then next-hop ::172.27.0.6
 set policy-options policy-statement import-ebgp then accept

 ## apply policy configs to bgp
 set protocols bgp group ebgp import import-ebgp
 set protocols bgp group ebgp export export-ebgp

After we commit this config change on R1, we now have reachability both ways.

 lab@R1&gt; show bgp summary
 Groups: 2 Peers: 2 Down peers: 0
 Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
 inet.0                 0          0          0          0          0          0
 inet6.0                2          2          0          0          0          0
 Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
 10.255.1.32             701         94         97       0       0       41:04 Establ
   inet.0: 0/0/0/0
   inet6.0: 1/1/1/0
 172.27.0.6                3         67         71       0       0       27:15 Establ
   inet.0: 0/0/0/0
   inet6.0: 1/1/1/0

 lab@R1&gt; show route table inet6 3333:3333::/32

 inet6.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
 + = Active Route, - = Last Active, * = Both

 3333:3333::/32     *[BGP/170] 00:04:18, localpref 100, from 172.27.0.6
                       AS path: 3 I
                     &gt; to ::172.27.0.6 via ge-0/0/2.0

And R3.

 lab@R3&gt; show bgp summary
 Groups: 1 Peers: 1 Down peers: 0
 Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
 inet.0                 0          0          0          0          0          0
 inet6.0                1          1          0          0          0          0
 Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
 172.27.0.5              701         77         72       0       0       29:23 Establ
   inet.0: 0/0/0/0
   inet6.0: 1/1/1/0

 lab@R3&gt; show route protocol bgp

 inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

 inet6.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
 + = Active Route, - = Last Active, * = Both

 4444:4444::/32     *[BGP/170] 00:02:55, localpref 100, from 172.27.0.5
                       AS path: 701 4 I
                     &gt; to ::172.27.0.5 via ge-0/0/1.0


 lab@R3&gt; show route protocol bgp detail

 inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

 inet6.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
 4444:4444::/32 (1 entry, 1 announced)
         *BGP    Preference: 170/-101
                 Next hop type: Router, Next hop index: 587
                 Address: 0x934c688
                 Next-hop reference count: 2
                 Source: 172.27.0.5
                 Next hop: ::172.27.0.5 via ge-0/0/1.0, selected
                 State: 
                 Local AS:     3 Peer AS:   701
                 Age: 3:22
                 Task: BGP_701.172.27.0.5+52965
                 Announcement bits (1): 0-KRT
                 AS path: 701 4 I Aggregator: 4 10.255.1.34
                 Accepted
                 Localpref: 100
                 Router ID: 10.255.1.31

There you have it: accept-remote-nexthop, and some resetting of the next-hop works by either import or export policy.

JNCIE-SP: Using help from the Junos CLI

One of the tools at your disposal during the JNCIE-SP exam is the JUNOS CLI itself and there is an awful lot of documentation stored in it.

Help Apropos

The first tool you will need to learn how to use to take advantage of this is “help apropos XXX”.

Here are a couple of example outputs:

 lab@R1&gt; help apropos anycast                       
 help topic pim examples anycast 
     Overview of anycast RP example
 help reference pim local-address 
     Local address for anycast rendezvous point
 help reference pim address-anycast 
     Anycast rendezvous point addresses in RP set
 help reference pim anycast-pim 
     Anycast rendezvous point using PIM
 help reference pim rp-set 
     Set of up to 15 rendezvous point addresses for anycast RP

 lab@R1&gt; help apropos interpro 
 help topic layer3-vpns examples-cofc 
     Sample interprovider and carrier-of-carriers VPNs
 help topic layer3-vpns examples-cofc interprovider-ebgp 
     Overview of interprovider with multihop MP-EBGP
 help topic layer3-vpns examples-cofc interprovider-isp 
     Overview of interprovider with MP-EBGP between ISP peers
 help topic layer3-vpns examples-cofc terms 
     Terms in carrier-of-carriers and interprovider examples
 help topic layer3-vpns interprovider 
     Overview of interprovider VPNs

As you can see above, “help apropos…” acts as a sort of keyword search for the help system.

Beyond that, “help apropos…” can provide a context-sensitive search CLI commands.

Operational

 lab@R1&gt; help apropos pfe      
 clear pfe 
     Clear Packet Forwarding Engine information
 show pfe 
     Show Packet Forwarding Engine information
 show pfe version 
     Show pfe version
 ...

lab@R1&gt; help apropos uptime      
show system uptime
    Show time since system and processes started
show chassis pic
    Show Physical Interface Card state, type, and uptime

Configuration

 [edit protocols bgp]
 lab@R1# help apropos override 
 set group  as-override 
     Replace neighbor AS number with our AS number
 set group  neighbor <address> as-override 
     Replace neighbor AS number with our AS number

 [edit policy-options]
 lab@R1# help apropos route-type 
 set policy-statement  term  from route-type 
     Route type
 set policy-statement  from route-type 
     Route type

Help Reference and Help Topic

Your mileage will vary with these help outputs. The output seems to be nearly verbatim copy from the JUNOS documentation. Where you would normally have images, you instead find a URL for a GIF. That may not turn out to be too helpful for someone who is completely blanking on how to configure something but if you forget a detail or two, it can probably save you a lot of time.

For instance, I forgot about which MPLS TTL mechanism supported LDP. So I ran a search and pulled up the reference for no-propagate-ttl

 lab@R1&gt; help apropos no-prop                  
 help topic mpls no-propagate-ttl 
     TTL value is decremented by 1 only
 help reference mpls no-propagate-ttl 
     TTL value is set to 255

 lab@R1&gt; help reference mpls no-propagate-ttl 
 ...

     Description

    Disable normal TTL decrementing. You configure this statement once per
    router, and it affects all RSVP-signaled or LDP-signaled LSPs. When this
    router acts as an ingress router for an LSP, it pushes an MPLS header with
    a TTL value of 255, regardless of the IP packet TTL. When the router acts
    as the penultimate router, it pops the MPLS header without writing the
    MPLS TTL into the IP packet.

By chance, this happened to be the correct one to configure to support LDP.

There is some seriously detail information available if you need it. For an example, see “help topic pim auto-rp”. It tells you just about every step you need to configure.

Good luck!

JNCIE-SP Notes on Configuring BGP for IPv6 Unicast NLRI over an IPv4 Peering session

When configuring MP-BGP over an ipv4 peering session, you probably already know that you have to enable family inet6 on your interface. But you also have to make sure to configure an ipv4-mapped inet6 address for your interface because your Juniper device will probably be setting the next-hop to that address unless you’re running older code.

Here is an example of config to get you going.

Diagram

diagram

R2 Config

set interfaces ge-0/0/0 description “Connection to R1”
set interfaces ge-0/0/0 unit 0 family inet address 172.27.0.2/30
set interfaces ge-0/0/0 unit 0 family inet6 address ::ffff:172.27.0.2/126
set protocols bgp group R1-R2 type external
set protocols bgp group R1-R2 family inet unicast
set protocols bgp group R1-R2 family inet6 unicast
set protocols bgp group R1-R2 peer-as 1
set protocols bgp group R1-R2 neighbor 172.27.0.1

R1 Config

set interfaces ge-0/0/0 description “Connection to R2”
set interfaces ge-0/0/0 unit 0 family inet address 172.27.0.1/30
set interfaces ge-0/0/0 unit 0 family inet6 address ::ffff:172.27.0.1/126
set protocols bgp group R1-R2 type external
set protocols bgp group R1-R2 family inet unicast
set protocols bgp group R1-R2 family inet6 unicast
set protocols bgp group R1-R2 peer-as 2
set protocols bgp group R1-R2 neighbor 172.27.0.2

One Last Note

You may need an extra bit of config to get your router to forward packets addressed to ipv4-mapped-addresses:

set system allow-v4mapped-packets

IPv4-Compatible Addressing… A Possible Pitfall

Older versions of JUNOS used IPv4-Compatible addresses for the next-hop field of a BGP update. This would have been something like “::172.27.0.1”.

If you try to configure IPv4-compatible addresses on your interfaces, you will probably see a log message which looks like this:

Jan 16 13:19:02  mrgarrison rpd[1197]: bgp_nexthop_sanity: peer 172.27.0.1 (External AS 701) next hop ::ffff:172.27.0.1 unexpectedly remote, ignoring routes in this update.

Do yourself a favor and check your logs for sanity messages if it looks like you’re not receiving any IPv6 routes that the other route claims it is advertising.

See also: JNCIE-SP: IPv6 NLRIs over IPv4 BGP Peering When You’re Not Using Mapped Addresses.

JNCIE-SP Notes on BGP Troubleshooting

General tips
 - Get to know the diagram/topology.  Mark it up: add notes and draw AS boundaries so that you don’t get your numbers mixed up.
 - Read the requirements carefully and, as you are reading, start forming a list of requirements to validate.
 - Traceoptions will probably take too long to be useful so if you can use show commands, the messages log, or “monitor traffic…” you are better off.

Getting Established - IBGP
 - Check pings from all loopbacks, to all other loopbacks.  Remember to specify the loopback address as the source or “set system default-address-selection”.
 - Be prepared to troubleshoot the IGP and protocol-independent routing configs.
 - For adjacency issues, check the messages log and grep on the host IP.
 - Misconfigured authentication may cause problems.

Getting Established - EBGP
 - As with IBGP, check pings and look in the messages log for entries matched against the peer address.
 - Make sure multihop is configured where needed and supporting static routes are active.
 - Prefix limits can make for problems staying established.  These are logged in “messages”.
 - Look for mismatched AS configurations.

Verifying Policy and Routing
 - Hopefully you took good notes on which peers must be preferred over others because that will come in handy now.
 - Use “show route receive-protocol bgp <neighbor_addr> all” to identify key routes that you can use to verify that prefixes are received and reachable from your whole network.  Make sure you check against the requirements so that you don’t pick a route that is supposed to be filtered.
 - Use “show route resolution unresolved” to deal with problems with unresolvable next-hops.
 - Use “show route receive-protocol bgp <neighbor_addr> hidden” to verify that the policy is not filtering routes which should be permitted per the requirements.
 - Verify that advertisements to customers are as expected:
   * Summary Aggregates may need to be advertised, possibly with specific routes suppressed.
   * a missing address-family configuration in BGP may mean that you are not advertising IPv6 when you need to.  ditto IPv4.


JNCIE-SP / JNCIP-SP - Notes on OSPF Area types using Juniper's Vernacular

Notes from studying and discussion of OSPF Areas for the JNCIE-SP and JNCIP-SP exams.

Stub Areas

Stub - Do not permit OSPF External routes (Type 5 LSAs) into the area.  Re-generate OSPF Internal routes as Summary Type 3 LSAs.

Stub w/ default metric XXX - Same as above, but advertise a Type 3 Summary default-route into the area with metric XXX to reach external routes.

Stub, no-summaries, default metric XXX (aka Totally Stubby Area) - Do not permit OSPF internal or external routes into the area.  Instead, advertise a Type 3 Summary default-route with metric XXX.

===

Not-So-Stubby-Areas

NSSA - Fundamentally similar to Stub Area (see above), but ASBR can reside within the area and generates an NSSA External Type 7 LSA for each route exported into OSPF.  Type 7s are regenerated as Type 5s into the backbone area by the ABR.

NSSA w/ default-lsa default-metric XXX - Same as above, but advertise a Type 3 Summary default-route into the area with metric XXX to reach external routes.

NSSA, no-summaries, default metric XXX - Do not permit OSPF internal or external routes into the area.  Instead, advertise a Type 3 Summary default-route with metric XXX.  ASBR can reside within the area…

Optional configuration for NSSA: -
  default-lsa {
    default-metric XXX;
    metric-type YYY;
    type-7;

  }
NSSA default-routes can be generated as Type 7 for backward compatibility.  This affords you the opportunity to set the external metric-type as “1” if you want one to be preferred when available.

==

References

 - Examples: Configuring OSPF Stub and Not-So-Stubby Areas - http://www.juniper.net/techpubs/en_US/junos11.4/topics/topic-map/ospf-stub-and-not-so-stubby-areas.html