Vagrant and Juniper's Firefly Perimeter

Looks like Juniper is working hard to get their Firefly perimeter usable on Vagrant. See also, the firefly-packer github for info and caveats.

fluong@fluong-ltm:vagrant$ mkdir firefly010
fluong@fluong-ltm:vagrant$ cd firefly010/
fluong@fluong-ltm:firefly010$ ls
fluong@fluong-ltm:firefly010$ vagrant init juniper/ffp-12.1X46-D20.5
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
fluong@fluong-ltm:firefly010$ ls
Vagrantfile
fluong@fluong-ltm:firefly010$ vim Vagrantfile
fluong@fluong-ltm:firefly010$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'juniper/ffp-12.1X46-D20.5' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'juniper/ffp-12.1X46-D20.5'
    default: URL: https://vagrantcloud.com/juniper/ffp-12.1X46-D20.5
==> default: Adding box 'juniper/ffp-12.1X46-D20.5' (v0.1.2) for provider: virtualbox
    default: Downloading: https://vagrantcloud.com/juniper/boxes/ffp-12.1X46-D20.5/versions/3/providers/virtualbox.box
    default: Progress: ##########################################################==> default: Successfully added box 'juniper/ffp-12.1X46-D20.5' (v0.1.2) for 'virtualbox'!
==> default: Importing base box 'juniper/ffp-12.1X46-D20.5'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'juniper/ffp-12.1X46-D20.5' is up to date...
==> default: Setting the name of the VM: firefly010_default_1411482071141_14275
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: No guest additions were detected on the base box for this VM! Guest
    default: additions are required for forwarded ports, shared folders, host only
    default: networking, and more. If SSH fails on this machine, please install
    default: the guest additions and repackage the box to continue.
    default:
    default: This is not an error message; everything may continue to work properly,
    default: in which case you may ignore this message.
fluong@fluong-ltm:firefly010$ vagrant ssh
--- JUNOS 12.1X46-D20.5 built 2014-05-14 20:38:10 UTC
vagrant>

vagrant> show interfaces terse
Interface               Admin Link Proto    Local                 Remote
ge-0/0/0                up    up
ge-0/0/0.0              up    up   inet     10.0.2.15/24
gr-0/0/0                up    up
ip-0/0/0                up    up
lsq-0/0/0               up    up
lt-0/0/0                up    up
mt-0/0/0                up    up
sp-0/0/0                up    up
sp-0/0/0.0              up    up   inet
                                   inet6
sp-0/0/0.16383          up    up   inet     10.0.0.1            --> 10.0.0.16
                                            10.0.0.6            --> 0/0
                                            128.0.0.1           --> 128.0.1.16
                                            128.0.0.6           --> 0/0
dsc                     up    up
gre                     up    up
ipip                    up    up
lo0                     up    up
lo0.16384               up    up   inet     127.0.0.1           --> 0/0
lo0.16385               up    up   inet     10.0.0.1            --> 0/0
                                            10.0.0.16           --> 0/0
                                            128.0.0.1           --> 0/0
                                            128.0.0.4           --> 0/0
                                            128.0.1.16          --> 0/0
lo0.32768               up    up
lsi                     up    up
mtun                    up    up
pimd                    up    up
pime                    up    up
pp0                     up    up
ppd0                    up    up
ppe0                    up    up
st0                     up    up
tap                     up    up
vlan                    up    down

#JUNOS - Recovering from Alternate Media (YMMV)

Had a situation at work where I had to remind myself of something so that means it’s time for a new blog post.

--- JUNOS 12.3R3.4 built 2013-06-14 00:09:12 UTC
---
--- NOTICE: System is running on alternate media device      (/dev/ad1s1a).
---

fluong@tickle-me-elmo-re0> show system storage | no-more 
Filesystem              Size       Used      Avail  Capacity   Mounted on
/dev/ad1s1a             3.5G       283M       3.1G        8%  / <<<<<
devfs                   1.0K       1.0K         0B      100%  /dev
/dev/md0                 41M        41M         0B      100%  /packages/mnt/jbase
/dev/md1                 32M        32M         0B      100%  /packages/mnt/jkernel64-12.1R1.9
/dev/md2                 73M        73M         0B      100%  /packages/mnt/jpfe-X960-12.1R1.9
/dev/md3                5.0M       5.0M         0B      100%  /packages/mnt/jdocs-12.1R1.9
/dev/md4                 78M        78M         0B      100%  /packages/mnt/jroute-12.1R1.9
/dev/md5                 28M        28M         0B      100%  /packages/mnt/jcrypto64-12.1R1.9
/dev/md6                 46M        46M         0B      100%  /packages/mnt/jpfe-common-12.1R1.9
/dev/md7                388M       388M         0B      100%  /packages/mnt/jruntime-12.1R1.9
/dev/md8                7.9G        22K       7.2G        0%  /tmp
/dev/md9                7.9G        15M       7.2G        0%  /mfs
/dev/ad1s1e             394M        42K       390M        0%  /config
procfs                  4.0K       4.0K         0B      100%  /proc
/dev/ad1s1f              18G       2.3G        14G       14%  /var

