Re: [c-nsp] Wanting to learn Juniper...

2008-04-13 Thread Mark Tinka
On Friday 11 April 2008, Wink wrote:

 It seems easier to find things w/reference to the
 routing-instance you are dealing with or the interface
 you are dealing with at the moment, within the
 configuration.

I've had a chance to play around with IOS XR - it's a good 
thing Cisco have done something like this in this software 
with 'sh configuration options'.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] NPE-G2 12.2(33)SRC AFI Bug?

2008-04-13 Thread Mark Tinka
Hi all.

We are lab'ing 12.2(33)SRC on an NPE-G2.

We see the VPNv4 AFI configuration saving a duplicate 
configuration for a peer policy template inheritance:

...
!
 address-family vpnv4
  neighbor x.x.x.x activate
  neighbor x.x.x.x send-community extended
  neighbor x.x.x.x inherit peer-policy rr-peers-l3vpn
  neighbor x.x.x.x inherit peer-policy rr-peers-l3vpn
  neighbor y.y.y.y activate
  neighbor y.y.y.y send-community extended
  neighbor y.y.y.y inherit peer-policy rr-peers-l3vpn
  neighbor y.y.y.y inherit peer-policy rr-peers-l3vpn
 exit-address-family
...

Deleting the inheritance deletes both instances of it. 
Replacing a single instance of it sets up a duplicate as 
shown above.

A similar configuration on an NPE-G1 does not yield this 
issue.

Is this a bug? Anyone else seen this?

...
lab#sh ver | i IOS
Cisco IOS Software, 7200 Software 
(C7200P-ADVENTERPRISEK9-M), Version 12.2(33)SRC, RELEASE 
SOFTWARE (fc3)
lab#

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] csm Bride Mode Simple scenario. Is it Possible?

2008-04-13 Thread Brad Case
Hey,

Sorry guys, I have one last CSM query which relates directly to the below.
In the customers network  1 of the 2 VIP's  is actually used for server to
server load balancing.

So to simplify 3 servers all reside in the same subnet.

The addresses are the following:

server A: 10.20.220.11
server B: 10.20.220.12
server C: 10.20.220.15

Server A  B are in a serverfarm  the VIP address is 50.40.220.100

Server C needs to communicate to the VIP address of 50.40.220.100 to load
balance to servers A  B

Configuring ths up in Routed mode on the CSM is easy, however, in bridge
mode I am not  so sure. Below is the configuration which I think should work
(I cannot test it)   Presuming it does I am a little concerned with things
such as ICMP redirect occuring from the MSFC interface. Anyway, I would
really appreciate peoples input on the configuration:




vlan 221 client
   ip address 10.20.220.2 255.255.255.0
   gateway 10.20.220.1
  !
  vlan 220 server
   ip address 10.20.220.2 255.255.255.0
   Two VLANs with the same IP address are bridged
  together.

  serverfarm WEBFARM
   nat server
   nat client SABRIX
   real 10.20.220.11
   inservice
   real 10.20.220.12
   inservice
  !
  vserver WEB
   virtual 50.40.220.100 tcp www
  Place the IP address in a different subnet than the IP's in the
serverfarm 
  serverfarm WEBFARM
persistent rebalance
 inservice

natpool SABRIX 10.20.220.55 10.20.220.55 netmask 255.255.255.0


Interface Vlan 221
ip address 10.20.220.1


  On the MSFC place a static route to route the 50.40.220.100

  address towards the CSM IP on vlan 221.

  ip route 50.40.220.100 255.255.255.255 10.20.220.2


interface GigabitEthernet6/31
 description Server A
 switchport
 switchport access vlan 220
 switchport mode access


interface GigabitEthernet6/32
 description Server B
 switchport
 switchport access vlan 220
 switchport mode access

interface GigabitEthernet6/33
 description Server C
 switchport
 switchport access vlan 221
 switchport mode access


On Server C the default gateway is obviously going towards the MSFC address
of 10.20.220.1.  No other routes are defined on the server.

Anyones input is highly appreciated.

Regards,

Brad














