nanog@nanog.org

[Michael Ruiz]

Hey folks,

 

I had a situation recently that our network went down
and our Network Monitoring software did not notify us that the network
was down because the internet connection went down.  We had a problem
with our carrier where they messed up on our /23(where our Network
Monitoring software resides), when they did a maintenance.  What
transpired is our /23 was no longer routing to us.  Is there a free ping
internet service, or something that we can pay a company that just sends
a ping to devices?  If they fail to respond, then an email is sent to
us?  Thank you folks.

 

M.A.R

Senior Network Engineer

 

nanog@nanog.org

[Michael Ruiz]

Hello folks,

 

I would like to the OID number for displaying the number
of routers that your EBGP peer has received.  Thank you in advanced.

 

Michael Ruiz

 

nanog@nanog.org

[Michael Ruiz]

Hello all,

 

I am having very unusual problem with the CSM.  This is
what my problems.  I have my active CSM setup for a Fault Tolerance
group with a priority of 100 and an alternate of 30 and set to preempt.
Now for some reason I cannot get the standby configure to get the
configuration from the Active.  I did a debug and it appears the CSM on
the standby is deleting it's configuration and the active fails to sends
its configuration.  So I know the Active is talking across the VLAN I
have created for this purpose.  I can see the information coming up on
my debug from both ends.  Below is my configuration.  Any help on this
is appreciated.  Thank you in advance. 

 

DR01.SNATXDC1#  show module csm 8 ft detail 

FT group 2, vlan 45

This box is active

Configuration is out-of-sync

priority 100, heartbeat 1, failover 3, preemption is on

alternate priority 30

total buffer count 6214, illegal state transitions 0

receive buffers not committed 0, send buffers not committed 0

updates:  sent 4, received 0, committed 0

coup msgs:  sent 0, received 0

election msgs:  sent 0, received 2

heartbeat msgs:  sent 1057, received 594

relinquish msgs:  sent 0, received 0

conn replicate msgs: sent 462, received 0

conn refresh msgs: sent 462, received 0

conn reset msgs: sent 61, received 0

conn redundancy errors: msgs lost 0, msgs rejected 0

packets:  total received 0, total dropped 0, duplicates 0

   checksum failed 0, dumped 0, buffer unavailable 0

number of state updates in last 8 transfers:

0  0  0  0  0  0  0  0 

 Critical device and interface tracking:

 

 

DR01.SNATXDC1#

 

DR02.SNATXDC1#show module csm 8 ft detail 

FT group 2, vlan 45

This box is in standby state

Configuration is out-of-sync

priority 10, heartbeat 1, failover 3, preemption is off

total buffer count 6214, illegal state transitions 10

receive buffers not committed 0, send buffers not committed 0

updates:  sent 4, received 0, committed 0

coup msgs:  sent 0, received 0

election msgs:  sent 2, received 0

heartbeat msgs:  sent 0, received 984

relinquish msgs:  sent 0, received 0

conn replicate msgs: sent 0, received 0

conn refresh msgs: sent 0, received 0

conn reset msgs: sent 0, received 0

conn redundancy errors: msgs lost 0, msgs rejected 0

packets:  total received 5056012, total dropped 0, duplicates 0

   checksum failed 0, dumped 0, buffer unavailable 0

number of state updates in last 8 transfers:

0  0  0  0  0  0  0  0 

 Critical device and interface tracking:

 

 

DR02.SNATXDC1#

 

!

ft group 2 vlan 45 

  priority 100 alt 30

  preempt

 

 

 

DR02.SNATXDC1#show run module 8

Building configuration...

 

Current configuration : 5 bytes

end

 

DR02.SNATXDC1#

 

 

M.A.R

 

Is Cisco equpiment de facto for you?

[Michael Ruiz]

I know where I have worked we have had a mixture of Juniper and Cisco
equipment.  Personally buying a Juniper Router like a M or a T series is
like buying a Ferrari. I like Cisco personally and they are cheaper than
buying a Juniper.  For example a M-series is always going to cost some
bucks after you factor the FPC and the PICS that need to be loaded.
Personally I like the JUNOS system better than the Cisco IOS, it is more
tech friendly when troubleshooting issues.  I have not worked on the new
IOS-NX system, but if I understand it correctly it is modular.  If Cisco
can the really cool Monitor command and the structure the command tree
like a Juniper.  I would think Cisco did something totally right.  

 

M.A.R

 

RE: Is Cisco equpiment de facto for you?

[Michael Ruiz]

>I find this usually has to do with the fact that there is no "backup to

>software processing" on a Juniper. Every feature it supports, it does
so 
>in hardware. If the hardware won't do it, then JUNOS won't do it.

>The exception has been the multiservices PIC, which is being obsoleted 
>with the trio chipset.

>You are right, though. If you don't need the performance, you can
settle 
>for a cisco in many cases. Also, the MX Juniper line often has nicer 
>performance than the M series if you do more ethernet than sonet.

Yeah another thing I love about the JUNOS is the rollback command.  Whew
I can tell you a few times where that has saved my bacon a few times and
the commit and check command. :-)

-Original Message-
From: Jack Bates [mailto:jba...@brightok.net] 
Sent: Thursday, January 13, 2011 1:41 PM
To: Michael Ruiz
Cc: nanog@nanog.org
Subject: Re: Is Cisco equpiment de facto for you?

On 1/13/2011 1:35 PM, Michael Ruiz wrote:
> For example a M-series is always going to cost some
> bucks after you factor the FPC and the PICS that need to be loaded.

I find this usually has to do with the fact that there is no "backup to 
software processing" on a Juniper. Every feature it supports, it does so

in hardware. If the hardware won't do it, then JUNOS won't do it.

The exception has been the multiservices PIC, which is being obsoleted 
with the trio chipset.

You are right, though. If you don't need the performance, you can settle

for a cisco in many cases. Also, the MX Juniper line often has nicer 
performance than the M series if you do more ethernet than sonet.

Jack

RE: Is Cisco equpiment de facto for you?

[Michael Ruiz]

>Cisco marketing seems to have dropped the ball on this one, but IOS has
had a feature that allows you to save a number of configurations, do
diff's, and >generally behave similar to the JunOS method for quite a
while.  You'll want to check out the "archive" command.

>http://blogs.techrepublic.com.com/networking/?p=532

>The only thing I can tell that's really missing is "commit confirmed"
in JunOS, and of course it operates differently so people may or may not
like it.

>-- 
 >  Leo Bicknell - bickn...@ufp.org - CCIE 3440
  >  PGP keys at http://www.ufp.org/~bicknell/
Yeah you are right it does have some JUNOS like feel. 

-Original Message-
From: Leo Bicknell [mailto:bickn...@ufp.org] 
Sent: Thursday, January 13, 2011 1:58 PM
To: Michael Ruiz
Cc: Jack Bates; nanog@nanog.org
Subject: Re: Is Cisco equpiment de facto for you?

In a message written on Thu, Jan 13, 2011 at 01:48:27PM -0600, Michael
Ruiz wrote:
> Yeah another thing I love about the JUNOS is the rollback command.  
> Whew I can tell you a few times where that has saved my bacon a few 
> times and the commit and check command. :-)

Cisco marketing seems to have dropped the ball on this one, but IOS has
had a feature that allows you to save a number of configurations, do
diff's, and generally behave similar to the JunOS method for quite a
while.  You'll want to check out the "archive" command.

http://blogs.techrepublic.com.com/networking/?p=532

