System time:  Thu/12/24 : 03:02:29

Gone Going

'Nuff said.

2nite

I've toyed with buliding a dedicated SSH client box at the office off and on, in hopes that every time my Windows box crashes, or re-activates and runs automatic updates, I don't have to re-login to a hojillion boxes all over again.
My first attempt failed miserably. I just couldn't get my sessions or programs to stay open on the host box using Xming with, or without an ssh tunnel between reboots / crashes, et al.
The following attempt was far from elegant, but it was GoodEnough™, and consisted of, Xorg, fluxbox, and VNC Server. I'm sure I don't need to go into details as to what's wrong with this solution. Besides which, I was never really happy with the setup.
For version 3, I broke down and read the man-page for tmux, which, in a nutshell, is basically screen except that it doesn't suck. Go figure, the best solution's the simplest one.

I also finally built up the nerve to migrate my minecraft server. Moved it off the barebones Debian VM it was running on, to an OpenBSD VM. I'm not sure why, but I was surprised at how much better the server runs on the new host. I suppose it could have something to do with dropping 100 processes.

Haven't touched Java since my last post... the thought of building a parser and hierarchical syntax checks feels somewhat daunting.

Been using phpipam at the office since around v0.5. Updated to 0.9 shortly after it came out. The 0.9 release includes up/down/last-seen host checks. For a free, open-source tool, it's pretty epic.
That said, setting up the scanning script's not documented anywhere obvious yet that I've been able to find, and a little bit fiddly. Lest I forget what I did...

Some values you might want to change from defaults.

-----e@insight:~ $ diff -u /usr/local/src/phpipam-0.9/functions/scan/config-scan.php \
/var/apache2/htdocs/phpipam/functions/scan/config-scan.php
--- /usr/local/src/phpipam-0.9/functions/scan/config-scan.php   Thu Jan 23 19:11:50 2014
+++ /var/apache2/htdocs/phpipam/functions/scan/config-scan.php  Mon Dec 30 23:09:08 2013
@@ -8,11 +8,11 @@

//general configs
$scanMaxHosts   = 32; // maximum number of scans per once
-$scanDNSresolve = true;        // try to resolve DNS name
+$scanDNSresolve = false;       // try to resolve DNS name
$scanIPv6       = false; // not yet

//configs
-$MAX_THREADS = 256; // set max concurrent threads
+$MAX_THREADS = 128; // set max concurrent threads

// ping path
$pathPing = "/sbin/ping";

-----e@insight:~ $ diff -u /usr/local/src/phpipam-0.9/functions/scripts/pingCheck.php \
/var/apache2/htdocs/phpipam/functions/scripts/pingCheck.php
--- /usr/local/src/phpipam-0.9/functions/scripts/pingCheck.php  Thu Jan 23 19:11:50 2014
+++ /var/apache2/htdocs/phpipam/functions/scripts/pingCheck.php Fri Dec 27 13:31:56 2013
@@ -11,10 +11,10 @@
*/

// config
-$email = true; //set mail with status diff to admins
+$email = false; //set mail with status diff to admins
$emailText = false; //format to send mail via text or html
//$wait = 500; //time to wait for response in ms
-$count = 1; //number of pings to send
+$count = 2; //number of pings to send

// response
$stateDiff = array(); //Array with differences, can be used to email to admins

By default, no subnets are setup to scan. Poke the bit for any relevant subnets to save updating them manually.

Lucky last, run it in a sensible users crontab. I wound up dropping the priority on this with nice, since the scads of processes I chose to let it spawn tends to cause a noticeable degradation to other http childs.

#mm hh md mo wd
30  *  *  *  *  /path/to/php /path/to/phpipam/functions/scripts/pingCheck.php

And away she goes.

Take me to Heaven

Pak. Chooie. Unf.
Been internet-less at home for as near as makes no difference, a week.
Abnormal service should resume shortly.

Damn. That is one ugly mini.

Iconic

So, happy new year and stuff.
Should probably post something worthwhile sometime soon.
With any luck I'll have something useful to show for my suffering by the end of next month - enthusiasm permitting. Because yeah, I needed yet more random, unfinished junk.

Очень Очень