Here’s the initial scenario. Routing-Engine re0 is booting from alternate media. IN MOST CASES this means a compact-flash on the routing has gone bad and has to be replaced by RMA, but in this case I happen to know that it’s a new RE and we had a USB install that went south. Keep this in mind and know that your mileage may vary with this one.

Other interesting considerations for this scenario is that for this router, a remote hands technician is not on site so we don’t have cheap easy options to do another USB install. Luckily JUNOS provides a means to rewrite the image on the compact-flash if you’re able to boot off the HDD/SSD: “request system snapshot partition”

{backup}
root@tickle-me-elmo-re0> request system snapshot partition
Clearing current label...
Partitioning compact-flash media (ad0) ...
Partitions on snapshot:

  Partition  Mountpoint  Size    Snapshot argument
      a      /           671MB   root-size
      e      /config     400MB   config-size
      f      /var        2GB     var-size
Running newfs (671MB) on compact-flash media  / partition (ad0s1a)...
Running newfs (400MB) on compact-flash media  /config partition (ad0s1e)...
Running newfs (2GB) on compact-flash media  /var partition (ad0s1f)...
Copying '/dev/ad1s1a' to '/dev/ad0s1a' .. (this may take a few minutes)
Copying '/dev/ad1s1e' to '/dev/ad0s1e' .. (this may take a few minutes)
The following filesystems were archived: / /config

{backup}
root@tickle-me-elmo-re0> exit

We verify that the compact-flash is in the boot list before rebooting.

root@tickle-me-elmo-re0% sysctl machdep.bootdevs
machdep.bootdevs: usb,compact-flash,disk1,disk2,lan

root@tickle-me-elmo-re0% cli req sys reboot

*** FINAL System shutdown message from root@tickle-me-elmo-re0 ***            

System going down IMMEDIATELY

When your router boots next time, you should be able to verify that the root “/” partition is /dev/ad0xxx (for RE-S-1800). (marked below with “<<<<<<”)

fluong@tickle-me-elmo-re0> show system storage | no-more 
Filesystem              Size       Used      Avail  Capacity   Mounted on
/dev/ad0s1a             3.5G       272M       2.9G        8%  / <<<<<<
devfs                   1.0K       1.0K         0B      100%  /dev
/dev/md0                 40M        40M         0B      100%  /packages/mnt/jbase
/dev/md1                 19M        19M         0B      100%  /packages/mnt/jkernel64-11.4R3.7
/dev/md2                 60M        60M         0B      100%  /packages/mnt/jpfe-X960-11.4R3.7
/dev/md3                5.0M       5.0M         0B      100%  /packages/mnt/jdocs-11.4R3.7
/dev/md4                 78M        78M         0B      100%  /packages/mnt/jroute-11.4R3.7
/dev/md5                 28M        28M         0B      100%  /packages/mnt/jcrypto64-11.4R3.7
/dev/md6                 45M        45M         0B      100%  /packages/mnt/jpfe-common-11.4R3.7
/dev/md7                382M       382M         0B      100%  /packages/mnt/jruntime-11.4R3.7
/dev/md8                7.9G        18K       7.2G        0%  /tmp
/dev/md9                7.9G       744K       7.2G        0%  /mfs
/dev/ad0s1e             393M        44K       362M        0%  /config
procfs                  4.0K       4.0K         0B      100%  /proc
/dev/ad1s1f              18G       1.7G        15G       10%  /var

#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)

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: 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!

JUNOS - Using The 'chassisd' Log To Determine Boot Times