The only thing I can tell that's really missing is "commit confirmed" in
JunOS, and of course it operates differently so people may or may not
like it.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

RE: Is Cisco equpiment de facto for you?

[Michael Ruiz]

On Jan 13, 2011, at 11:51 AM, Jack Bates wrote:

> On 1/13/2011 1:48 PM, Michael Ruiz wrote:
>> Yeah another thing I love about the JUNOS is the rollback command.
Whew
>> I can tell you a few times where that has saved my bacon a few times
and
>> the commit and check command.:-)
> 
> Cisco IOS has a similar feature.
> 
> reload in 5
> make changes
> verify things are working
> reload cancel
> 
> It's a little different on a redundant processor system, as you have
to reload both processors. It's also a 2-20 minute outage while you
reload, but it does beat 2 hour drives.
> 
> 
> Jack

>Not at all the same... With JunOS, I can have the changes I made
running for days, but, when some problem is later discovered I can still
rollback to >the previous (or several revisions back). I can easily
compare the current config to several previous revisions, etc.

>Additionally, with JunOS I can make all my changes, verify them
syntactically, compare the changes made to the previous configuration
all without having >the changes take effect during the process. Then,
when I'm satisfied I have it right, I commit the configuration. If
you've ever had to play the IOS ACL >rotation game, you know how
wonderful this feature is.

>Cisco's half-hearted attempt to play catch-up here is woefully
inadequate.

>Owen


I agree.  That is the really neat feature about the
rollback command.  Like I said before it has saved me more ways the one.
:-)

-Original Message-
From: Owen DeLong [mailto:o...@delong.com] 
Sent: Thursday, January 13, 2011 2:59 PM
To: Jack Bates
Cc: Michael Ruiz; nanog@nanog.org
Subject: Re: Is Cisco equpiment de facto for you?


On Jan 13, 2011, at 11:51 AM, Jack Bates wrote:

> On 1/13/2011 1:48 PM, Michael Ruiz wrote:
>> Yeah another thing I love about the JUNOS is the rollback command.
Whew
>> I can tell you a few times where that has saved my bacon a few times
and
>> the commit and check command.:-)
> 
> Cisco IOS has a similar feature.
> 
> reload in 5
> make changes
> verify things are working
> reload cancel
> 
> It's a little different on a redundant processor system, as you have
to reload both processors. It's also a 2-20 minute outage while you
reload, but it does beat 2 hour drives.
> 
> 
> Jack

Not at all the same... With JunOS, I can have the changes I made running
for days, but, when some problem is later discovered I can still
rollback to the previous (or several revisions back). I can easily
compare the current config to several previous revisions, etc.

Additionally, with JunOS I can make all my changes, verify them
syntactically, compare the changes made to the previous configuration
all without having the changes take effect during the process. Then,
when I'm satisfied I have it right, I commit the configuration. If
you've ever had to play the IOS ACL rotation game, you know how
wonderful this feature is.

Cisco's half-hearted attempt to play catch-up here is woefully
inadequate.

Owen

How are you aggregating WAN customers these days?

[Michael Ruiz]

I know the way I used to do it at a previous company is we
deployed the Cisco 12000 series router with the CHOC12-DS1-IR-SC module
so we can 336 T1 out of that puppy.  The only down side is there is a
limitation on the number of channel groups. If doing something other
than just handing off full T1 circuits, i.e. channelized T1s, then that
is where you run into the problem.  Sorry I do not remember what the
magic number is but it something like 360 channel groups.  The price on
those cards can been pretty steep at times, not counting the OC12 card
you have to get for the DACS(usually those cards have LR type interface,
so have to pad the laser, assuming you have your DACS J)
 
If you do not care about QOS those cards are great.  If you
don't mind doing COS, which can be a little challenging of getting them
setup for it, work ok.  If you want to more fancier with QOS, now you
have to move to the Engine 5 cards which cost some bucks.
 
At this new company we use old faith full, Cisco 7206 VXR routers with
the PA-MC2T3+ cards.  Since they have come down a lot in price you can
really load up the chassis with those cards. DS-3 cards for a DACS is
fairly inexpensive (depending on the type of DACS you have).  
 
In short, if you have your own transport equipment, then really comes
down to the interfaces cards, connection type, labor and time.  I hope
that helps.  
 
> Hello,
> 
> I'm looking to put some feelers out there and see what people are
> doing to aggregate WAN customers (T1,T3, etc...) these days. What
> platforms/devices are you using? What seems to be working/not working?
> Any insights would be great!
> 
> Thanks,
> 
 
 
> Chris

 

M.A.R

 

How are you aggregating WAN customers these days?

[Michael Ruiz]

We used that topology, with an Adtran MX 2800 19" rack version.  We
would take our channelize DS-3 from the Telco and the Cisco PA-MC2T3
cards and in turn wire those to a DSX-1 panel.  We then did 1 to 1 DS1
X-connects on the panel.  That was starting to get too much of a pain as
services grew, so we went with a DACS and that took care of having to do
all that DSX-1 wiring.  Ugh. 
 
 
>The ASRs seem to be the consensus in a lot of places. Wondering if
>anyone has tried anything like aggregating T1 customers onto a mux
>box, then connecting that back to a 6500.
 
>I work in that kind of topology all day long/ both in 6500 & ASR's.
>All is well/
 
>On Mon, Jan 10, 2011 at 7:51 AM, Chris https://mailman.nanog.org/mailman/listinfo/nanog> > wrote:
 
> Hello,
> 
> I'm looking to put some feelers out there and see what people are
> doing to aggregate WAN customers (T1,T3, etc...) these days. What
> platforms/devices are you using? What seems to be working/not working?
> Any insights would be great!
> 
> Thanks,
> 
 
 
> Chris
> 
> 
 

 

 

Michael Ruiz

Senior Network Engineer

 

 

LST Financial, Inc.

Integrated Network Delivery Services, Inc.

Integrated Components, Inc.

Office 210-933-0212

Fax 210-892-2599

"Opportunities multiply as they are seized." - Sun Tzu

 

<>

Authentication using Microsoft 2008 Active directory for Cisco RADIUS login

[Michael Ruiz]

Hello all,

 

I am having some trouble getting my Cisco routers to use
Active directory to authenticate users. I have searched on Google and so
far I am coming up dry on good documentation that will work. 

 

I have used these links.
http://briandesmond.com/blog/how-to-authenticate-against-active-director
y-from-cisco-ios/

 

http://filedb.experts-exchange.com/incoming/2008/12_w51/87700/TA0001-Win
dows-2008-RADIUS-for-C.pdf

 

 

When I am doing a debug against the AAA I am getting the "Response (32)
failed decrypt" error.  Any thoughts?  Thank you in advance.

 

M.A.R

 

RE: Authentication using Microsoft 2008 Active directory for Cisco RADIUS login

[Michael Ruiz]

>Can you post your config on the router?

 

>Also, this may be better to post over at cisco-nsp.

 

 

>B

 

I decided to move away from RADIUS via Active Directory and turn up a
Ubuntu TACACS+ server.  Now it works.  HAHA.  Now it is time to create
the template files. 

 

 

 

M.A.R

 

nanog@nanog.org

[Michael Ruiz]

Hello All,

I have been working for two days trying to get an ASA to setup 
a VPN tunnel to a SSG-550.  I have the VPN tunnel Setup and ready to go on the 
ASA.  I ran a Debug crypto IPSec 200 and crypto ikve1 200.  I do the command 
ping PRIVATE  and I get in the console