On Thu, Apr 10, 2008 at 12:03 AM, Ross Vandegrift [EMAIL PROTECTED] wrote:

 On Wed, Apr 09, 2008 at 11:02:06PM +1000, Brad Case wrote:
  I actually asked this same question to Cisco. The official response I
 got
  was this:
 
  Extract:
 
 
  This should work to some extent. However, for the large network I don't
 know
  how reliable you can run this system for sure.
 
  You are basically forcing static route in MSFC to forward traffic to the
  client vlan of the CSM. This is not something desirable way to do
 routing on
  the CSM. Especially bridge mode.

 This response is completely bogus and highlights why I am frustrated
 with Cisco's support for the CSM.  I have only ever heard of two
 people at Cisco that really understood the thing, and I've personally
 only talked to one.

  There will only be 2 VIP's setup this way  never anymore. There will
  be many additional VIPs  that will be created using an VIP IP in the
 same
  address range as the real server addresses (Text book scenario).
  If the customer were to change the 2 VIP addresses it requires a massive
  amount of logistics to do so, hence the reason why I am considering
 doing it
  this way.
 
 
  I would really like to here what people have to say in relation to this
  response  if I should be concerned in doing it like this for just 2
 VIP's
  only.

 I have over 400 VIPs on a CSM running in this way, in bridged mode,
 without
 advertise active.  Any IP can be used as a VIP so long as traffic to that
 IP
 ends up directed to the CSM's client VLAN IP.

 The easiest way to do this is add a static route for the VIP to the
 CSM's client IP on the MSFC.  So for your example below, you would need
 ip route 50.40.220.99 255.255.255.255 10.20.220.2.

 If you have an FT setup, you'll want the next-hop to be the client
 VLAN's alias IP.


 Ross

 
 
  Regards,
 
  Brad
 
 
 
 
 
  On Tue, Apr 8, 2008 at 5:59 PM, Arie Vayner (avayner) [EMAIL PROTECTED]
 
  wrote:
 
   Brad,
  
   You should just make sure the virtual IP is routable on the MSFC. The
   best way is to use the advertise command on the virtual server.
  
   Arie
  
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED] On Behalf Of Brad Case
   Sent: Tuesday, April 08, 2008 02:27 AM  To:
 cisco-nsp@puck.nether.net
   Subject: [c-nsp] csm Bride Mode Simple scenario. Is it Possible?
  
   Hi Guys,
   I have a question that I simply cannot find an answer to on the Cisco
   site in regards to the CSM in Bridge mode.
   Is it possible to have the vserver (VIP) IP in a differnt subnet range
   than the real IP addresses in the serverfarm that is bound to it?
  
   In other words, as an example a typical bridge configuration is like
   this:
  
  
  
   vlan 221 client
ip address 10.20.220.2 

Re: [c-nsp] csm Bride Mode Simple scenario. Is it Possible?

2008-04-13 Thread Arie Vayner (avayner)
Ross,

The only issue I see with using different VIP addresses has to do with
pushing the traffic to the CSM, which can be solved by different routing
mechanisms. The routing tweaks are sometimes not elegant, but are not
much different in a case where you use an external load balancer
(especially in bridge mode).

When a VIP is active on the CSM it would be registered in the hardware
IXPs and there should not be any difference how the routing is done at
this stage...

I would be happy to assist with any further questions.

Arie

-Original Message-
From: Ross Vandegrift [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 09, 2008 17:03 PM
To: Brad Case
Cc: Arie Vayner (avayner); cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] csm Bride Mode Simple scenario. Is it Possible?

On Wed, Apr 09, 2008 at 11:02:06PM +1000, Brad Case wrote:
 I actually asked this same question to Cisco. The official response I 
 got was this:
 
 Extract:
 
 
 This should work to some extent. However, for the large network I 
 don't know how reliable you can run this system for sure.
 
 You are basically forcing static route in MSFC to forward traffic to 
 the client vlan of the CSM. This is not something desirable way to do 
 routing on the CSM. Especially bridge mode.

This response is completely bogus and highlights why I am frustrated
with Cisco's support for the CSM.  I have only ever heard of two people
at Cisco that really understood the thing, and I've personally only
talked to one.

 There will only be 2 VIP's setup this way  never anymore. There 
 will be many additional VIPs  that will be created using an VIP IP in 
 the same address range as the real server addresses (Text book
scenario).
 If the customer were to change the 2 VIP addresses it requires a 
 massive amount of logistics to do so, hence the reason why I am 
 considering doing it this way.
 
 
 I would really like to here what people have to say in relation to 
 this response  if I should be concerned in doing it like this for 
 just 2 VIP's only.

I have over 400 VIPs on a CSM running in this way, in bridged mode,
without advertise active.  Any IP can be used as a VIP so long as
traffic to that IP ends up directed to the CSM's client VLAN IP.

The easiest way to do this is add a static route for the VIP to the
CSM's client IP on the MSFC.  So for your example below, you would need
ip route 50.40.220.99 255.255.255.255 10.20.220.2.

If you have an FT setup, you'll want the next-hop to be the client
VLAN's alias IP.


Ross

 
 
 Regards,
 
 Brad
 
 
 
 
 
 On Tue, Apr 8, 2008 at 5:59 PM, Arie Vayner (avayner) 
 [EMAIL PROTECTED]
 wrote:
 
  Brad,
 
  You should just make sure the virtual IP is routable on the MSFC. 
  The best way is to use the advertise command on the virtual
server.
 
  Arie
 
  -Original Message-
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Brad Case
  Sent: Tuesday, April 08, 2008 02:27 AM  To: 
  cisco-nsp@puck.nether.net
  Subject: [c-nsp] csm Bride Mode Simple scenario. Is it Possible?
 
  Hi Guys,
  I have a question that I simply cannot find an answer to on the 
  Cisco site in regards to the CSM in Bridge mode.
  Is it possible to have the vserver (VIP) IP in a differnt subnet 
  range than the real IP addresses in the serverfarm that is bound to