Happy non-denominational winter holiday
Happy Chalica
Merry Christmas
Happy Kwanza
Merry X-mas

And all that jazz, and stuff, and like, whatever.

You Never Can Tell

Of all the weekends to get almost no sleep. This week is going to suck. Immensely.

Once again, the worlds screwed up digital media distribution channels have left me aghast.
I wanted to buy this. Hell, I'd even buy a complete CD or single filled with useless junk for the one song (Ahhhh... those were the days). But alas, neither of the many available distribution channels had it available for legal acquisition. Granted, the greek store has it listed, but that just drives my point home. It's right there! I probably wouldn't mind so much if the afore-mentioned channels hadn't all but killed retail chains that deal with physical media. At least then I could order the item as an 'import', pay an obscene fee, and expect to have ownership some three and a half weeks later.
Seriously, I'm not the only one.

I received an e-mail from the good folks at Evernote, telling me that adobe.com's list of accounts was compromised.
"Huh. Good for them." I thought. I read on.
"We compared this list to our user email addresses and found that the email address you used to register for an Evernote account is on the list of exposed Adobe accounts."
This has left me wondering what cockamamy 3rd party created an account at adobe.com on my behalf, given I don't own any Adobe products past or present. Best guess is maybe they created an account for me after acquisition of some other product or company, but nothing in their current or unsupported products is relevant to me. My money's on a third party doing it on my behalf though… I recognize some of the bogus information I've given at least one enterprise.
Curious to find out how difficult it is to close the account by phone.
Oh, also - thanks Evernote folks, for doing Adobe's job for them. Either Adobe's too hammered by the recoil of this, or hasn't bothered to inform anyone at all.

Crimson Poenix

Well, I'm completely unenthused, and otherwise bored on the whole. Fair warning this post may have no point what-so-ever as a result of the aforementioned mental-state.

A mysterious grey bar I don't recall seeing appeared at the top of my blog recently. If the file timestamps are to believed, this would have been about the time I was mucking around with some backups. Can't believe I never noticed it before now.
In any event, It was buried deep within the festering pit that is nested style sheets and their irregular hierarchies.
<plug>Not sure if I've mentioned it before or not, but Coda is epic. Fired it up for the first time since the 2.x release for the afore-mentioned irritant, and was able find and squelch it within a couple of clicks. The built-in MySQL editor is also looking pretty handy.</plug>

Random new project, because I don't already have enough half-started things. No idea what will become of it, but have a few ideas.

Also, damn it. I don't even know why I googled it. Oh, that's right... bored.

I have nothing to say about this one, just listen to it. Or don't. Whatever.

Million Voices

Co-worker: How often do you clean your balls?
Me: out of context, that might seem like a peculiar question.
Once every couple months usually, otherwise whenver I notice they start to feel 'sticky'. ie; if there's any resistance starting from no motion.
Co-worker: That answer is better than the question, out of context :)
And now, I give you the context.

That out of the way, it's been one of those nights.
Suffered a colossal brain malfunction trying to redistribute static /32's into my stub area (derp).
Moved on from that and took a stab at trying to improve the efficiency of my VRRP setup, as well as work on ideas to only distribute subnets into OSPF based on VRRP status. While undertaking this task, I ran into a fun problem with scarecrone.
Trying to setup VRRP to use an address applied to a VLAN interface, doesn't appear to be supported. I've not found any documentation that explicitly states this fact either.
Disclaimer: Poorly obfuscated to prevent future confusion when I inevitably reference this.

-----e@scarecrone# run show configuration interfaces vlan.255
description "Public allocation from Initech"
family inet {
    address 1.2.3.2/29 {
        vrrp-group 255 {
            virtual-address 1.2.3.2;
            priority 255;
        }
        vrrp-group 254 {
            virtual-address 1.2.3.1;
            priority 128;
        }
    }
}

[edit interfaces vlan unit 255]
-----e@scarecrone# commit confirmed 1
[edit interfaces vlan unit 255 family inet address 1.2.3.2/29]
  'vrrp-group 255'
    IP address owner priority (255) not supported on this interface
error: configuration check-out failed

[edit interfaces vlan unit 255]
-----e@scarecrone#