Sending 5, 100-byte ICMP Echos to 10.1.4.81, timeout is 2 seconds:
IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=1, 
saddr=10.20.1.2, sport=29733, daddr=10.1.4.81, dport=29733
IPSEC(crypto_map_check)-5: Checking crypto map CARIBOU-VPN-1 10: skipping 
incomplete map.  No peer, access-list or transform-set specified.
IPSEC(crypto_map_check)-1: Error: No crypto map matched.

>From my understanding this is caused by the crypto map not being able to 
>establish a tunnel to the Juniper.

On my Juniper configuration I have built the Gateway and set the Phase 1 
Proposal to "pre-g2-3des-md5" followed by "pre-g2-3des-sha"

For the VPN configuration I use the predefined gateway configuration.

Under the advanced button, I use the predefined of "compatible" and the Phase 2 
Proposal "nopfs-esp-3des" followed by "nopfs-esp-3des"
The proxy id is the local IP / Network block and the remote IP network block is 
the destination IP block.  The only part that has me wondering, because the 
Juniper has multiple zones, i.e. a DMZ, Trust, and Untrust.  Each Zone has its 
own IP block that is assigned to it.  I have entered a policy into one of the 
zones, i.e. Untrust to Trust, input source block, destination block, specified 
it is a tunnel, set for bi-directional entry and that should be it.

Any help in this as always will be greatly appreciated.  Thank you.



Thank You,

MAR

CONFIDENTIALITY NOTICE: This message is intended only for the individual or 
entity to which it is addressed and may contain information that is 
confidential or exempt from disclosure under applicable law. If you are not the 
intended recipient, you have received this communication in error. In such 
case, please notify us immediately by reply e-mail and immediately delete this 
message and its attachments. Any use, dissemination, redistribution or 
reproduction of this communication is strictly prohibited. Unless the message 
explicitly states otherwise, no e-mail correspondence claims to be a 
contractual offer or acceptance. LST Financial has instructed its employees not 
to send libelous or inappropriate statements and disclaims responsibility for 
such. Subject to applicable law, LST Financial may monitor, review and retain 
e-communications traveling through its networks/systems. By messaging with LST 
Financial you consent to the foregoing.

Re:

[Michael Ruiz]

Yes sir.

I called cisci tac and according to the asa team, the tunnel cannot be created 
because the juniper is not the session to be created due to some missmatches.
--
Sent using BlackBerry


- Original Message -
From: Chris Russell [mailto:ch...@nifry.com]
Sent: Friday, July 08, 2011 06:09 PM
To: Michael Ruiz
Cc: nanog@nanog.org 
Subject: Re: 


> Sending 5, 100-byte ICMP Echos to 10.1.4.81, timeout is 2 seconds:
> IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple:
> Prot=1, saddr=10.20.1.2, sport=29733, daddr=10.1.4.81, dport=29733
> IPSEC(crypto_map_check)-5: Checking crypto map CARIBOU-VPN-1 10:
skipping
> incomplete map.  No peer, access-list or transform-set specified.
> IPSEC(crypto_map_check)-1: Error: No crypto map matched.
>
>>From my understanding this is caused by the crypto map not being able to
>>establish a tunnel to the Juniper.

 From that log, the Cisco is missing numerous configuration items:

No peer, access-list or transform-set specified.

 Do you have the above specified in the crypto map within the ASA ?

Cheers

Chris

CONFIDENTIALITY NOTICE: This message is intended only for the individual or 
entity to which it is addressed and may contain information that is 
confidential or exempt from disclosure under applicable law. If you are not the 
intended recipient, you have received this communication in error. In such 
case, please notify us immediately by reply e-mail and immediately delete this 
message and its attachments. Any use, dissemination, redistribution or 
reproduction of this communication is strictly prohibited. Unless the message 
explicitly states otherwise, no e-mail correspondence claims to be a 
contractual offer or acceptance. LST Financial has instructed its employees not 
to send libelous or inappropriate statements and disclaims responsibility for 
such. Subject to applicable law, LST Financial may monitor, review and retain 
e-communications traveling through its networks/systems. By messaging with LST 
Financial you consent to the foregoing.
CONFIDENTIALITY NOTICE: This message is intended only for the individual or 
entity to which it is addressed and may contain information that is 
confidential or exempt from disclosure under applicable law. If you are not the 
intended recipient, you have received this communication in error. In such 
case, please notify us immediately by reply e-mail and immediately delete this 
message and its attachments. Any use, dissemination, redistribution or 
reproduction of this communication is strictly prohibited. Unless the message 
explicitly states otherwise, no e-mail correspondence claims to be a 
contractual offer or acceptance. LST Financial has instructed its employees not 
to send libelous or inappropriate statements and disclaims responsibility for 
such. Subject to applicable law, LST Financial may monitor, review and retain 
e-communications traveling through its networks/systems. By messaging with LST 
Financial you consent to the foregoing.

nanog@nanog.org

[Michael Ruiz]

I am having difficulty maintaining my BGP session from my 6509 with
Sup-7203bxls to a 7206 VXR NPE-400.  The session bounces every 3
minutes.  I do have other IBGP sessions that are established with no
problems, however, this is the only IBGP peer that is bouncing
regularly. 

 

cr1.AUSTTXEE#show ip bgp neighbors 67.214.64.100



  BGP state = Established, up for 00:02:54

  Last read 00:00:53, last write 00:02:54, hold time is 180, keepalive
interval is 60 seconds

  Keepalives are temporarily in throttle due to closed TCP window

  Neighbor capabilities:

Route refresh: advertised and received(new)

Address family IPv4 Unicast: advertised and received

  Message statistics:





What does exactly the message mean and how do I stabilize this?  Any
help will be appreciated. 

 

Michael Ruiz

Network Engineer

Office 210-448-0040

Cell 512-744-3826

mr...@telwestservices.com <mailto::mr...@telwestservices.com> 

 

"I don't measure a man's success by how high he climbs but how high he
bounces when he hits bottom."

 - General George S. Patton Jr.

 

How am I doing?  Please email my Director of Engineering Jared Martin
with any feedback at: jmar...@telwestservices.com

 

<>

RE:

[Michael Ruiz]

* Mikael Abrahamsson:

>> What does exactly the message mean and how do I stabilize this?  Any
>> help will be appreciated.
>
> This is most likely an MTU problem.

>>Does IOS enable PMTUD for BGP sessions by default these days?  The 476
>>(or something like that) MTU is unlikely an issue.  There could be a
>>forwarding bug which causes drops dependent on packet size, though.

I am not sure. I think it is, but I went ahead and put in the command
manually. 

Here is more of the configuration to do with TCP information.

ip tcp selective-ack
ip tcp window-size 65535
ip tcp synwait-time 10
ip tcp path-mtu-discovery




-Original Message-
From: Florian Weimer [mailto:f...@deneb.enyo.de] 
Sent: Tuesday, September 15, 2009 12:14 PM
To: Mikael Abrahamsson
Cc: Michael Ruiz; nanog@nanog.org
Subject: Re: 

* Mikael Abrahamsson:

>> What does exactly the message mean and how do I stabilize this?  Any
>> help will be appreciated.
>
> This is most likely an MTU problem.

Does IOS enable PMTUD for BGP sessions by default these days?  The 476
(or something like that) MTU is unlikely an issue.  There could be a
forwarding bug which causes drops dependent on packet size, though.

RE:

[Michael Ruiz]