it?
 
  In other words, as an example a typical bridge configuration is like
  this:
 
 
 
  vlan 221 client
   ip address 10.20.220.2 255.255.255.0  gateway 10.20.220.1 !
  vlan 220 server
   ip address 10.20.220.2 255.255.255.0 Two VLANs with the

  same IP address are bridged
  together.
  serverfarm WEBFARM
   nat server
   no nat client
   real 10.20.220.10
   inservice
   real 10.20.220.20
   inservice
  !
  vserver WEB
   virtual 10.20.220.100 tcp www
   serverfarm WEBFARM
   persistent rebalance
   inservice
 
 
 
  Is it possible to do something like this:
 
  vlan 221 client
   ip address 10.20.220.2 255.255.255.0  gateway 10.20.220.1 !
  vlan 220 server
   ip address 10.20.220.2 255.255.255.0  Two VLANs with 
  the same IP address are bridged
  together.
 
  serverfarm WEBFARM
   nat server
   no nat client
   real 10.20.220.10
   inservice
   real 10.20.220.20
   inservice
  !
  vserver WEB
   virtual 50.40.220.99 tcp www Place the IP address in
a
  different subnet than the IP's in the serverfarm  
  serverfarm WEBFARM  persistent rebalance  inservice
 
 
  On the MSFC place a static route to route the 50.40.220.99 
  address towards the CSM IP on vlan 221.
 
  ip route 50.40.220.99 255.255.255.255 10.20.220.2
 
 
  Please if somebody knows if this is or is not possible it would be 
  highly appreciated to hear your feedback.
 
 
  Regards,
 
  Brad
   ___
  cisco-nsp mailing list  cisco-nsp@puck.nether.net 
  https://puck.nether.net/mailman/listinfo/cisco-nsp
  archive at http://puck.nether.net/pipermail/cisco-nsp/
 
 ___
 cisco-nsp mailing list  

Re: [c-nsp] csm Bride Mode Simple scenario. Is it Possible?

2008-04-13 Thread Arie Vayner (avayner)
Brad,

There is an alternative for client nat, which is usually not recommended
as it makes reporting and other mechanisms which rely on the source IP
to be unique.

The idea is to configure the VIP address (50.40.220.100) as a loopback
on the real servers. Then, disable nat server on the serverfarm. This
would send the queries to the real server with the VIP's IP (which would
be fine, as the real server has this IP locally configured).
In the situation when a local server is the client, this would allow the
server (after load balancing) to send the response directly to the
server.

Another approach is to have a different vserver (with the same IP
address) by configuring the client VLAN inside the vserver. Take a look
here:
http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/csm/
4.2.x/configuration/guide/cfgxpls.html#wp1008442 

Arie

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brad Case
Sent: Sunday, April 13, 2008 12:30 PM
To: Ross Vandegrift
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] csm Bride Mode Simple scenario. Is it Possible?

Hey,

Sorry guys, I have one last CSM query which relates directly to the
below.
In the customers network  1 of the 2 VIP's  is actually used for server
to server load balancing.

So to simplify 3 servers all reside in the same subnet.

The addresses are the following:

server A: 10.20.220.11
server B: 10.20.220.12
server C: 10.20.220.15

Server A  B are in a serverfarm  the VIP address is 50.40.220.100

Server C needs to communicate to the VIP address of 50.40.220.100 to
load balance to servers A  B

Configuring ths up in Routed mode on the CSM is easy, however, in bridge
mode I am not  so sure. Below is the configuration which I think should
work
(I cannot test it)   Presuming it does I am a little concerned with
things
such as ICMP redirect occuring from the MSFC interface. Anyway, I would
really appreciate peoples input on the configuration:




vlan 221 client
   ip address 10.20.220.2 255.255.255.0
   gateway 10.20.220.1
  !
  vlan 220 server
   ip address 10.20.220.2 255.255.255.0
   Two VLANs with the same IP address are bridged
  together.

  serverfarm WEBFARM
   nat server
   nat client SABRIX
   real 10.20.220.11
   inservice
   real 10.20.220.12
   inservice
  !
  vserver WEB
   virtual 50.40.220.100 tcp www
  Place the IP address in a different subnet than the IP's in
the serverfarm 
  serverfarm WEBFARM
persistent rebalance
 inservice

natpool SABRIX 10.20.220.55 10.20.220.55 netmask 255.255.255.0


Interface Vlan 221
ip address 10.20.220.1


  On the MSFC place a static route to route the 50.40.220.100

  address towards the CSM IP on vlan 221.

  ip route 50.40.220.100 255.255.255.255 10.20.220.2


interface GigabitEthernet6/31
 description Server A
 switchport
 switchport access vlan 220
 switchport mode access


interface GigabitEthernet6/32
 description Server B
 switchport
 switchport access vlan 220
 switchport mode access

interface GigabitEthernet6/33
 description Server C
 switchport
 switchport access vlan 221
 switchport mode access


On Server C the default gateway is obviously going towards the MSFC
address of 10.20.220.1.  No other routes are defined on the server.

Anyones input is highly appreciated.

Regards,

Brad