You can use “show system uptime” to determine the time that the system last booted but if you need to know about how long the system was up prior to the last boot you have to dig a bit deeper.

 fluong@re0.mx960-1.eng> show system uptime 
 Feb 01 11:26:13
 Current time: 2013-02-01 11:26:13 EST
 System booted: 2013-01-04 10:34:28 EST (4w0d 00:51 ago)
 Protocols started: 2013-02-01 11:17:44 EST (00:08:29 ago)
 Last configured: 2013-02-01 11:17:45 EST (00:08:28 ago) by root
 11:26AM  up 28 days, 52 mins, 1 user, load averages: 0.02, 0.15, 0.13

The “messages” log, though handy, is also very noisy. Because of this, we can try to use the “chassisd” log instead and look for the “built by” string, which occurs each time the chassis control process initiates itself.

That line, unfortunately, is on the line after the timestamp, so we need some other nearby log messages to determine the rough time of system startup.

Also important to note is that the “built by” string occurs when you “restart chassis-control”, so we need to inspect those logs to see if a SIGTERM occurred within seconds of chassisd restarting. If it is a few minutes apart, that is probably a reboot. If it is seconds apart, that means someone triggered a process restart.

 fluong@re0.mx960-1.eng> show log chassisd | match "(built by|rtsock_init s|sigterm)" 
 Feb 01 11:28:45
 Dec 19 11:14:52 CHASSISD_TERM_SIGNAL: Received SIGTERM request, shutting down
 Dec 19 11:14:58 CHASSISD_TERM_SIGNAL: Received SIGTERM request, shutting down
 CHASSISD release 10.4R3.4 built by builder on 2011-03-19 21:10:47 UTC
 Dec 19 11:22:37 rtsock_init synchronous socket
 Jan  4 10:27:25 CHASSISD_TERM_SIGNAL: Received SIGTERM request, shutting down
 Jan  4 10:27:31 CHASSISD_TERM_SIGNAL: Received SIGTERM request, shutting down
 CHASSISD release 11.4R6.5 built by builder on 2012-11-28 21:35:45 UTC
 Jan  4 10:35:54  rtsock_init synchronous socket
 Feb  1 11:17:31 CHASSISD_TERM_SIGNAL: Received SIGTERM request, shutting down
 CHASSISD release 11.4R6.5 built by builder on 2012-11-28 21:35:45 UTC
 Feb  1 11:17:32  rtsock_init synchronous socket

We can tell from looking at these logs:

  • System was rebooted and chassisd started on Dec 19 11:22:37. Ditto, Jan 4 10:35:54.
  • “restart chassis-control” was invoked on Feb 1 11:17:31

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.


Juniper Stuff: When you need to know about your pluggable optics

I had a guy ask me today about some funky output he was seeing on his router when he was trying to get info on his SFP optics from “show chassis hardware”.  I directed him instead to check out “show chassis pic fpc-slot <#> pic-slot <#>”.  It’s a lot more detailed and reliable.

–

user@host> show chassis pic fpc-slot 4 pic-slot 1
FPC slot 4, PIC slot 1 information:
  Type                             10x 1GE(LAN)
  State                            Online    
  PIC version                  0.0
  Uptime                         18 days, 5 hours, 41 minutes, 54 seconds

PIC port information:
                          Fiber                    Xcvr vendor
  Port  Cable type        type  Xcvr vendor        part number       Wavelength
  0     SFP-1000BASE-BX10-D SM  SumitomoElectric   SBP6H44-J3-BW-49  1490 nm 
  1     SFP-1000BASE-BX10-D SM  SumitomoElectric   SBP6H44-J3-BW-49  1490 nm 
  2     SFP-1000BASE-BX10-D SM  SumitomoElectric   SBP6H44-J3-BW-49  1490 nm 
  3     SFP-1000BASE-BX10-D SM  OCP                TRXBG1LXDBVM2-JW  1490 nm 
  4     SFP-1000BASE-BX10-D SM  OCP                TRXBG1LXDBVM2-JW  1490 nm 
  5     SFP-1000BASE-BX10-U SM  SumitomoElectric   SBP6H44-J3-BW-31  1310 nm 
  6     SFP-1000BASE-BX10-U SM  SumitomoElectric   SBP6H44-J3-BW-31  1310 nm 
  7     SFP-1000BASE-BX10-U SM  OCP                TRXBG1LXDBBMH-J1  1310 nm 
  8     SFP-1000BASE-BX10-U SM  OCP                TRXBG1LXDBBMH-J1  1310 nm 
  9     SFP-1000BASE-BX10-U SM  SumitomoElectric   SBP6H44-J3-BW-31  1310 nm