>Every time I turn those on (plus timestamping), it breaks something.
The
>last time I tried it broke ftp based transfers of new IOS, had to
>disable or use tftp to get a non-corrupted image (SRA). The time before
>that, it occasionally caused bgp keepalives to be missed and thus
>dropped the session (SXF). It may work now, or there may be more subtle

>Cisco bugs lurking, who knows. :)

I tried that, no dice.  I thought it would actually work.  

>You can confirm what MSS is actually being used in show ip bgp
neighbor,
>under the "max data segment" line. I believe in modern code there is a
>way to turn on pmtud for all bgp neighbors (or individual ones) which
>may or may not depend on the global ip tcp path-mtu-discovery setting.
I
>don't recall off the top of my head, but you should be able to confirm
>what size messages you're actually trying to send. FWIW I've run
>extensive tests on BGP with > 9000 byte MSS (though numbers that large
>are completely irrelevent, since bgp's maximum message size is 4096
>bytes) and never hit a problem. I once saw a bug where Cisco
>miscalculated the MSS when doing tcp md5 (off by the number of bytes
>that the tcp option would take, I forget which direction), but I'm sure
>that's fixed now too. :)

Below is snap shot of the neighbor in question.

Datagrams (max data segment is 4410 bytes):
Rcvd: 6 (out of order: 0), with data: 4, total data bytes: 278
Sent: 6 (retransmit: 5), with data: 2, total data bytes: 4474

Could there be a problem with the total data bytes size exceeds the size
of the max data segment?

Below is the router (7206 NPE-400) I am trying to establish a session
with BGP neighbor.


Description: cr1.AUSTTXEE
 Member of peer-group TelWest-iBGP for session parameters
  BGP version 4, remote router ID 67.214.64.97
  BGP state = Established, up for 00:00:02
  Last read 00:00:02, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
  Message statistics:


Datagrams (max data segment is 4410 bytes):
Rcvd: 4 (out of order: 0), with data: 1, total data bytes: 64
Sent: 5 (retransmit: 0, fastretransmit: 0), with data: 3, total data
bytes: 259
cr2.CRCHTXCB#

-Original Message-
From: Richard A Steenbergen [mailto:r...@e-gerbil.net] 
Sent: Tuesday, September 15, 2009 2:54 PM
To: Michael Ruiz
Cc: nanog@nanog.org
Subject: Re: 

On Tue, Sep 15, 2009 at 12:28:02PM -0500, Michael Ruiz wrote:
> Here is more of the configuration to do with TCP information.
> 
> ip tcp selective-ack
> ip tcp window-size 65535
> ip tcp synwait-time 10
> ip tcp path-mtu-discovery

Every time I turn those on (plus timestamping), it breaks something. The
last time I tried it broke ftp based transfers of new IOS, had to
disable or use tftp to get a non-corrupted image (SRA). The time before
that, it occasionally caused bgp keepalives to be missed and thus
dropped the session (SXF). It may work now, or there may be more subtle 
Cisco bugs lurking, who knows. :)

You can confirm what MSS is actually being used in show ip bgp neighbor,
under the "max data segment" line. I believe in modern code there is a
way to turn on pmtud for all bgp neighbors (or individual ones) which
may or may not depend on the global ip tcp path-mtu-discovery setting. I
don't recall off the top of my head, but you should be able to confirm
what size messages you're actually trying to send. FWIW I've run
extensive tests on BGP with > 9000 byte MSS (though numbers that large
are completely irrelevent, since bgp's maximum message size is 4096
bytes) and never hit a problem. I once saw a bug where Cisco
miscalculated the MSS when doing tcp md5 (off by the number of bytes
that the tcp option would take, I forget which direction), but I'm sure
that's fixed now too. :)

-- 
Richard A Steenbergen 
http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)

RE:

[Michael Ruiz]

>Take a look at the interfaces over which the peering session runs, at
both ends.
>I.e., is this the only BGP session *over that interface*, for the local
box?

You are going to find this even more strange.  I have two routers that
are communicating over the same transport medium and are actually in the
same rack. One router is a Cisco 7606 which has an IBGP session
established with my Cisco 6509.  Both equipment have Sup-7203bxls 1 Gig
of memory. Ironically from the 6509's perspective, I cannot seem to
maintain a session with my 7206VXR which has two directly connected
DS-3s.  In order for my 6509 to establish an IBGP session with my 7606,
it has to go through the 7206 VXR.  Crazy right?

Yeah I can already this is going to be a *War Story* as you said it. :)

-Original Message-
From: Brian Dickson [mailto:brian.dick...@concertia.com] 
Sent: Tuesday, September 15, 2009 3:40 PM
To: Mikael Abrahamsson; Michael Ruiz
Cc: nanog@nanog.org
Subject: RE: 

And more specifically, possibly an interface MTU (or ip mtu, I forget
which).

If there is a mismatch between ends of a link, in one direction,
MTU-sized packets get sent, and the other end sees those as "giants".

I've seen situations where the MTU is calculated incorrectly, when using
some technology that adds a few bytes (e.g. VLAN tags, MPLS tags, etc.).

On Cisco boxes, when talking to other Cisco boxes, even.

Take a look at the interfaces over which the peering session runs, at
both ends.
I.e., is this the only BGP session *over that interface*, for the local
box?

(It might not be the end you think it's at, BTW.)

Oh, and if you find something, please, let us know.
War stories make for great bar BOFs at NANOG meetings. :-)

Brian

-Original Message-
From: Mikael Abrahamsson [mailto:swm...@swm.pp.se] 
Sent: September-14-09 2:39 PM
To: Michael Ruiz
Cc: nanog@nanog.org
Subject: Re: 

On Mon, 14 Sep 2009, Michael Ruiz wrote:

> I am having difficulty maintaining my BGP session from my 6509 with
> Sup-7203bxls to a 7206 VXR NPE-400.  The session bounces every 3
> minutes.  I do have other IBGP sessions that are established with no
> problems, however, this is the only IBGP peer that is bouncing
> regularly.
>
> What does exactly the message mean and how do I stabilize this?  Any
> help will be appreciated.

This is most likely an MTU problem. Your SYN/SYN+ACK goes thru, but then

the first fullsize MSS packet is sent, and it's not getting to the 
destination. 3 minutes is the dead timer for keepalives, which are not 
getting thru either because of the stalled TCP session.

-- 
Mikael Abrahamssonemail: swm...@swm.pp.se

RE:

[Michael Ruiz]

>I was assuming that wasn't the case here based on the 4474 mtu (was
assuming
>sonet links or something), but looking at the original message he
>doesn't say what media or what might be in the middle, so its possible
>4474 is a manually configured mtu causing blackholing.

Here is the network architecture from the Cisco 6509 to the 7206 VXR.
The 6509 has a successful BGP session established with another router,
Cisco 7606 w/ Sup720-3bxls.  The 7606 and 7206 VXR are connected
together by a Cisco 3550 switch. In order for the 6509 to establish the
IBGP session to the 7606, it has to pass through two DS-3s, go through
the 7206 VXR, out the Fast E, through the Cisco 3550, and then to the
7606. I checked the MTUs on the 3550s and I am seeing the Fast E
interfaces are still showing 1500 bytes. Would increasing the MTU size
on the switches cause any harm? 

-Original Message-
From: Richard A Steenbergen [mailto:r...@e-gerbil.net] 
Sent: Tuesday, September 15, 2009 3:53 PM
To: Brian Dickson
Cc: Mikael Abrahamsson; Michael Ruiz; nanog@nanog.org
Subject: Re: 