On Thu, Apr 10, 2008 at 12:03 AM, Ross Vandegrift [EMAIL PROTECTED]
wrote:

 On Wed, Apr 09, 2008 at 11:02:06PM +1000, Brad Case wrote:
  I actually asked this same question to Cisco. The official response 
  I
 got
  was this:
 
  Extract:
 
 
  This should work to some extent. However, for the large network I 
  don't
 know
  how reliable you can run this system for sure.
 
  You are basically forcing static route in MSFC to forward traffic to

  the client vlan of the CSM. This is not something desirable way to 
  do
 routing on
  the CSM. Especially bridge mode.

 This response is completely bogus and highlights why I am frustrated 
 with Cisco's support for the CSM.  I have only ever heard of two 
 people at Cisco that really understood the thing, and I've personally 
 only talked to one.

  There will only be 2 VIP's setup this way  never anymore. There 
  will be many additional VIPs  that will be created using an VIP IP 
  in the
 same
  address range as the real server addresses (Text book scenario).
  If the customer were to change the 2 VIP addresses it requires a 
  massive amount of logistics to do so, hence the reason why I am 
  considering
 doing it
  this way.
 
 
  I would really like to here what people have to say in relation to 
  this response  if I should be concerned in doing it like this for 
  just 2
 VIP's
  only.

 I have over 400 VIPs on a CSM running in this way, in bridged mode, 
 without advertise active.  Any IP can be used as a VIP so long as 
 traffic to that IP ends up directed to the CSM's client VLAN IP.

 The easiest way to do this is add a static route for the VIP to the 
 CSM's client IP on the MSFC.  So for 

Re: [c-nsp] OSPFv3 down every 34 minutes

2008-04-13 Thread Brad Henshaw
Eric Van Tol wrote:
 
 In any case, the question now is, what would cause so many
 neighbors to retransmit and why on only one router?
 
Packet loss or congestion on the physical links/interfaces
connecting to this router?
 
Not sure why it'd be every 34 minutes though. If it were every
/30/ minutes, the OSPF refresh would be a real suspect.

I notice input drops are shown for int vl2. Check these for
the relevant physical interface(s) also.
 
~Brad
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] OSPFv3 down every 34 minutes

2008-04-13 Thread Eric Van Tol
Hi Brad,
Thanks for the response.  I saw those drops, but they don't come close to the 
amount of times this is occurring.  This happens literally, every 34 minutes 
(okay, 33 minutes and some seconds :-) ):

Apr 13 06:13:03 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 06:13:03 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 06:13:07 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 06:46:52 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 06:46:53 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 06:46:57 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 07:20:35 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 07:20:36 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 07:20:40 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 07:53:48 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 07:53:49 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 07:53:52 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 08:27:36 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 08:27:37 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 08:27:42 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 09:01:31 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 09:01:31 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits
Apr 13 09:01:35 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from 
FULL to DOWN, Neighbor Down: Too many retransmits

The interfaces all show the same info:

  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0

On the Vlan2 interface, I show one more drop since I sent the original message 
on Friday:

  Input queue: 0/75/17/17 (size/max/drops/flushes); Total output drops: 0

I'm baffled at this point.  I'll likely be moving to IS-IS soon, but this is 
one of those problems that really makes you wonder.


From: Brad Henshaw [EMAIL PROTECTED]
Sent: Sunday, April 13, 2008 9:13 AM
To: Eric Van Tol; cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] OSPFv3 down every 34 minutes

Eric Van Tol wrote:

 In any case, the question now is, what would cause so many
 neighbors to retransmit and why on only one router?

Packet loss or congestion on the physical links/interfaces
connecting to this router?

Not sure why it'd be every 34 minutes though. If it were every
/30/ minutes, the OSPF refresh would be a real suspect.
I notice input drops are shown for int vl2. Check these for
the relevant physical interface(s) also.

~Brad
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


[c-nsp] 7200vxr-npe400/512mb - how much BGP?

2008-04-13 Thread Skeeve Stevens

OK,

Just how much BGP should a 7200vxr-NPE400 with 512MB of RAM be able to
handle.

Presently:

Neighbor  V AS  MsgRcvd   MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
XXX.XXX.XXX.XXX   4 xxx 1500420   942940  6027573000   2d06h
5634
XXX.XXX.XXX.XXX   4 xxx 15883688  468471  6027574800   00:48:01
249967
XXX.XXX.XXX.XXX   4 xxx 19556635  471877  6027574600   16w5d
248964

So at present, 2 world feeds and a feed from an IX.

BGP table version is 60275748, main routing table version 60275748
251459 network entries using 24391523 bytes of memory
504651 path entries using 18167436 bytes of memory
86074 BGP path attribute entries using 5164680 bytes of memory
77392 BGP AS-PATH entries using 2340778 bytes of memory
525 BGP community entries using 27544 bytes of memory
43080 BGP route-map cache entries using 689280 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 50781241 total bytes of memory
66 received paths for inbound soft reconfiguration
BGP activity 3758774/3507315 prefixes, 31401381/30896730 paths, scan
interval 60 secs

From what I can see, 50781241 total bytes of memory is about 50mb of RAM.

The router currently says Total: 466497056, Used: 200153224, Free:
266343832

When should I start worrying about how big the tables are growing and so on?


.Skeeve

--
Skeeve Stevens, RHCE
[EMAIL PROTECTED] / www.skeeve.org
Cell +61 (0)414 753 383 / skype://skeeve

eintellego - [EMAIL PROTECTED] - www.eintellego.net 
--
I'm a groove licked love child king of the verse 
Si vis pacem, para bellum


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] OSPFv3 down every 34 minutes

2008-04-13 Thread Ben Steele
Does a sh standby 1 show any hsrp state changes? might also be worth  
setting up an ip sla probe to your neighbor for the 34 minutes to  
probe every second and just see if it fails at all when you lose your  
OSPF neighbor, that way you can discard OSPF from the problem and look  
into what is causing your dataflow issue.

Ben

