anyone here

I'm here. Sometimes

@JohnJensen, your profile mentions automation, I would be interested in hearing about your automation work

hey Mike

I'm actually somewhat of a novice. I learned Perl and started to pick up python at the new gig

wrote some code that uses exscript and networkx to generate MPLS paths for LSP's based on the arp tables of brocade kit

we'd originally tried to do strict hops in the manual ERO's all the way through, but that didn't work out so well

if there were 2 equal cost paths, sometimes the script would pick a secondary path that transited the same physical link as the primary :-)

so i wound up just doing strict for the first immediate hop and loose for the loopback of the remote device

python is proving to be fun, definitely feels like there's a lower "barrier of entry" for writing modules etc. than perl

plus the OO feels nicer to me

I worked for an ISP that was using TE as well... we did not have tunnel automation at the time, and I wound up doing the same thing for routing LSPs

perl has moose nowadays but you don't get that for free :-)

good stuff

I was a perl guy for about 10 years and finally got fed up with the bad error messages... one day I tried python and I've been hooked ever since... OO makes a lot of automation easier, if you code the classes correctly

are you using exscript on linux or windows?

yeah, that's still kind of where i fall short a bit. perl OO seemed really kludgy and i never quite understood it fully (at least until python gave me some more context) but i managed to "work my way around it" by just writing tons of procedural code

or functional code? is that the right term?

but yeah, trying to break myself of that habit

exscript on linux

i've also done some hacking on ncclient

i'd love to get us to where we rely mostly on NETCONF

wish that was more mainstream

seems like Juniper were the only ones that got that part right

I haven't done much work with netconf yet... actually that's been on my list to investigate for a while... are you doing netconf with Cisco gear, or is it mostly junos?

brocade actually

I'm curious how that Aaron person will fare with the IOS-XR XML agent

they wouldn't properly serialize their configs into xml

*xml elements anyway

you'd just have a bunch of "cisco config" snippets in CDATA's or something like that

:-)

Brocade is good (they have the fundamentals there, they just need to get more of their configuration directives NETCONF-accessible, but they're getting there), but JunOS is the best IMO

yeah, that (cisco issues with xml serialization) makes sense... I don't do much xml work... when you say cisco config in CDATAs, you mean you'd have to hack around cisco's XML problems with static configurations in CDATA elements?

no i mean, you'd see like literal Cisco config in CDATA elements

ah, instead of an XML element heirarchy

ya

trying to find an example

John, I'm curious do you ever write any C code?

I wish

Do you?

I've read through a bit of tac_plus and quagga code

but i haven't written any C

ok... my C is fairly infantile... but have this idea that what I really need (and maybe other people too) is a python interface to putty...

that would require some C skills... I'm trying to find some people to team up with who'd be interested in that kind of a project

what are the goals/use cases?

(brb stepping out for a smoke - where are you located btw?)

A truly cross-platform CLI scrapper

pexpect is basically only written for linux... it requires a PTY, and that's out of the question on windows... exscript may have better cross platform support, but the scope of that project is a much higher-level API than what I want... I just want a cross-platform API to automate telnet / ssh without involving how you parse vendor-specific login methods

np... I'm in Austin, TX

cool. heard the music scene is pretty awesome there

what do you mean by parsing vendor-specific login messages?

i mean anything expect-based is going to require some amount of prompt interpretation

yeah, Austin has got awesome music... not that I can ever get out any more... we just had our first child last year, so that's eating our ability to do the music club scene

Congratulations! No kids for me yet, but getting married in July

and the fiancee recently got a job as a manager for a baby clothing/accessories/etc store

so I can probably assume my kid-free days are numbered. :-)

exscript focuses on giving you an API to login to a Cisco or Juniper... contrast with pexpect, which has lower-level send() or expect() methods...

oh, yeah, it does, but you can also use the python module directly, which is what i do

lol... yeah, I don't care what they say before marriage... my wife and I "weren't planning to have kids either"

but yeah exscript does sit on top of pexpect, but you also get the handy accounts management and "threading" (not sure if it's real threading or not) and things like that

I didn't realize exscript was using pexpect under the covers...

ya

at least I thought it was

s/thought/assumed :-)

I wonder how he gets it working on windows... I have seen some ugly hacks to get pexpect up on windows, but that's not what I want for this library... in fact that's why I want it... linux, windows, and OSX support from the beginning... simple installation, and one api with consistent behavior on all platforms

anyway, that's my pet project... one day I will figure out how to start it :)

well it sounds like a good idea IMO! I wish I knew more C, otherwise I'd totally volunteer to do what I could to help get it off the ground

also would be good to include NETCONF support :D

no problems... I just like to network with other scripters for ideas

although to be fair that would probably introduce a ton of scope creep initially

true... netconf protocol would be a natural addition after I got the basic telnet / ssh stuff working

putty supports raw sockets, so I think it's possible

do you mean initiating socket connections from putty, or to putty itself?

from putty... netconf is a higher level protocol, but similar client-server model as telnet and ssh

oh yeah, but the underlying transport is SSH anyway

just to "not port 22" :-)

if you take a look at the ncclient code he's using paramiko to do the transport

I looked at paramiko, but there is no telnet support... and python's native telnet hasn't really got me that excited

ah

we still have devices that are only telnet

hm

getting downtime in our environment is hard... we get one real maintenance window a year, at best

you can interact with the C stdlib in python yeah? wonder how hard it would be to make a basic telnet client

wowzas

you still in the SP industry?

yes, but that only gets me telnet... I want both

no electronics manufacturing... I work at a semiconductor fab... 24x7x365

they have people making chips on thanksgiving and christmas

:-(

i thought robots did all that

well, the robots need guidance... and a network :-)

well, if you got the telnet part down, wouldn't paramiko be able to do the rest? or is it not that great on windows?

I look at putty as a way to abstract support for both telnet and ssh across platforms...

ah, i see

if I write stdlib c to get a decent telnet client on linux, then I have to deal with porting to windows

doh

that's right

putty solves all that... they do the nasty cross-platform stuff... I just surf on top of their work

actually there is already a putty project that interfaces with Lua...

tbh how many linux folks use putty on linux though? :-)

or would you just omit the putty bits for the linux port

that's not really an issue... I can redistribute putty with the library

nobody even has to know I'm shipping putty with it... although it would be obvious during compilation... and of course, from the name of the library

fair point

well, i'm off to bed. if you want to drop me an e-mail it's in my profile. even though i don't write C, i'm keen to help out in any way I can - if you manage to get the time :-)

good chatting with you

sure thing... good talking with you too... I'll shoot you an email with my contact info

sweet, sounds good. ttys

hi

If you haven't read it yet, tools.ietf.org/html/rfc2549

But read rfc1149, first.