On Tue, Sep 15, 2009 at 05:39:33PM -0300, Brian Dickson wrote:
> And more specifically, possibly an interface MTU (or ip mtu, I forget
> which).
> 
> If there is a mismatch between ends of a link, in one direction,
> MTU-sized packets get sent, and the other end sees those as "giants".

Well if the interface or ip mtu was smaller on one end, this would
result in a lower mss negotiation and you would just have smaller but
working packets. The bad situation is when there is a layer 2 device in
the middle which eats the big packets and doesn't generate an ICMP
needfrag. For example, if there was a 1500-byte only ethernet switch in
the middle of this link, it would drop anything > 1500 bytes and prevent
path mtu discovery from working, resulting in silent blackholing. I was
assuming that wasn't the case here based on the 4474 mtu (was assuming
sonet links or something), but looking at the original message he
doesn't say what media or what might be in the middle, so its possible
4474 is a manually configured mtu causing blackholing.

> I've seen situations where the MTU is calculated incorrectly, when
> using some technology that adds a few bytes (e.g. VLAN tags, MPLS
> tags, etc.).

Even when things are working as intended, different vendors mean 
different things when they talk about MTU. For example, Juniper and 
Cisco disagree as to whether the mtu should include layer 2 or .1q tag 
overhead, resuling in inconsistent MTU numbers which are not only 
different between the vendors, but which can change depending on what 
type of trunk you're running between the devices. Enabling > 1500 byte 
MTUs is a dangerous game if you don't know what you're doing, or if 
you're connected to other people who are sloppy and don't fully verify 
their MTU settings on every link.

> War stories make for great bar BOFs at NANOG meetings. :-)

Never ending supply of those things. :)

-- 
Richard A Steenbergen 
http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)

RE:

[Michael Ruiz]

>Either a) you have the mtu misconfigured on that 7206vxr

That part is where I am at a loss.  How is it the 6509 can establish a
IBGP session with a 7606 when it has to go through the 7206 VXR?  The
DS-3s are connected to the 7206 VXR. To add more depth to the story.  I
have 8 IBGP sessions that are connected to the 7206 VXR that have been
up and running for over a year.  Some of the sessions traverse the DS-3s
and or a GigE long haul connections.  There are a total 10 Core routers
that are mixture of Cisco 7606, 6509s, 7206 VXR w/ NPE400s or G1s.  Only
this one IBGP session out of 9 routers is not being established.  Since
I have a switch between the 7606 and 7206, I plan to put a packet
capture server and see what I can see. 


-Original Message-
From: Richard A Steenbergen [mailto:r...@e-gerbil.net] 
Sent: Wednesday, September 16, 2009 2:07 PM
To: Michael Ruiz
Cc: Brian Dickson; nanog@nanog.org
Subject: Re: 

On Wed, Sep 16, 2009 at 01:18:20PM -0500, Michael Ruiz wrote:
> Here is the network architecture from the Cisco 6509 to the 7206 VXR.
> The 6509 has a successful BGP session established with another router,
> Cisco 7606 w/ Sup720-3bxls.  The 7606 and 7206 VXR are connected
> together by a Cisco 3550 switch. In order for the 6509 to establish
the
> IBGP session to the 7606, it has to pass through two DS-3s, go through
> the 7206 VXR, out the Fast E, through the Cisco 3550, and then to the
> 7606. I checked the MTUs on the 3550s and I am seeing the Fast E
> interfaces are still showing 1500 bytes. Would increasing the MTU size
> on the switches cause any harm? 

As other people have said, this definitely sounds like an MTU problem. 
Basically you're trying to pass 4470 byte BGP packets over a link that
drops anything bigger than 1500. The session will establish because all
the setup packets are small, but the tcp session will stall as soon as
you try to send routes across it.

What should be happening here is the 6509 will generate a 4470 byte
packet because it sees the directly connected interface as a DS3 and
doesn't know the path is incapable of supporting > 1500 bytes end to
end. The layer 3 device on the mtu choke point, in this case the faste
interface on the 7206vxr, should be configured to a 1500 byte mtu. This
will cause the 7206vxr to generate an ICMP neegfrag when the 4470 byte
packet comes along, and cause path mtu discovery to lower the MSS on the
IBGP session. Either a) you have the mtu misconfigured on that 7206vxr
port, b) your router is misconfigured not to generate the icmp, c)
something in the middle is misconfigured to filter this necessary icmp
packet, or d) some other screwup probably related to one of the above.

Generally speaking increasing the MTU size on a switch can never hurt
anything, but having an insufficiently large MTU on the switch is what
will break you the most (as is happening here). The problem occurs when
you increase the MTU on the layer 3 routers to something beyond what the
layer 2 link in the middle is capable of supporting. Layer 3 devices
will either fragment (deprecated) or generate ICMP NeedFrags which will
cause path MTU discovery to shrink the MSS. Layer 2 devices are
incapable of doing this, so you MUST NOT set the layer 3 MTU above what
the layer 2 link is capable of handling.

Now that said, increasing the mtu on the 3550 won't work here because
3550 MTU support is terrible. The only option you have is to configure
the MTU of all interfaces to 1546 with the "system mtu 1546" command,
followed by a reload. This is not big enough to pass your 4470 byte
packets, and will also break any MTU dependent configuration you might
be running. For example, after you do this, any OSPF speakers on your
3550 will have to have their MTUs adjusted as well, or OSPF will not
come back up due to the interface mismatch. For more details see:

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configura
tion_example09186a008010edab.shtml#c4

Your best bet (in order of most preferable to least) is to a) fix
whatever is breaking path mtu discovery on the 7206vxr in the first
place, b) force the mss of the ibgp session to something under 1460, or
c) lower the mtu on the ds3 interface to 1500.

-- 
Richard A Steenbergen 
http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)

RE:

[Michael Ruiz]

And is that the one that traverses the 3550 with the 1500 byte MTU? 

Both connection traver through the 3550. I will disable the command on 7206 
vxr. thanks

-Original Message-
From: "Richard A Steenbergen" 
To: "Michael Ruiz" 
Cc: "Brian Dickson" ; "nanog@nanog.org" 

Sent: 9/16/09 8:58 PM
Subject: Re: 

On Wed, Sep 16, 2009 at 06:47:10PM -0500, Michael Ruiz wrote:
> >Either a) you have the mtu misconfigured on that 7206vxr
> 
> That part is where I am at a loss.  How is it the 6509 can establish a
> IBGP session with a 7606 when it has to go through the 7206 VXR?  The
> DS-3s are connected to the 7206 VXR. To add more depth to the story.  I
> have 8 IBGP sessions that are connected to the 7206 VXR that have been
> up and running for over a year.  Some of the sessions traverse the DS-3s
> and or a GigE long haul connections.  There are a total 10 Core routers
> that are mixture of Cisco 7606, 6509s, 7206 VXR w/ NPE400s or G1s.  Only
> this one IBGP session out of 9 routers is not being established.  Since
> I have a switch between the 7606 and 7206, I plan to put a packet
> capture server and see what I can see. 

And is that the one that traverses the 3550 with the 1500 byte MTU? 
Re-read what we said. You should be able to test the MTU theory by 
disabling path-mtu-discovery, which will cause MSS to fail back to the 
minimum 576.

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

RE:

[Michael Ruiz]

Oh you guys are going to love this...Before I could send out the maintenance 
notification for tonight to make changes,  The session has been up for 21 
hours.  This is before I could put a packet capture server on the segment.  
 


  BGP state = Established, up for 21:29:25
  Last read 00:00:24, last write 00:00:02, hold time is 180, keepalive interval 