On 13/04/2008, at 11:10 PM, Eric Van Tol wrote:

 Hi Brad,
 Thanks for the response.  I saw those drops, but they don't come  
 close to the amount of times this is occurring.  This happens  
 literally, every 34 minutes (okay, 33 minutes and some seconds :-) ):

 Apr 13 06:13:03 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 06:13:03 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 06:13:07 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 06:46:52 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 06:46:53 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 06:46:57 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 07:20:35 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 07:20:36 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 07:20:40 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 07:53:48 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 07:53:49 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 07:53:52 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 08:27:36 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 08:27:37 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 08:27:42 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 09:01:31 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 09:01:31 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits
 Apr 13 09:01:35 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on  
 Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits

 The interfaces all show the same info:

  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output  
 drops: 0

 On the Vlan2 interface, I show one more drop since I sent the  
 original message on Friday:

  Input queue: 0/75/17/17 (size/max/drops/flushes); Total output  
 drops: 0

 I'm baffled at this point.  I'll likely be moving to IS-IS soon, but  
 this is one of those problems that really makes you wonder.

 
 From: Brad Henshaw [EMAIL PROTECTED]
 Sent: Sunday, April 13, 2008 9:13 AM
 To: Eric Van Tol; cisco-nsp@puck.nether.net
 Subject: RE: [c-nsp] OSPFv3 down every 34 minutes

 Eric Van Tol wrote:

 In any case, the question now is, what would cause so many
 neighbors to retransmit and why on only one router?

 Packet loss or congestion on the physical links/interfaces
 connecting to this router?

 Not sure why it'd be every 34 minutes though. If it were every
 /30/ minutes, the OSPF refresh would be a real suspect.
 I notice input drops are shown for int vl2. Check these for
 the relevant physical interface(s) also.

 ~Brad
 ___
 cisco-nsp mailing list  cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] 7200vxr-npe400/512mb - how much BGP?

2008-04-13 Thread Niels Bakker
* [EMAIL PROTECTED] (Skeeve Stevens) [Sun 13 Apr 2008, 16:55 CEST]:
 Just how much BGP should a 7200vxr-NPE400 with 512MB of RAM be able to 
 handle.

Are you seeing problems?  I'm loading 1.8 million paths in exactly such 
a router, with plenty headroom.  Some IOS versions leak memory like a 
sieve (and some leak only a little), though.  This is 12.2(28)SB10, an 
example of the latter; SB6 was an example of the former.  12.2(14)S3 ran 
literally for years and years on this particular router.


 When should I start worrying about how big the tables are growing and 
 so on?

When the router starts complaining about lack of memory.  Personally my 
biggest worry with the above router is convergence time after more than 
a few BGP peers flap (which has actually gotten much better with SB over S).


-- Niels.

-- 
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] OSPFv3 down every 34 minutes

2008-04-13 Thread Gregory Boehnlein
 Hi Brad,
 Thanks for the response.  I saw those drops, but they don't come close
 to the amount of times this is occurring.  This happens literally,
 every 34 minutes (okay, 33 minutes and some seconds :-) ):

Maybe you have a Cylon infiltrator hiding in your network? :)

http://www.scifi.com/battlestar/episodes/episodes.php?seas=1ep=101act=1

In the wake of the Cylon sneak attack, the ragtag fleet of human survivors
is forced to play a deadly game of cat-and-mouse with their pursuers. Every
33 minutes, they make a jump to a new location. And every 33 minutes, the
Cylons manage to find them. The pilots are on the brink of exhaustion,
relying on artificial stimulants to keep fighting, and the civilians are
beginning to doubt the leadership of Commander Adama and President Roslin.



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] 7200vxr-npe400/512mb - how much BGP?

2008-04-13 Thread Justin M. Streiner
On Mon, 14 Apr 2008, Skeeve Stevens wrote:

 Just how much BGP should a 7200vxr-NPE400 with 512MB of RAM be able to
 handle.
 
 The router currently says Total: 466497056, Used: 200153224, Free:
 266343832

 When should I start worrying about how big the tables are growing and so on?

512 MB is the minimum I'd consider using for a router that will be 
carrying full BGP feeds, but in this case, the limiting factor might not 
be memory availability, but rather the CPU, since everything in the 7200 
series is done in software.  Do you notice your CPU usage spiking 
periodically (around once a minute), and is a large chunk of the CPU tied 
up un the BGP Scanner process?

If you have a tool for graphing and trending stuff like that over time 
(MRTG, Cricket, many others), you may want to set up something to monitor 
that CPU utilization, paying attnetion to both the 5 second and 5 minute 
CPU utilization values in the MIBs.  The 5 second value will help you 
catch transient spikes that get washed out of the 5-minute average 
values.  The output ends up more closely resembling the output of show 
proc cpu hist.  When the utilization starts regularly getting close to 
100%, it's time to think about an upgrade.

I wouldn't worry so much about one or two errant spikes, but when things 
regularly get that high, it could manifest itself in the form of increased 
latency in getting traffic through the box, or if things get bad enough, 
the router starts missing BGP update messages or similar messages for your 
IGP, and sessions/adjacencies can start dropping, which only makes the CPU 
thrashing problem worse.

jms
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] Cat4500 and bandwidth per slot

2008-04-13 Thread Asbjorn Hojmark - Lists
 And what about Cat6500 and Sup32 ? How much Gbps per slot and 
 half-duplex or full-duplex ?

