The Data Plumber » JunOS

Juniper L2Circuit Config

DataPlumber — Thu, 03 Jan 2008 10:36:51 +0000

Just posting a basic l2circuit configuration for my own reference… Piece of cake really, but it won’t work unless you use a dynamic routing protocol – the static that I had configured wasn’t enough.

In the below snippet of config, the fe-0/0/1 interface is the customer-facing interface, and fe-0/0/0 is the ISP side. Customer traffic is expected with a VLAN tag of 512.

set version 8.3R2.8 set interfaces fe-0/0/0 unit 0 family inet address 192.168.0.1/24 set interfaces fe-0/0/0 unit 0 family mpls set interfaces fe-0/0/1 vlan-tagging set interfaces fe-0/0/1 speed 100m set interfaces fe-0/0/1 link-mode full-duplex set interfaces fe-0/0/1 encapsulation vlan-ccc set interfaces fe-0/0/1 unit 0 vlan-id 1 set interfaces fe-0/0/1 unit 100 encapsulation vlan-ccc set interfaces fe-0/0/1 unit 100 vlan-id 512 set interfaces lo0 unit 0 family inet address 127.0.0.1/32 set interfaces lo0 unit 0 family inet address 10.1.1.2/32 primary set routing-options static route 0.0.0.0/0 next-hop 192.168.0.2 set protocols mpls interface all set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface fe-0/0/0.0 set protocols ldp interface all set protocols l2circuit neighbor 10.1.1.1 interface fe-0/0/1.100 virtual-circuit-id 2 set protocols l2circuit neighbor 10.1.1.1 interface fe-0/0/1.100 no-control-word

These routers were just back-to-back, so it was a pretty simple layout. Once the other side was configured and there was carrier on the customer ports, the circuit came up. Check it using the following command:

root# run show l2circuit connections Layer-2 Circuit Connections: - Legend for connection status (St) EI -- encapsulation invalid NP -- interface h/w not present MM -- mtu mismatch Dn -- down EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down CM -- control-word mismatch Up -- operational VM -- vlan id mismatch CF -- Call admission control failure OL -- no outgoing label XX -- unknown NC -- intf encaps not CCC/TCC CB -- rcvd cell-bundle size bad - Legend for interface status Up -- operational Dn -- down Neighbor: 10.1.1.1 Interface Type St Time last up # Up trans fe-0/0/1.100(vc 2) rmt Up Jan 3 18:12:44 2008 1 Local interface: fe-0/0/1.100, Status: Up, Encapsulation: VLAN Remote PE: 10.1.1.1, Negotiated control-word: No Incoming label: 100000, Outgoing label: 100000

Juniper J-series upgrade to 8.4R2.3

DataPlumber — Fri, 28 Sep 2007 03:33:40 +0000

We’ve just been in the lab trying to get a router upgraded from 8.2 to the latest 8.4R2.3, and have been having some issues…

JunOS 8.4R2.3 is just out, and we need it for a customer who is having repeated crashes of the fwdd daemon under 8.3R2.8. Here is a chop from the messages log file that shows fwdd crashing:

Sep 26 04:07:40.109 juniper fwdd[4567]: smpmutex_lock() called from unix context (ra = 0x808e0ef) Sep 26 04:07:40.129 juniper fwdd[4567]: smpmutex_unlock() called from unix context (ra = 0x808e124) Sep 26 04:07:40.129 juniper fwdd[4567]: smpmutex_lock() called from unix context (ra = 0x808e0ef) Sep 26 04:07:40.129 juniper fwdd[4567]: smpmutex_unlock() called from unix context (ra = 0x808e124) Sep 26 04:07:40.130 juniper fwdd[4567]: smpmutex_lock() called from unix context (ra = 0x808e0ef) Sep 26 04:07:40.130 juniper fwdd[4567]: smpmutex_unlock() called from unix context (ra = 0x808e124) Sep 26 04:08:15.153 juniper /kernel: psdd 1 (0xc1ff4000): exception 0xe in fwdd (pid 4567) at 0x818beea (0x818beea); killing Sep 26 04:08:15.153 juniper /kernel: CPU=0 eip=0818beea eflags=00010206 Sep 26 04:08:15.153 juniper /kernel: eax: 00000000 ebx: 00000002 ecx: 0000003d edx: 4cbd0084 Sep 26 04:08:15.153 juniper /kernel: esi: 0000003a edi: 00000002 ebp: 4a449324 esp: 4a4492ac Sep 26 04:08:15.153 juniper /kernel: ds: 4a44002f es: 4a44002f ss: 002f cs: 001f Sep 26 04:08:15.153 juniper /kernel: Start of stack for thread 0xc1ff4000: Sep 26 04:08:15.153 juniper /kernel: Frame 0: sp = 0x4a449324, pc = 0x818beea Sep 26 04:08:15.154 juniper /kernel: Frame 1: sp = 0x4a449344, pc = 0x819974c Sep 26 04:08:15.154 juniper /kernel: Frame 2: sp = 0x4a449384, pc = 0x81aa357 Sep 26 04:08:15.154 juniper /kernel: Frame 3: sp = 0x4a449624, pc = 0x80d0eea Sep 26 04:08:15.154 juniper /kernel: Frame 4: sp = 0x4a449664, pc = 0x80b4584 Sep 26 04:08:15.154 juniper /kernel: End of stack Sep 26 04:08:15.153 juniper fwdd[4567]: -------------------------------------- Sep 26 04:08:15.153 juniper fwdd[4567]: Bus error! Sep 26 04:08:15.153 juniper fwdd[4567]: Registers: Sep 26 04:08:17.490 Sep 26 04:08:17.490 juniper /kernel: pfe_send_failed(index 0, type 10), err=32 Sep 26 04:08:17.490 juniper /kernel: pfe_listener_disconnect: conn dropped: listener idx=0, tnpaddr=0x1, reason: socket error Sep 26 04:08:17.548 juniper chassisd[2918]: CHASSISD_FRU_OFFLINE_NOTICE: Taking FPC 0 offline: Error Sep 26 04:08:17.548 juniper chassisd[2918]: CHASSISD_IFDEV_DETACH_FPC: ifdev_detach(0) Sep 26 04:08:17.568 juniper chassisd[2918]: CHASSISD_IPC_WRITE_ERR_NULL_ARGS: FRU has no connection arguments fru_send_msg FWDD Sep 26 04:08:17.631 juniper init: forwarding (PID 4567) terminated by signal number 10. Core dumped! Sep 26 04:08:17.632 juniper init: forwarding (PID 4637) started /kernel: pfe_send_failed(index 0, type 10), err=32 Sep 26 04:08:17.490 juniper /kernel: pfe_listener_disconnect: conn dropped: listener idx=0, tnpaddr=0x1, reason: socket error Sep 26 04:08:17.548 juniper chassisd[2918]: CHASSISD_FRU_OFFLINE_NOTICE: Taking FPC 0 offline: Error Sep 26 04:08:17.548 juniper chassisd[2918]: CHASSISD_IFDEV_DETACH_FPC: ifdev_detach(0) Sep 26 04:08:17.568 juniper chassisd[2918]: CHASSISD_IPC_WRITE_ERR_NULL_ARGS: FRU has no connection arguments fru_send_msg FWDD Sep 26 04:08:17.631 juniper init: forwarding (PID 4567) terminated by signal number 10. Core dumped! Sep 26 04:08:17.632 juniper init: forwarding (PID 4637) started

Not very nice – you can see an exception occurring in fwdd, and the process is killed. It then does a stack dump and writes some stuff to the logs. The PFE then detaches, and the fwdd process is restarted. When this is happening you lose your telnet session.

So… Juniper kindly brought out 8.4r2.3 with a fix for this in it. (The previous version – 8.4r1 – didn’t have it). But we ran into another issue. Even a unit with a mostly blank config on it (just an IP address and root password) would not take the software – it complained that there was a configuration incompatibility and that the check-out failed for the Chassis control process.

Here’s the output found in /cf/var/log/install:

Checking compatibility with configuration Initializing... Verified manifest signed by PackageProduction_8_2_0 Using /var/tmp/junos-jseries-8.4R2.3-export.tgz Checking junos requirements on / Available space: 133919 require: 51215 Verified manifest signed by PackageProduction_8_4_0 mtree: line 57: unknown user ext mtree: line 57: unknown user ext Hardware Database regeneration succeeded Validating against /config/juniper.conf.gz http://xml.juniper.net/xnm/1.1/xnm" xmlns:xnm="http://xml.juniper.net/xnm/1.1/xnm">; Couldn't open /packages/mnt mgd: error: Check-out failed for Chassis control process (/usr/sbin/chassisd) without details mgd: error: configuration check-out failed Validation failed WARNING: Current configuration not compatible with /var/tmp/junos-jseries-8.4R2.3-export.tgz 1 root@% cli root>

Turns out, this is an additional bug – documented under PR 237369. The upgrade is failing in the Validate part. There’s no software fix for this at the moment. You just have to do the upgrade on the CLI only, and use the ‘no-validate’ command:

juniper> request system software add /var/tmp/junos-jseries-8.4R2.3-domestic.tgz no-validate

While JTAC were coming up with this answer, however, my colleague managed to upgrade to 8.3, and from there to 8.4. It moaned about the config not being compatible, but worked anyway. We loaded the customer’s config on using ‘load override’ and it complained about there being an incompatibility in one line. We committed it, and then did a diff on the before and after configs – the only line that was different was the encrypted password for the root user. I wonder if they changed the encryption algorithm in this new version or something…

I’ll have to ask if these bugs affect the M and T series of routers. Something for tomorrow morning I think.

Exclusive configuration in IOS and JunOS

DataPlumber — Thu, 01 Feb 2007 20:03:19 +0000

Juniper certainly seem to lead Cisco in certain areas sometimes.

If there’s a chance that more than one person can be changing a router’s configuration at the same time, you can get yourself into trouble. JunOS is quite good in that it tells you as you go into edit mode whether someone else is already modifying the configuration. Of course you could forget that someone is already in there, so it could be a good idea to get into the habit of using one of the two following commands:

configure exclusive configure private

The “exclusive” keyword locks the candidate configuration and prevents anyone else making changes while you are editing. The “private” keyword is even better – it permits userA and userB to be in edit mode at the same time, while allowing each user to commit their own changes.

Cisco (I believe) didn’t have a feature like this until recently. Now you can do a something similar in IOS too. If you enter the command:
configuration mode exclusive auto
in global configuration mode, this makes all configuration sessions exclusive by default.

Should you want the configuration locking to be optional, use “manual” instead of auto. From then on, when going into configuration mode, you need to type “conf t lock” to set the configuration lock.

I see from the Cisco command reference that this is a 12.3(14)T or later feature, so you may not get it without an IOS upgrade.

Don’t Cut Your Own Legs Off – IOS and JunOS

DataPlumber — Thu, 01 Feb 2007 19:40:45 +0000

I guess every engineer knows that heart-stopping moment when you change something on a remote router and the telnet session you are using stops responding. You hit a few keys in the folorn hope that it is a bit of network congestion before resigning yourself to the fact that you’ve just been a complete idiot and removed the IP address you were telnetting in through.

Juniper built JunOS from the ground up with features to counter things like this. In JunOS, when you go into editing mode, a copy of the current configuration is taken and becomes what is called the “candidate configuration”. It is this that gets edited, and when you are happy with your changes, you issue the “commit” command. The candidate configuration becomes the current configuration, and the old current configuration is stored as a “rollback configuration”. Of course if you’ve made a mistake, it is at this point that your telnet session goes dead.

If you use the “commit confirmed” command, however, the router implements the configuration and waits for a second “commit” command. If it doesn’t get one within a set period, it assumes you have lost connectivity and rolls the configuration back to the previously working config. A nice feature.

Now IOS doesn’t do this, unfortunately. What you can do, however, if you are making what might be a risky change, is to use the “reload in ” command. Here’s what you do:

Enter privileged exec mode
Issue the command “reload in 10″ to give yourself 10 minutes
Make your changes in configuration mode
If you didn’t cut yourself off, you’re ok. Cancel the reload using “cancel reload”
Write your config to flash

If you prefer, you can reload at a specific time – “reload at 19:00″ will reload the router at 7pm. It is probably wise to check that your clock is right before you do this though.

And finally, a “show reload” will tell you if there are any outstanding reloads pending.

This parameter on the end of the reload command seems to have been around for a few years (at least since 12.1 mainline), but I’ve never seen anyone else using it.