is 60 seconds
  Neighbor capabilities:


-Original Message-
From: Michael Ruiz 
Sent: Thursday, September 17, 2009 7:47 AM
To: Richard A Steenbergen; Michael Ruiz
Cc: Brian Dickson; nanog@nanog.org
Subject: RE: 

And is that the one that traverses the 3550 with the 1500 byte MTU? 

Both connection traver through the 3550. I will disable the command on 7206 
vxr. thanks

-Original Message-
From: "Richard A Steenbergen" 
To: "Michael Ruiz" 
Cc: "Brian Dickson" ; "nanog@nanog.org" 

Sent: 9/16/09 8:58 PM
Subject: Re: 

On Wed, Sep 16, 2009 at 06:47:10PM -0500, Michael Ruiz wrote:
> >Either a) you have the mtu misconfigured on that 7206vxr
> 
> That part is where I am at a loss.  How is it the 6509 can establish a
> IBGP session with a 7606 when it has to go through the 7206 VXR?  The
> DS-3s are connected to the 7206 VXR. To add more depth to the story.  I
> have 8 IBGP sessions that are connected to the 7206 VXR that have been
> up and running for over a year.  Some of the sessions traverse the DS-3s
> and or a GigE long haul connections.  There are a total 10 Core routers
> that are mixture of Cisco 7606, 6509s, 7206 VXR w/ NPE400s or G1s.  Only
> this one IBGP session out of 9 routers is not being established.  Since
> I have a switch between the 7606 and 7206, I plan to put a packet
> capture server and see what I can see. 

And is that the one that traverses the 3550 with the 1500 byte MTU? 
Re-read what we said. You should be able to test the MTU theory by 
disabling path-mtu-discovery, which will cause MSS to fail back to the 
minimum 576.

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

RE:

[Michael Ruiz]

>http://cisco.cluepon.net/index.php/Using_capture_buffer_with_ELAM
>http://cisco.cluepon.net/index.php/6500_SPAN_the_RP

Well even the IBGP session came up on its own now and has been up for 1
day and 1 hour, I can honestly say this is bizarre situation.  I will
use the above links if something like this or weird happens.  Thank you
all. 

-Original Message-
From: Richard A Steenbergen [mailto:r...@e-gerbil.net] 
Sent: Thursday, September 17, 2009 1:11 PM
To: Michael Ruiz
Cc: Brian Dickson; nanog@nanog.org
Subject: Re: 

On Thu, Sep 17, 2009 at 09:17:00AM -0500, Michael Ruiz wrote:
> Oh you guys are going to love this...Before I could send out the
maintenance notification for tonight to make changes,  The session has
been up for 21 hours.  This is before I could put a packet capture
server on the segment.   
> 
> 
>   BGP state = Established, up for 21:29:25
>   Last read 00:00:24, last write 00:00:02, hold time is 180, keepalive
interval is 60 seconds
>   Neighbor capabilities:

You don't need to use an external sniffer, you can use "debug ip packet"
to see traffic being punted to the control plane, or in the case of the
6500 you can use ELAM or ERSPAN (though this is probably a little bit on
the advanced side). If this was an MTU mismatch a sniffer wouldn't
reveal anything other than missing packets anyways, which you could just
as easily deduce from a debug or looking at the retransmit counters on
the bgp neighbor.

http://cisco.cluepon.net/index.php/Using_capture_buffer_with_ELAM
http://cisco.cluepon.net/index.php/6500_SPAN_the_RP

My money is still on MTU mismatch. Assume the simplest and most likely 
explanation until proved otherwise.

-- 
Richard A Steenbergen 
http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)

nanog@nanog.org

[Michael Ruiz]

Hello Folks,

 

I am a different problem here this time It is on my Cisco 
12008.  I currently have two types of access cards installed into the chassis.  
I have a CHOC12-DS1/IR-SC card and a 6-CT3-SMB card.  I am running QOS on the 
unit.  I get this error when I do apply this command "tx-cos DS1-TX."  What 
brought this about was when t he service policy was entered the Queing strategy 
did not change. It still said FIFO. In slot 1 I have a channelized 6-CT3-SMB 
card installed.  Our previous engineer discovered that because the 6-CT3 card 
is an Engine 1 card and not an Engine 3 card, there are limitation of what you 
can do with the QOS of the line card itself.  So you have to setup almost like 
frame-relay type setup.   The question I have, is there limitation on the 
number of queuing strategies you can run at one time?

 

ar1.DLLSTXHW#show int ser 1/0/1:0

Serial1/0/1:0 is up, line protocol is up 

  Hardware is Channelized-T3

  Description:

  Internet address is 

  MTU 1500 bytes, BW 1536 Kbit, DLY 2 usec, rely 255/255, load 35/255

  Encapsulation PPP, crc 16, loopback not set

  Keepalive set (10 sec)

  LCP Open

  Open: IPCP

  Last input 00:00:01, output 00:00:01, output hang never

  Last clearing of "show interface" counters 00:13:45

  Queueing strategy: fifo --à

  Output queue 0/40, 0 drops; input queue 0/75, 0 drops

  5 minute input rate 97000 bits/sec, 56 packets/sec

  5 minute output rate 214000 bits/sec, 80 packets/sec

 45738 packets input, 9931625 bytes, 0 no buffer

 Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

 67213 packets output, 22609196 bytes, 0 underruns

 0 output errors, 0 collisions, 0 interface resets

 0 output buffer failures, 0 output buffers swapped out

 0 carrier transitions alarm present

  Timeslot(s) Used: 1-24, Transmitter delay is 0 flags

  non-inverted data

ar1.DLLSTXHW#show run int ser 1/0/1:0

Building configuration...

 

Current configuration : 271 bytes

!

interface Serial1/0/1:0

no ip redirects

 no ip unreachables

 no ip directed-broadcast

 no ip proxy-arp

 encapsulation ppp

 no cdp enable

 service-policy output VOICE

end

 

 

ar1.DLLSTXHW(config-if)#tx-cos DS1-TX

service-policy is already configured on interface, tx-cos is not allowed

 

On my Channelized OC12 facilities I use the service policy command to add my 
Policy MAP to the interface.

 

ar1.DLLSTXHW#show policy-map 

  Policy Map VOICE

Class VOICE

  priority 

Class class-default

  random-detect precedence-based

ar1.DLLSTXHW#show class

ar1.DLLSTXHW#show class-map 

 Class Map match-any class-default (id 0)

   Match any 

 

 Class Map match-any VOICE (id 7)

   Match ip  precedence 5 

 

ar1.DLLSTXHW#show access

ar1.DLLSTXHW#show access-lists VOICE

Extended IP access list VOICE

permit tcp any any eq 1720

permit udp any any eq 5060

permit udp any any range 4000 6000

permit udp any any range 16384 32767

permit udp any any range 6 65531

permit udp any any range 6001 6300

permit udp any any range 58000 5

permit udp any any range 32768 33000

permit udp any host 206.193.221.32

permit udp host 206.193.221.32 any

permit udp any host 206.193.221.36

permit udp host 206.193.221.36 any

permit udp any eq 5060 any eq 5060

permit udp any host 206.193.221.35

permit udp host 206.193.221.35 any

 

 

 

 

Michael Ruiz mr...@telwestservices.com <mailto::mr...@telwestservices.com> 

 

 

 

nanog@nanog.org

[Michael Ruiz]

I found the issue.  I found that one of the techs had applied the
service-policy against an interface that is on the 6-CT3 line card.
This caused the error I found.  I took out the service policy applied
and applied the tx-cos command and problem fixed. 

 

 