With a Sup32, the line run on a 16 Gbps shared bus. (No, it's
not full duplex. It's a bus. 32 is pure marketing). Since it's
shared, any one of the line cards can use all of the bandwidth,
if it's available.

-A

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] Cat6500 - Support for MPLS and IPv6

2008-04-13 Thread Asbjorn Hojmark - Lists
 Cross our fingers what? Cross our fingers that they'll neglect
 IOS in favour of IOS XE? How does that help anyone?

IOS XE *is* IOS. It 'just' runs on another kernel.

 Honestly, I don't mean to sound too combative, but Cisco do 
 not need to be diversifying at this point; they need to be
 focussing.

Yes, but IOS 'classic' clearly doesn't have the infrastructure
needed. (If it did, the BUs would not all work on something
different).

-A

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] Cat6500 - Support for MPLS and IPv6

2008-04-13 Thread Asbjorn Hojmark - Lists
 The issue is not an attempt to re-architect. It's 4 (ION, 
 IOS-XR, NS-OS, IOS XE), on platforms with partially overlap-
 ping coverage.

IMO there's a pretty big difference between building software
for a pure core, for a data center with lots of L2 and SAN, and
'IOS with *all* the features, reworked'.

Would it be great to have a single OS for all of it? Well, then
you'd only have to learn one, obviously, but it sure wouldn't be
good for 'time to market' (feature velocity)... and you'd still
have all the hardware differences.

-A

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] 7200vxr-npe400/512mb - how much BGP?

2008-04-13 Thread Ibrahim Abo Zaid
I agree with Justin , currently it seems you don't have any memory problem
but you need to worry about box CPU especially BGP isn't the only active
process here and you need to monitor processor utilization closely and if
you faced sporadic peaks you can use show process cpu sorted command to
catch up the process eating the resource and isolate the peak trigger , is
it BGP scanner or IP Input process etc , ..

and finally in such cases there are some processes appears as the
*reason*behind high CPU but actually those ara
*results* of other causes so these problems needs accurate investigation and
always check IOS caveats as sometimes processing problems yields of coding
caveats


On 4/13/08, Justin M. Streiner [EMAIL PROTECTED] wrote:

 On Mon, 14 Apr 2008, Skeeve Stevens wrote:

  Just how much BGP should a 7200vxr-NPE400 with 512MB of RAM be able to
  handle.
 
  The router currently says Total: 466497056, Used: 200153224, Free:
  266343832
 
  When should I start worrying about how big the tables are growing and so
 on?

 512 MB is the minimum I'd consider using for a router that will be
 carrying full BGP feeds, but in this case, the limiting factor might not
 be memory availability, but rather the CPU, since everything in the 7200
 series is done in software.  Do you notice your CPU usage spiking
 periodically (around once a minute), and is a large chunk of the CPU tied
 up un the BGP Scanner process?

 If you have a tool for graphing and trending stuff like that over time
 (MRTG, Cricket, many others), you may want to set up something to monitor
 that CPU utilization, paying attnetion to both the 5 second and 5 minute
 CPU utilization values in the MIBs.  The 5 second value will help you
 catch transient spikes that get washed out of the 5-minute average
 values.  The output ends up more closely resembling the output of show
 proc cpu hist.  When the utilization starts regularly getting close to
 100%, it's time to think about an upgrade.

 I wouldn't worry so much about one or two errant spikes, but when things
 regularly get that high, it could manifest itself in the form of increased
 latency in getting traffic through the box, or if things get bad enough,
 the router starts missing BGP update messages or similar messages for your
 IGP, and sessions/adjacencies can start dropping, which only makes the CPU
 thrashing problem worse.

 jms
 ___
 cisco-nsp mailing list  cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


[c-nsp] News Item: Cisco Turns Routers Into Linux Application Servers

2008-04-13 Thread Skeeve Stevens
I haven't seen anything here about this, so ..

http://www.internetnews.com/dev-news/article.php/3740106/Cisco+Turns+Routers
+Into+Linux+Application+Servers.htm

Cisco Turns Routers Into Linux Application Servers
By Sean Michael Kerner
April 10, 2008

Networking gear and server equipment are two distinct types of hardware,
right? Not anymore. 

Networking goliath Cisco (NASDAQ: CSCO) is now opening its Integrated
Services Router (ISR) and Cisco Wide Area Application Services (WAAS)
platforms to become Linux-based application server platforms. The move could
have wide-ranging implications, as Cisco's gear has millions of deployments
that now can be leveraged to serve applications directly. 

Inbar Lasser-Raab, Cisco’s senior director of network systems, told
InternetNews.com that the company has been looking to open up the ISR to
third-party applications for a long time. 

We really think that we're changing the way business models will be built
in the branch, she said. Lasser-Raab isn't being overly dramatic, either.
Cisco to date has sold more than 4 million ISRs and as such has a large
installed base to target with the new application initiative. 

Officially called the Cisco Application eXtension Platform (AXP), the new
initiative includes both hardware and software for deploying applications on
Cisco's routers. The AXP is available as both a module that can plug into
modular Cisco ISRs as well as a daughterboard that can plug into a Cisco ISR
motherboard. 

