[c-nsp] 12.4(20)T oddities
Lala Lander
sshafi at gmail.com
Sun Aug 31 18:23:25 EDT 2008
i saw issues with iBGP sessions...I kept receiving this messages for iBGP
sessions till I went back to my previous code.
*Aug 7 02:07:45: %BGP-3-NOTIFICATION: sent to neighbor x.x.x.x 1/2 (illegal
header length) 2 bytes 1001
Thanks,
On Sun, Aug 31, 2008 at 2:47 PM, Martin Moens <Moens at carrier2carrier.com>wrote:
> I had the same issues with scrt and 20T, resolved it with the latest SCRT
> (some 6.1.xxxx beta) and a manual change to an .ini file. After this change
> SCRT works fine again with 20T.
>
> I have seen issues with trace backs as well, I do not have the exact text
> at
> hand, but each time I do a write after a config change I get a trace back.
> (2801)
>
> It definitely looks like 20T is not ready for a life outside the test
> lab...
>
> Martin
>
>
>
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of James Baker
> > Sent: Sunday, 31 August, 2008 22:04
> > To: Justin Shore; Cisco-nsp
> > Subject: Re: [c-nsp] 12.4(20)T oddities
> >
> > Hi
> >
> > The problem with SecurtCRT and 20T seems to be around the Key
> > exchange.
> > What I did to solve this for me was to move diffie-hellman to be the
> > first key which fixed it.
> >
> > I'm still not 100% confidant of 20T as well.
> >
> > James
> >
> >
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin Shore
> > Sent: Saturday, 30 August 2008 9:04 p.m.
> > To: 'Cisco-nsp'
> > Subject: [c-nsp] 12.4(20)T oddities
> >
> > I upgraded a 2811 to 20T the other night. I did another 2811 tonight
> > after a different maintenance window. The routers are basically
> > identical, except for the quantity of modules installed in them. I
> > noticed the first night that I was seeing a number of tracebacks.
> > Nothing was a show-stopper though. One happened on boot and I don't
> > have it handy at the moment. Here are 2 that I still have in the log:
> >
> >
> > 000435: Aug 27 00:47:47 CDT: %SCHED-7-WATCH: Attempt to enqueue
> > uninitialized watched queue (address 0). -Process= "Call Manager XML
> > client", ipl= 0, pid= 342, -Traceback= 0x41774928 0x42DF4DF8
> > 0x42B15C58
> >
> > 0x42B54260
> >
> > 000440: Aug 27 00:49:20 CDT: %SCHED-7-WATCH: Attempt to enqueue
> > uninitialized watched queue (address 0). -Process= "SSH
> > Process", ipl=
> > 0, pid= 317, -Traceback= 0x41774928 0x42DF4DF8 0x42B15C58 0x42B54260
> >
> >
> > Another odd thing that I noticed was that SSH from SecureCRT
> > broke after
> >
> > the upgrade. SSH from a Linux command line (OpenSSH) still works
> > though. This error is logged on the router:
> >
> >
> > 000552: Aug 30 03:45:26.430 CDT: SSH2 0: Invalid modulus length
> >
> >
> > I wiped the router's RSA keys and regenerated them first at
> > with a 2048
> > bit modulus and then 1024 bit. Neither solved the problem. I even
> > removed the local SecureCRT known_hosts key for that host
> > (though that
> > shouldn't have matter because SCRT will prompt you if the key has
> > changed). Below is the output from debug ip ssh packet/detail:
> >
> >
> > 001258: Aug 30 03:53:11.320 CDT: SSH0: starting SSH control process
> > 001259: Aug 30 03:53:11.320 CDT: SSH0: sent protocol version id
> > SSH-2.0-Cisco-1.25
> > 001260: Aug 30 03:53:11.324 CDT: SSH0: protocol version id is -
> > SSH-2.0-SecureCRT_6.0.0 (build 183) SecureCRT
> > 001261: Aug 30 03:53:11.324 CDT: SSH2 0: send:packet of length 344
> > (length also includes padlen of 5)
> > 001262: Aug 30 03:53:11.324 CDT: SSH2 0: SSH2_MSG_KEXINIT sent
> > 001263: Aug 30 03:53:11.324 CDT: SSH2 0: ssh_receive: 424
> > bytes received
> > 001264: Aug 30 03:53:11.324 CDT: SSH2 0: input: total packet
> > length of
> > 424 bytes
> > 001265: Aug 30 03:53:11.324 CDT: SSH2 0: partial packet length(block
> > size)8 bytes,needed 416 bytes,
> > maclen 0
> > 001266: Aug 30 03:53:11.324 CDT: SSH2 0: input: padlength 7 bytes
> > 001267: Aug 30 03:53:11.324 CDT: SSH2 0: SSH2_MSG_KEXINIT received
> > 001268: Aug 30 03:53:11.324 CDT: SSH2:kex: client->server
> > enc:aes128-cbc
> >
> > mac:hmac-md5
> > 001269: Aug 30 03:53:11.328 CDT: SSH2:kex: server->client
> > enc:aes128-cbc
> >
> > mac:hmac-md5
> > 001270: Aug 30 03:53:11.328 CDT: SSH2 0: ssh_receive: 24
> > bytes received
> > 001271: Aug 30 03:53:11.328 CDT: SSH2 0: input: total packet
> > length of
> > 24 bytes
> > 001272: Aug 30 03:53:11.328 CDT: SSH2 0: partial packet length(block
> > size)8 bytes,needed 16 bytes,
> > maclen 0
> > 001273: Aug 30 03:53:11.328 CDT: SSH2 0: input: padlength 6 bytes
> > 001274: Aug 30 03:53:11.328 CDT: SSH2 0: SSH2_MSG_KEX_DH_GEX_REQUEST
> > received
> > 001275: Aug 30 03:53:11.328 CDT: SSH2 0: Range sent by client
> > is - 1024
> > < 2046 < 2046
> > 001276: Aug 30 03:53:11.328 CDT: SSH2 0: Invalid modulus length
> > 001277: Aug 30 03:53:11.428 CDT: SSH0: Session disconnected -
> > error 0x00
> >
> >
> > Any thoughts? I'm holding off on any more 20T upgrades until
> > this can
> > be resolved. While I do have a local NOC server that I can
> > SSH from if
> > needed I'm not inclined to hinder my management abilities like that.
> >
> > As I was writing the config and disconnecting this 3rd
> > traceback popped
> > up:
> >
> > 001301: Aug 30 03:59:06 CDT: %SCHED-7-WATCH: Attempt to enqueue
> > uninitialized watched queue (address 0). -Process= "Virtual
> > Exec", ipl=
> > 0, pid= 354, -Traceback= 0x41774928 0x42DF4DF8 0x42B15C58
> > 0x42B54260[OK]
> >
> >
> > Does anyone have any thoughts on any of this? So far this
> > has been the
> > most problematic T release I've used. They are generally
> > more reliable.
> >
> > So far I haven't noticed any VoIP issues or other actual
> > show-stoppers. I'm itching to try out some of the new and
> > long-awaited
> > features but I may have to wait for a (20)T1 to do that outside of a
> > lab.
> >
> > Thanks
> > Justin
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > ----------
> >
> > The information contained in this e-mail and any attachments
> > is confidential
> > and is intended for the attention and use of the named
> > addressee(s) only.
> > Any views expressed in this message are those of the
> > individual sender and
> > may not necessarily reflect the views of Chelmer Limited.
> >
> > ##############################################################
> > #######################
> > This e-mail message has been scanned for Viruses and Content
> > and cleared
> > by NetIQ MailMarshal
> > ##############################################################
> > #######################
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
More information about the cisco-nsp
mailing list