This is the closest match to an explanation I've found so far today:

  • You cannot configure a virtual IP address to be the same as the interface’s address for an aggregated Ethernet interface. This configuration is not supported.

ref: http://www.juniper.net/techpubs/software/junos/junos85/swconfig85-high-availability/configuring-basic-vrrp-support.html
Subject to finding a better explanation somewhere, I'm forced to assume that this includes those of the ethernet-switching flavour.
I also find it odd that the JunOS doesn't default to a priority of 255, regardless of what's configured on respective VRRP groups since the parser suggests they are RFC 3768 compliant.

That aside, further testing revealed that this sort of lunacy is at least allowed on subinterfaces performing VLAN encapsulation.

-----e@scarecrone> show configuration interfaces fe-0/0/1   
vlan-tagging;
unit 0 {
    vlan-id 0;
    family inet;
}
unit 255 {
    vlan-id 255;
    family inet {
        address 1.2.3.2/29 {
            vrrp-group 255 {
                virtual-address 1.2.3.2;
                priority 255;
            }
        }
    }
}

So, I guess that means the next step is to try building some bridge-groups off the sub-interface assuming such a thing is possible. Assuming it is, I expect this will raise all kinds of hell with the SRX' Zone Based Firewalling.

Amusingly enough, my 1811 had no problems at all using a VLAN interface parent IP address as a VRRP address.
Game point to Cisco.

Wee!

Skip To The Good Bit

Installed scarecone, re-jigged my esx hosts to use both nic's.

Things I learned;

  • Juniper's reference-bandwidth is skewed. A reference-bandwidth of 1000M in Juniper does not produce the same metrics as 1000M on my 1811 or 2811. Had to crank the Juniper up to 10000M to advertise equivalent metrics.
  • Having an outstanding issue logging into the SRX from Cisco IOS doodads, even though the SRX appears to be using a 1024 bit cipher.

Not sure where the fault lies with the ssh thing yet... could be the Cisco client I suppose. Time will tell.

*Oct 26 22:18:24.404 PDT: SSH2 CLIENT 0:
Invalid modulus length
*Oct 26 22:18:24.404 PDT: SSH CLIENT0: key exchange failure (code = 0)
*Oct 26 22:18:24.404 PDT: SSH CLIENT0: Session disconnected - error 0x00

My next challenges;
Find a way to advertise prefixes based on VRRP status
Get NAT working on the SRX
Piggyback minecraft off an existing VM rather than run on its own
Hook-up touchstone
Get an SSL certificate
Move most of the VM's to myr
Re-build fluctuator with larger drives
And work out how to fit a UPS in the co-lo rack.

This is totally not a music video.
Warning: Tastefully garnished with gratuitous placement of the F word.
Warning Supplimentary: May not actually be funny, but made me smile in my current mental-state.

Mr. Night

Beaker as David Tennant? Awesome.