On the software side, the core operating system of the AXP is Linux. Joel
Conover, manager of network systems at Cisco, explained that that the
version of Linux used is one that Cisco refers to it as Cisco Hardened
Linux. 

Cisco is no stranger to Linux, though the AXP does represent a shift. This
is not the first time we have had a Linux platform,  Lasser-Raab commented.
Some of the network modules with various services are also Linux-based. So
we're actually using the same Linux to deploy our own services onto modules.
Now we're just making it available to our customers and partners. 

Though the AXP is Linux-based, Conover noted that the actual development
environment for applications could be anything an ISV wants. He explained
that the SDK and APIs provide a standard set of libraries for C, Python and
Java. 

Before an application can actually be deployed onto an AXP, a certification
process must first be completed. Part of the process includes a license
agreement from Cisco as well as a support contract. The certification also
provides a mechanism to ensure that only certified applications are deployed
on the AXP. 

Lasser-Raab noted that routers are mission-critical components, and
customers likely don't want any engineer to be able to deploy whatever they
want without first ensuring it's certified. 

From a pure open source perspective, Cisco is also making sure it plays by
the rules. 

From a GPL perspective, we've taken all the things that are GPL and
reciprocated the code back to the community, Conover said. Obviously if a
developer built an application on top of a GPL platform, that doesn't imply
that they have to GPL that code.  

The GPL is a reciprocal license that requires any modification made be
contributed back to the community. 

Overall, Cisco expects the AXP to reduce the hardware footprint at branch
offices and provide deeper network integration that provides IT managers
with more control over what they can monitor. 

The ISR started as a way to integrate services, Lasser-Raab explained.
This is taking it to whole new level in terms of flexibility. 

The AXP also will take Cisco to a new level competitively, in the sense that
it is now encroaching on territory traditionally held by server vendors. 

We really view this as helping customers to simplify their branch
architectures, Lasser-Raab said. It's not looking at being a full server
replacement; it's more about efficiency and consolidation. 

 


--
Skeeve Stevens, RHCE
[EMAIL PROTECTED] / www.skeeve.org
Cell +61 (0)414 753 383 / skype://skeeve

eintellego - [EMAIL PROTECTED] - www.eintellego.net 
--
I'm a groove licked love child king of the verse 
Si vis pacem, para bellum



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] News Item: Cisco Turns Routers Into Linux Application Servers

2008-04-13 Thread Wink
http://opensourcejuicer.blogspot.com/2008/04/dumb-and-dumber.html



Skeeve Stevens wrote:
 I haven't seen anything here about this, so ..

 http://www.internetnews.com/dev-news/article.php/3740106/Cisco+Turns+Routers
 +Into+Linux+Application+Servers.htm

 Cisco Turns Routers Into Linux Application Servers
 By Sean Michael Kerner
 April 10, 2008

 Networking gear and server equipment are two distinct types of hardware,
 right? Not anymore. 

 Networking goliath Cisco (NASDAQ: CSCO) is now opening its Integrated
 Services Router (ISR) and Cisco Wide Area Application Services (WAAS)
 platforms to become Linux-based application server platforms. The move could
 have wide-ranging implications, as Cisco's gear has millions of deployments
 that now can be leveraged to serve applications directly. 

 Inbar Lasser-Raab, Cisco’s senior director of network systems, told
 InternetNews.com that the company has been looking to open up the ISR to
 third-party applications for a long time. 

 We really think that we're changing the way business models will be built
 in the branch, she said. Lasser-Raab isn't being overly dramatic, either.
 Cisco to date has sold more than 4 million ISRs and as such has a large
 installed base to target with the new application initiative. 

 Officially called the Cisco Application eXtension Platform (AXP), the new
 initiative includes both hardware and software for deploying applications on
 Cisco's routers. The AXP is available as both a module that can plug into
 modular Cisco ISRs as well as a daughterboard that can plug into a Cisco ISR
 motherboard. 

 On the software side, the core operating system of the AXP is Linux. Joel
 Conover, manager of network systems at Cisco, explained that that the
 version of Linux used is one that Cisco refers to it as Cisco Hardened
 Linux. 

 Cisco is no stranger to Linux, though the AXP does represent a shift. This
 is not the first time we have had a Linux platform,  Lasser-Raab commented.
 Some of the network modules with various services are also Linux-based. So
 we're actually using the same Linux to deploy our own services onto modules.
 Now we're just making it available to our customers and partners. 

 Though the AXP is Linux-based, Conover noted that the actual development
 environment for applications could be anything an ISV wants. He explained
 that the SDK and APIs provide a standard set of libraries for C, Python and
 Java. 

 Before an application can actually be deployed onto an AXP, a certification
 process must first be completed. Part of the process includes a license
 agreement from Cisco as well as a support contract. The certification also
 provides a mechanism to ensure that only certified applications are deployed
 on the AXP. 

 Lasser-Raab noted that routers are mission-critical components, and
 customers likely don't want any engineer to be able to deploy whatever they
 want without first ensuring it's certified. 

 From a pure open source perspective, Cisco is also making sure it plays by
 the rules. 

 From a GPL perspective, we've taken all the things that are GPL and
 reciprocated the code back to the community, Conover said. Obviously if a
 developer built an application on top of a GPL platform, that doesn't imply
 that they have to GPL that code.  

 The GPL is a reciprocal license that requires any modification made be
 contributed back to the community. 

 Overall, Cisco expects the AXP to reduce the hardware footprint at branch
 offices and provide deeper network integration that provides IT managers
 with more control over what they can monitor. 

 The ISR started as a way to integrate services, Lasser-Raab explained.
 This is taking it to whole new level in terms of flexibility. 

 The AXP also will take Cisco to a new level competitively, in the sense that
 it is now encroaching on territory traditionally held by server vendors. 

 We really view this as helping customers to simplify their branch
 architectures, Lasser-Raab said. It's not looking at being a full server
 replacement; it's more about efficiency and consolidation. 

  


 --
 Skeeve Stevens, RHCE
 [EMAIL PROTECTED] / www.skeeve.org
 Cell +61 (0)414 753 383 / skype://skeeve

 eintellego - [EMAIL PROTECTED] - www.eintellego.net 
 --
 I'm a groove licked love child king of the verse 
 Si vis pacem, para bellum



 ___
 cisco-nsp mailing list  cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] OSPFv3 down every 34 minutes