Michael Ruiz  mr...@telwestservices.com
<mailto::mr...@telwestservices.com> 

 

nanog@nanog.org

[Michael Ruiz]

Group,

 

I am stuck like chuck.  We are unable to activate a VPN
in one of the virtual firewall context.  Under the crypto commands, none
of the IP-sec are available.  Any help on this would be appreciated.
Version we running is 8.0(4)

 

 

Michael Ruiz mr...@telwestservices.com
<mailto::mr...@telwestservices.com> 

 

 

RE:

[Michael Ruiz]

Thank you for your help for this question.  Have a good day. 

-Original Message-
From: Tillinger, Steve [mailto:steve.tillin...@sourcemedia.com] 
Sent: Wednesday, October 07, 2009 12:00 PM
To: Michael Ruiz; nanog@nanog.org
Subject: RE: 

IPsec isn't available when in multiple context mode.



-Original Message-
From: Michael Ruiz [mailto:mr...@telwestservices.com] 
Sent: Wednesday, October 07, 2009 12:56 PM
To: nanog@nanog.org
Subject: 

Group,

 

I am stuck like chuck.  We are unable to activate a VPN
in one of the virtual firewall context.  Under the crypto commands, none
of the IP-sec are available.  Any help on this would be appreciated.
Version we running is 8.0(4)

 

 

Michael Ruiz mr...@telwestservices.com
<mailto::mr...@telwestservices.com> 

 

 


"This communication is intended solely for the addressee and is
confidential and not for third party unauthorized distribution"

Having trouble trying to activate a GigE connection>

[Michael Ruiz]

Group,

 

I am having an issue with activating a Gige interface
between a Cisco 7206 VXR w/IO-1GE module to a 7606 w/sup720-3bxls
connecting to a line module WS-X6416-GBIC.  I have verified that the
GBIC-MMF have good light reading and the MMF fiber jumper are not
reversed.  The GigE connection comes up briefly for about a few seconds,
takes a burst of errors and goes down.  I have tried to set the speed to
nonegotiate on both ends, set one end to speed auto.  No dice.  Here is
the copy of the configuration.  On my 7606 I show that the GigE
interface is up/up but on the 7206vxr I show down/down.  Any help will
be greatly appreciated.  Thanks!

 

This is the Cisco 7206VXR configuration.

 

interface GIabitEthernet0/0

no ip address

duplex full

speed 1000

media-type gbic

no negotiation auto

 

This is the Cisco 7606 configuration.

 

interface GigabitEthernet1/8

 description AR4-DLLSTXHW-GE0/0

 no ip address

 speed nonegotiate

 

 

 

Michael Ruiz

Network Engineer

 

 

RE: Having trouble trying to activate a GigE connection>

[Michael Ruiz]

>I don't think there is any reason to have hard-set speed and duplex,
>particularly between two Cisco's.  Why not just set *both* sides (you
>can't set just one) to auto-negotation - 'no speed nonegotiate' on the
>7606 side.  Is this a straight shot, single fiber pair between the two
>or are there intermediate junctions or optics?  It sounds like you have
>questionable fiber or optics in the path.  It could be the fiber itself
>or the GBICs on either side.

Mike,

I tried setting the 7206 to auto, and the 7606 to nonnegtiate,
however, no dice.  We put light meter on both ends of the GBIC and light
readings are at -20, which are applicable. Between the two routers are
MMF and it is straight shot with no transport equipment in between. 
 
-Original Message-
From: Michael K. Smith - Adhost [mailto:mksm...@adhost.com] 
Sent: Tuesday, November 24, 2009 10:25 AM
To: Michael Ruiz; nanog@nanog.org
Subject: RE:  Having trouble trying to activate a GigE
connection>

Hello Michael:

> -Original Message-
> From: Michael Ruiz [mailto:mr...@telwestservices.com]
> Sent: Tuesday, November 24, 2009 8:02 AM
> To: nanog@nanog.org
> Subject:  Having trouble trying to activate a GigE
connection>
> 
> Group,
> 
> 
> 
> I am having an issue with activating a Gige interface
> between a Cisco 7206 VXR w/IO-1GE module to a 7606 w/sup720-3bxls
> connecting to a line module WS-X6416-GBIC.  I have verified that the
> GBIC-MMF have good light reading and the MMF fiber jumper are not
> reversed.  The GigE connection comes up briefly for about a few
> seconds,
> takes a burst of errors and goes down.  I have tried to set the speed
> to
> nonegotiate on both ends, set one end to speed auto.  No dice.  Here
is
> the copy of the configuration.  On my 7606 I show that the GigE
> interface is up/up but on the 7206vxr I show down/down.  Any help will
> be greatly appreciated.  Thanks!
> 
> 
> 
I don't think there is any reason to have hard-set speed and duplex,
particularly between two Cisco's.  Why not just set *both* sides (you
can't set just one) to auto-negotation - 'no speed nonegotiate' on the
7606 side.  Is this a straight shot, single fiber pair between the two
or are there intermediate junctions or optics?  It sounds like you have
questionable fiber or optics in the path.  It could be the fiber itself
or the GBICs on either side.

Regards,

Mike

RE: Having trouble trying to activate a GigE connection>

[Michael Ruiz]

>I have seen this behavior caused by a mismatch of SFPs, SX on one side
>and LX on the other.

We found the problem.  After going through 5 MMF GBICS we found one that 
worked. 

-Original Message-
From: Peter Sandström [mailto:pe...@stardoll.com] 
Sent: Wednesday, November 25, 2009 12:39 PM
To: Michael Ruiz
Cc: Michael K. Smith - Adhost; nanog@nanog.org
Subject: Re:  Having trouble trying to activate a GigE connection>

I have seen this behavior caused by a mismatch of SFPs, SX on one side
and LX on the other.

/p

On Tue, Nov 24, 2009 at 9:04 AM, Michael Ruiz  wrote:
>>I don't think there is any reason to have hard-set speed and duplex,
>>particularly between two Cisco's.  Why not just set *both* sides (you
>>can't set just one) to auto-negotation - 'no speed nonegotiate' on the
>>7606 side.  Is this a straight shot, single fiber pair between the two
>>or are there intermediate junctions or optics?  It sounds like you have
>>questionable fiber or optics in the path.  It could be the fiber itself
>>or the GBICs on either side.
>
> Mike,
>
>        I tried setting the 7206 to auto, and the 7606 to nonnegtiate,
> however, no dice.  We put light meter on both ends of the GBIC and light
> readings are at -20, which are applicable. Between the two routers are
> MMF and it is straight shot with no transport equipment in between.
>
> -Original Message-
> From: Michael K. Smith - Adhost [mailto:mksm...@adhost.com]
> Sent: Tuesday, November 24, 2009 10:25 AM
> To: Michael Ruiz; nanog@nanog.org
> Subject: RE:  Having trouble trying to activate a GigE
> connection>
>
> Hello Michael:
>
>> -Original Message-
>> From: Michael Ruiz [mailto:mr...@telwestservices.com]
>> Sent: Tuesday, November 24, 2009 8:02 AM
>> To: nanog@nanog.org
>> Subject:  Having trouble trying to activate a GigE
> connection>
>>
>> Group,
>>
>>
>>
>>                 I am having an issue with activating a Gige interface
>> between a Cisco 7206 VXR w/IO-1GE module to a 7606 w/sup720-3bxls
>> connecting to a line module WS-X6416-GBIC.  I have verified that the
>> GBIC-MMF have good light reading and the MMF fiber jumper are not
>> reversed.  The GigE connection comes up briefly for about a few
>> seconds,
>> takes a burst of errors and goes down.  I have tried to set the speed
>> to
>> nonegotiate on both ends, set one end to speed auto.  No dice.  Here
> is
>> the copy of the configuration.  On my 7606 I show that the GigE
>> interface is up/up but on the 7206vxr I show down/down.  Any help will
>> be greatly appreciated.  Thanks!
>>
>>
>>
> I don't think there is any reason to have hard-set speed and duplex,
> particularly between two Cisco's.  Why not just set *both* sides (you
> can't set just one) to auto-negotation - 'no speed nonegotiate' on the
> 7606 side.  Is this a straight shot, single fiber pair between the two
> or are there intermediate junctions or optics?  It sounds like you have
> questionable fiber or optics in the path.  It could be the fiber itself
> or the GBICs on either side.
>
> Regards,
>
> Mike
>
>