Ran into this bug the other day, trying to point some FTP ports at a PBX on a client-site (because VPN's are 'teh complicated' and in cahoots with the devil according to some people it would seem).
https://tools.cisco.com/bugsearch/bug/CSCuc55719
The config works perfectly, right up until you specify a port-range in your service-group. Once you have a range, the source-port range is ignored, and only passes if source and destination ports are in the specified destination range.
Explicitly setting your source range of 1-65535 (or 0-65535 for UDP respectively) instead of riding on the default ranges of any wouldn't do the trick either. The implicit deny would always get in the way.

Observe!

ciscoasa# packet-tracer input outside tcp 4.4.4.4 12345 8.8.8.8 21

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   8.8.8.8 255.255.255.255 identity

Phase: 2
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule


But, put source and destination ports both within the specified range, and...

ciscoasa# sh run | beg obj-pbx-tcp
object service obj-pbx-tcp
  service tcp destination range ftp-data ftp
!
<trimmed>

ciscoasa# packet-tracer input outside tcp 4.4.4.4 21 8.8.8.8 21

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (outside,voice) source static any any destination static interface host-strata-cix service obj-pbx-tcp obj-pbx-tcp unidirectional
Additional Information:
NAT divert to egress interface voice
Untranslate 8.8.8.8/21 to 192.168.2.253/21

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit tcp any object-group tcp-source-any any object-group DM_INLINE_TCP_2 log
object-group service tcp-source-any tcp
  port-object range 1 65535
object-group service DM_INLINE_TCP_2 tcp
  port-object eq ftp
  port-object eq ftp-data
Additional Information:

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (outside,voice) source static any any destination static interface host-strata-cix service obj-pbx-tcp obj-pbx-tcp unidirectional
Additional Information:
Static translate 4.4.4.4/21 to 4.4.4.4/21

<trimmed>

Phase: 7
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group voice_access_out out interface voice
access-list voice_access_out extended permit ip any 192.168.2.0 255.255.255.0
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (outside,voice) source static any any destination static interface host-strata-cix service obj-pbx-tcp obj-pbx-tcp unidirectional
Additional Information:

<trimmed>

Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 36559, packet dispatched to next module

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: voice
output-status: up
output-line-status: up
Action: allow

Ah, the joys of not paying for SmartNET.
Fortunately, as the bug tracker reports, it was fixed. Tests fine with 9.1.3.

She doesn't look anything like she sounds. Perhaps my mind just expects all asian-looking types to sound Japanese. My mind is pretty screwed up though, so who the hell knows.

время

Moooooonday.
My new toy.
Wrapped my head around the SRX100 for the most part. I do not enjoy having to type 'interfaces fe..' instead of 'interface fa..'. All the other cool stuff you can do with JunOS however will hopefully make up for that over time.

Hmm. Had more on my mind when I started this, can't seem to get it out of my thick skull.

Never in a million years, would I have thought to put Robbie Williams, and Dizzee Rascal together.
But there you go.

До свидания.

Good Is Bad

I ran into this problem some time back, trying to perform NAT/PAT from inside hosts, to an interface secondary address on an ASR1000.
While looking for something else this evening, I randomly happened across this solution, and immediately felt stupid.

  • Firstly, because it's so simple a fix
  • Secondly, because TAC told me to take a hike, as it was an unsupported config. This was after five weeks of back and forth and debugs.
  • Thirdly, because I've done this before... kindof.

It should have occurred to me that it was this same config when I had a /29 sitting on an ASR's loopback, being advertised upstream from within an NSSA. In that case, my NAT was exactly that - to pools with no secondary addresses. However, strictly speaking, there was no primary address either in that scenario. Situations required that config change, which moved the /29 from the loopback, to the outside interface as a primary, and secondary addresses.

Pseudo-config of what was for those still playing along.

router ospf 1
  router-id 1.2.3.1
  area 99 nssa
  network 1.2.3.0 0.0.0.7 area 99
  passive-interface default
  no passive-interface gi0/0/0
!
interface gigabitEthernet0/0/0
  ip address 10.10.99.1 255.255.255.248
  ip ospf 1 area 99
  ip nat outside
!
interface gigabitEthernet0/0/1
  ip address 192.168.0.1 255.255.255.0
  ip nat inside
!
interface loopback 255
  description Public allocation from Initech
  ip address 1.2.3.1 255.255.255.248
  ip ospf 1 area 99
!
ip access-list extended 100
  remark deny host for nat to second pool
  deny ip host 192.168.0.5 any
  remark permit everything else
  permit ip 192.168.0.0 0.0.0.255 any
!
ip access-list extended 101
  permit ip host 192.168.0.5 any
!
ip nat pool POOL-1-2-3-5 1.2.3.5 1.2.3.5 prefix 29
ip nat pool POOL-1-2-3-6 1.2.3.6 1.2.3.6 prefix 29
!
ip nat inside source list 101 pool POOL-1-2-3-5 overload
ip nat inside source list 100 pool POOL-1-2-3-6 overload
!

Any active translations built using either pool, could even be pinged from outside the network, and the ICMP replies were even sourced from the respective address.
That sh!t worked fine, as far back as 3.1.0, 15.0(1)S - which is pretty close to the first production release of IOS-XE as far as I can tell.

Oh-well.

I wanted to buy this, but iTunes only has it in the UK. Ministry of sound doesn't list it (probably because I'm coming from a IP address outside of Europe). Amazon and Beatport don't list it.
Honestly, what's wrong with this world and it's digital media distribution? Seriously, shut up and take my money!
/sigh. Wiretap to the rescue, once more.