2008-04-13 Thread Brad Henshaw
Ben Steele wrote: 

 might also be worth setting up an ip sla probe

Definitely. Since it happens fairly predictably, you should also be
able to set the load-interval to 30 on the interfaces connecting to
those neighbours and check if there's a momentary increase of traffic
on those interfaces when the problem occurs.

Can you route around the problem while you troublshoot? (maybe force
a high ip ospf cost on the L3 interfaces) 

Regards,
Brad
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] OSPFv3 down every 34 minutes

2008-04-13 Thread Mike Louis
From what I recall, OSPF does a periodic sanity check every 30 minutes where 
it flushes its SPF table or something like that. Could this timing be related 
to something during that process? Wild guess, but I have seen issues with 
bouncing EIGRP adjacencies that were related to MTU sizes being set 
incorrectly on Gigabit and 10/100 interfaces facing each other. The problem 
only occurred when certain packets with DF bit were set.

Just a thought. Like I said , wild guess.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Henshaw
Sent: Sunday, April 13, 2008 7:23 PM
To: Ben Steele; Eric Van Tol
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] OSPFv3 down every 34 minutes

Ben Steele wrote:

 might also be worth setting up an ip sla probe

Definitely. Since it happens fairly predictably, you should also be
able to set the load-interval to 30 on the interfaces connecting to
those neighbours and check if there's a momentary increase of traffic
on those interfaces when the problem occurs.

Can you route around the problem while you troublshoot? (maybe force
a high ip ospf cost on the L3 interfaces)

Regards,
Brad
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Note: This message and any attachments is intended solely for the use of the 
individual or entity to which it is addressed and may contain information that 
is non-public, proprietary, legally privileged, confidential, and/or exempt 
from disclosure.  If you are not the intended recipient, you are hereby 
notified that any use, dissemination, distribution, or copying of this 
communication is strictly prohibited.  If you have received this communication 
in error, please notify the original sender immediately by telephone or return 
email and destroy or delete this message along with any attachments immediately.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] OSPFv3 down every 34 minutes

2008-04-13 Thread Mike Louis
What type of link is this running? NBMA or PTP? Are you using authentication on 
the link?


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Mike Louis [EMAIL 
PROTECTED]
Sent: Sunday, April 13, 2008 7:54 PM
To: Brad Henshaw; Ben Steele; Eric Van Tol
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] OSPFv3 down every 34 minutes

From what I recall, OSPF does a periodic sanity check every 30 minutes where 
it flushes its SPF table or something like that. Could this timing be related 
to something during that process? Wild guess, but I have seen issues with 
bouncing EIGRP adjacencies that were related to MTU sizes being set 
incorrectly on Gigabit and 10/100 interfaces facing each other. The problem 
only occurred when certain packets with DF bit were set.

Just a thought. Like I said , wild guess.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Henshaw
Sent: Sunday, April 13, 2008 7:23 PM
To: Ben Steele; Eric Van Tol
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] OSPFv3 down every 34 minutes

Ben Steele wrote:

 might also be worth setting up an ip sla probe

Definitely. Since it happens fairly predictably, you should also be
able to set the load-interval to 30 on the interfaces connecting to
those neighbours and check if there's a momentary increase of traffic
on those interfaces when the problem occurs.

Can you route around the problem while you troublshoot? (maybe force
a high ip ospf cost on the L3 interfaces)

Regards,
Brad
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Note: This message and any attachments is intended solely for the use of the 
individual or entity to which it is addressed and may contain information that 
is non-public, proprietary, legally privileged, confidential, and/or exempt 
from disclosure.  If you are not the intended recipient, you are hereby 
notified that any use, dissemination, distribution, or copying of this 
communication is strictly prohibited.  If you have received this communication 
in error, please notify the original sender immediately by telephone or return 
email and destroy or delete this message along with any attachments immediately.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Note: This message and any attachments is intended solely for the use of the 
individual or entity to which it is addressed and may contain information that 
is non-public, proprietary, legally privileged, confidential, and/or exempt 
from disclosure.  If you are not the intended recipient, you are hereby 
notified that any use, dissemination, distribution, or copying of this 
communication is strictly prohibited.  If you have received this communication 
in error, please notify the original sender immediately by telephone or return 
email and destroy or delete this message along with any attachments immediately.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/