-- 
Peter Sandström
Head of Operations, Stardoll AB
phone: +46 (0)70 456 05 28
e-mail: pe...@stardoll.com | stardoll: pj0tr
mail/visit: Hudiksvallsgatan 8, 113 30 Stockholm, Sweden
www.stardoll.com - Fame, fashion and friends

recommendation on vendor for 8 Cisco 7201 routers?

[Michael Ruiz]

IPV6 Training Books

[Michael Ruiz]

Hello All,

I am looking for some good reading material to get a better 
understanding of IPV6.  I know how to convert HEX into decimal format.  What I 
am looking for is how to under the CIDR notation and break them out into 
subnets.   Thank you in advance.

MAR.

IPv4 Address Exhaustion Effects on the Earth

[Michael Ruiz]

On Fri, Apr 1, 2011 at 8:30 PM, Robert Bonomi https://mailman.nanog.org/mailman/listinfo/nanog>> wrote:

>

>> Date: Sat, 02 Apr 2011 04:18:00 +0200

>> From: Alexander Maassen > scarynet.org>

>> Subject: Re: IPv4 Address Exhaustion Effects on the Earth

>>

>> wil,

>> maybe after all this time you got the router, it gained 7lbs of all the

>> dust in it ?

>

> Consider what happens if the carrier encounters a route reflector --

> flipping the bird??



>Also how port mirrors will cause a collision and the bird will die.

Speaking of birds and electromagnetic field, I wonder if birds are going to 
crashing into things like they did in the core.  Now that would be pretty 
interesting.

MAR.

RE: recommendation on vendor for 8 Cisco 7201 routers?

[Michael Ruiz]

Cool  How is their service?  Do they Telecom equipment.  For example, Adtran 
and Fujitsu equipment?

-Original Message-
From: David DiGiacomo [mailto:dav...@corp.nac.net] 
Sent: Monday, April 04, 2011 2:49 PM
To: Michael Ruiz; nanog@nanog.org
Subject: RE: recommendation on vendor for 8 Cisco 7201 routers?

Michael, 

I have had excellent service from OSI Hardware, they sell new & used at a 
pretty good price. They have 18 month warranties and I've had stuff ship same 
day  and on my doorstep first thing in the morning.

The guy I deal with is Stephen Craig,  scr...@osihardware.com , (214) 267-8519

Good luck
Dave D




Dave Joel DiGiacomo "dav...@corp.nac.net"
Network Engineer / Peering Coordinator
Net Access Corp
Network Operations Center
973-590-5050


-Original Message-
From: Michael Ruiz [mailto:mr...@lstfinancial.com] 
Sent: Monday, April 04, 2011 3:36 PM
To: nanog@nanog.org
Subject: recommendation on vendor for 8 Cisco 7201 routers?

RE: recommendation on vendor for 8 Cisco 7201 routers?

[Michael Ruiz]

Ok cool.  I will keep them mind for Cisco equipment.  Thank you sir for your 
reply.

-Original Message-
From: David DiGiacomo [mailto:dav...@corp.nac.net] 
Sent: Monday, April 04, 2011 3:06 PM
To: Michael Ruiz; nanog@nanog.org
Subject: RE: recommendation on vendor for 8 Cisco 7201 routers?

We have been dealing with them for close to a year now and the service has been 
pretty astonishing thus far. I can usually get a price quote within an hour, 
their prices are usually lower than my other vendors and I can get orders 
shipped the same day. They back everything with an 18 month warranty and I have 
never had to use it yet (knock on wood).  I can tell you I trust them and they 
have not let me down yet.  They do sell optics for Adtran and Fujitsu but they 
do not stock hardware for that equipment.




Dave Joel DiGiacomo "dav...@corp.nac.net"
Network Engineer / Peering Coordinator
Net Access Corp
Network Operations Center
973-590-5050


-Original Message-----
From: Michael Ruiz [mailto:mr...@lstfinancial.com] 
Sent: Monday, April 04, 2011 3:52 PM
To: David DiGiacomo; nanog@nanog.org
Subject: RE: recommendation on vendor for 8 Cisco 7201 routers?

Cool  How is their service?  Do they Telecom equipment.  For example, Adtran 
and Fujitsu equipment?

-Original Message-
From: David DiGiacomo [mailto:dav...@corp.nac.net] 
Sent: Monday, April 04, 2011 2:49 PM
To: Michael Ruiz; nanog@nanog.org
Subject: RE: recommendation on vendor for 8 Cisco 7201 routers?

Michael, 

I have had excellent service from OSI Hardware, they sell new & used at a 
pretty good price. They have 18 month warranties and I've had stuff ship same 
day  and on my doorstep first thing in the morning.

The guy I deal with is Stephen Craig,  scr...@osihardware.com , (214) 267-8519

Good luck
Dave D




Dave Joel DiGiacomo "dav...@corp.nac.net"
Network Engineer / Peering Coordinator
Net Access Corp
Network Operations Center
973-590-5050


-Original Message-
From: Michael Ruiz [mailto:mr...@lstfinancial.com] 
Sent: Monday, April 04, 2011 3:36 PM
To: nanog@nanog.org
Subject: recommendation on vendor for 8 Cisco 7201 routers?

RE: IPV6 Training Books

[Michael Ruiz]

Thank you all for replying.  

-Original Message-
From: Stefan Fouant [mailto:sfou...@shortestpathfirst.net] 
Sent: Monday, April 04, 2011 3:23 PM
To: Michael Ruiz; nanog@nanog.org
Subject: RE: IPV6 Training Books

> -Original Message-
> From: Michael Ruiz [mailto:mr...@lstfinancial.com]
> Sent: Monday, April 04, 2011 3:43 PM
> To: nanog@nanog.org
> Subject: IPV6 Training Books
> 
> Hello All,
> 
> I am looking for some good reading material to get a
> better understanding of IPV6.  I know how to convert HEX into decimal
> format.  What I am looking for is how to under the CIDR notation and
> break them out into subnets.   Thank you in advance.

I recommend 'Running IPv6' by Iljitsch van Beijnum or 'IPv6 Essentials' by
Silvia Hagen.  Also Chris Grundemann wrote a Day One Guide for Juniper
entitled "Exploring IPv6" which you can download for free at
http://forums.juniper.net/t5/Day-One-Books/Day-One-Book-Exploring-IPv6/ba-p/
52402 - Chapter 1 in the Day One guide has a lot of really good information
on understanding IPv6 addressing formats, subnetting, etc. 

Either one of those should be able to answer most of your questions.

Stefan Fouant