Re: [c-nsp] BGP Hybrid CLI - NLRI format to AFI

[Asbjorn Hojmark - Lists]

On Wed, 23 Jun 2010 13:51:12 -0700 (PDT), you wrote:

> I have to convert to AFI for IPv6, will my IPv4 BGP session drop
> when I do the conversion " bgp upgrade-cli" ?

No. (Yes, I've done that many times).

-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/

[c-nsp] Looping up far end smartjack

[Richey]

I've been looking around and can't find a clear cut answer to this question.
Is it possible to loop up a far end T1 smart jack using a PA-MC-T3 in a
7206?   Often I open a ticket with the lec and they will take an hour or two
to let us know if they can loop the smart jack up or not.  In a brilliant
move the customer's primary and secondary contact numbers are numbers on the
circuit so no one can call to verify that they have power at their site. 

 

 

Richey

___
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] SNMP descrepancy

[Vincent C Jones]

> But Phil is correct about polling the wrong OID: TS is looking at
> BRIDGE-MIB::dot1dTpFdbAddress, not ipNetToMedia.
> 

In which case the explanation is simple: By default on a Cisco box, the
bridge forwarding database (sho mac addr) timeout is 5 minutes (sho mac
addr aging), while the ARP table (ipNetToMedia) hangs around for four
hours. Devices down more than 5 minutes but less than four hours will
only appear in the ARP table.
-- 
Vincent C. Jones
Networking Unlimited, Inc.
Phone: +1 201 568-7810
v.jo...@networkingunlimited.com


___
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] GigE woes

[Tim Durack]

On Wed, Jun 23, 2010 at 11:59 AM, Anton Kapela  wrote:
> (noting a fresh reply to this thread, i recalled i didn't answer this one 
> from wayback)
>
> On May 17, 2010, at 1:10 PM, Tim Durack wrote:
>
>> What is PLCP?
>
> Short for "physical layer conformance protocol" -- basically, "yet more 
> phy-specific headers" that are prepended, appended, or concatenated with 
> 'user datagrams' on various networks. Depending on how these 'framers' 
> operate on the providers $mystery_transport gear, various sorts of 'broken' 
> can emerge. For example, a badly written PLCP framer could miss-interpret 
> user datagram bits for it's own, slicing frames in half or causing all sorts 
> of funk.

Gotcha.

>
>> Having a hard time coming up with a convincing test, especially with
>> test sets targetted at linerate rather than low bitrate tests. Haven't
>> tried varying patterns yet. Maybe that will turn something over.
>
> Seems like 64 byte frames at high rate triggered/exposed the negative 
> behavior in your follow-up post; this seems like something was indeed 'frame 
> aware' -- and then when they switched to 'transparent' mode, became less so 
> (given that it now works properly).
>
> Do we know that the previous 'less-than-transparent mode' wasn't always 
> frame-aware and stat-muxed with other users' data, into some sort of VC/VT 
> over a sonet-like transport piece?

One side connects directly to an Atrica A-4100, which has 8-port GigE
and 1-port 10GigE. Not sure how this gear works in the Ethernet world,
especially the "clear-channel" part. Transport is a Nortel DWDM
system.

>
> Lastly, knowing something about the drop rate/frequency and intervals of the 
> drops (during your high-rate 64 byte frame tests) could perhaps expose a 
> drop/loss process which could indicate a FIFO somewhere in the previous 
> config.
>

In the frame-aware mode, rfc2544 tests show:

Frame Size Throughput
(Mbps)
Frames Lost Loss Rate (%)
64 1,000.000 24,321,727 27.240
64 750.000 5 0.000
64 500.000 7 0.000
64 250.000 0 0.000
64 250.000 6 0.000
64 0.010 5 0.561

Bizarre latency figures:

Frame Size Throughput
(Mbps)
Avg Delay (us)
64 1,000.000 2,755.590
64 750.000 2,755.100
64 500.000 2,756.210
64 250.000 2,762.550
64 0.010 330,667.450
1,518 1,000.000 2,801.560
1,518 750.000 2,802.500
1,518 500.000 2,810.770
1,518 250.000 2,835.310
1,518 0.010 1,233,277.830
9,000 1,000.000 3,038.600
9,000 750.000 3,060.130
9,000 500.000 3,108.430
9,000 250.000 3,252.730
9,000 0.010 7,219,502.910

Frame Size Burst Size Frames Lost
64 24 6,994
64 124 169,044
64 224 328,449
64 324 486,780
64 424 637,727
64 524 797,163
64 624 946,447
64 724 1,096,295
64 824 1,247,705
64 924 1,387,109
64 1,024 1,544,136
1,518 24 1
1,518 124 1
1,518 224 1
1,518 324 1
1,518 424 1
1,518 524 1
1,518 624 1
1,518 724 1
1,518 824 1
1,518 924 1
1,518 1,024 1
9,000 24 1
9,000 124 1
9,000 224 1
9,000 324 1
9,000 424 1
9,000 524 1
9,000 624 1
9,000 724 1
9,000 824 1
9,000 924 1
9,000 1,024 1

-- 
Tim:>

___
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] GigE woes

[Tim Durack]

On Wed, Jun 23, 2010 at 9:55 AM, Kostas Fotiadis
 wrote:
> Hi Tim,
>
> Just out of curiosity, can you provide details of provider's equipment,
> model, etc ?
>

One side lands on an Atrica A-4100, with 8-port GigE and 1-port 10GigE
cards. It supposedly rides over a Nortel DWDM system (this is all
rather vague as it is difficult to get much out of the provide.)

-- 
Tim:>
___
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] RSP720-3C-10GE with daughter card = RSP720-3CXL-10GE?

[Matt Nichols]

No that is not correct. The system, at boot time, will fall back to the lowest 
common denominator - in this case PFC3C mode. To run in PFC3CXL mode all PFCs 
on the supervisors have to be 3CXLs, and all DFCS have to be DFC3CXL.

Matt

On Jun 23, 2010, at 3:38 PM, Lobo wrote:

> We're in the process of purchasing some RSP720-3CXL-10GEs for a 7604 and one 
> vendor has told us that they have some RSP720-3C-10GE cards plus PFC3CXL 
> daughter cards which they claim that when combined equates to a regular 
> RSP720-3CXL-10GE.  Is this true?  I mean from a technical stand point it may 
> be true and maybe the only thing I won't have is the 3CXL letters on the 
> outside of the blade.
> 
> I tried using the dynamic config tool on Cisco's page to build one and I see 
> no option for adding a daughter card to the regular RSP720-3C-10GE to make it 
> the 3CXL version.  Our main concern is that we want to ensure that we can 
> hold the entire global routing table and beyond and so far only the 3CXL 
> version fits that bill.  We also want to make sure we get the default memory 
> that comes with the 3CXL version and make sure we don't get cheated on lower 
> amount of memory.
> 
> Thanks
> 
> Jose
> ___
> 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] RSP720-3C-10GE with daughter card = RSP720-3CXL-10GE?

[Lobo]

We're in the process of purchasing some RSP720-3CXL-10GEs for a 7604 and 
one vendor has told us that they have some RSP720-3C-10GE cards plus 
PFC3CXL daughter cards which they claim that when combined equates to a 
regular RSP720-3CXL-10GE.  Is this true?  I mean from a technical stand 
point it may be true and maybe the only thing I won't have is the 3CXL 
letters on the outside of the blade.


I tried using the dynamic config tool on Cisco's page to build one and I 
see no option for adding a daughter card to the regular RSP720-3C-10GE 
to make it the 3CXL version.  Our main concern is that we want to ensure 
that we can hold the entire global routing table and beyond and so far 
only the 3CXL version fits that bill.  We also want to make sure we get 
the default memory that comes with the 3CXL version and make sure we 
don't get cheated on lower amount of memory.


Thanks

Jose
___
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] BGP Hybrid CLI - NLRI format to AFI

[Bill Buhlman]

I have to convert to AFI for IPv6, will my IPv4 BGP session drop when I do the 
conversion " bgp upgrade-cli" ?
 
Bill


  
___
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] SNMP descrepancy

[Drew Weaver]

The actual machine for:

Internet  10.1.164.42146   0030.48bf.3230  ARPA   Vlan643

Was down at the time (like completely down...) and I wouldn't have expected to 
even see this in the sh ip arp vlan 643 output at all, but since it did show up 
in there I am wondering why it didn't show up in the mac-address-table and more 
importantly is there a way to query the 'arp table' for just vlan 643 via SNMP 
that anyone is aware of? I also noticed this same thing occurs sometimes when 
Windows firewall is enabled on Windows 2008 machines. I have to disable the 
firewall and ping the machine before it will show up in those SNMP 
.1.3.6.1.2.1.17.4.3.1.1 even though the host is actually up and running.

Very puzzled.

thanks,
-Drew


-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers
Sent: Wednesday, June 23, 2010 11:37 AM
To: Matlock, Kenneth L
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] SNMP descrepancy

On 23/06/10 16:31, Matlock, Kenneth L wrote:
> Actually, the 'pub...@643' community he has there gives the table for
> VLAN 643.

So it is.

Perhaps I've misunderstood the question; maybe the OP is asking why 
there's an entry in the ARP table, but no MAC/FDB entry for that MAC in 
that vlan.

In which case; good question

What does:

sh ip arp vlan 6430
sh mac-address-table dyn vl 643

...say at that time?
___
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] SNMP descrepancy

[Drew Weaver]

ipNetToMedia doesn't seem to be available on a per VLAN basis via SNMP it seems 
no matter what community string you pass it is the full table.

thanks,
-Drew



-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of 
j.vaningensche...@utwente.nl
Sent: Wednesday, June 23, 2010 11:55 AM
To: matlo...@exempla.org; p.may...@imperial.ac.uk; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] SNMP descrepancy

> Actually, the 'pub...@643' community he has there gives the table for
> VLAN 643.

True, he's using community based indexing, so it's related to VLAN 643.
But Phil is correct about polling the wrong OID: TS is looking at
BRIDGE-MIB::dot1dTpFdbAddress, not ipNetToMedia.
 
> And I've seen that sort of thing before, and it seems to be random
> (there's probably some rhyme or reason, but I've learned that if I get
> the table via SNMP multiple times, at different times of day, it
> eventually catches it all).

Please note that aging time in MAC forwarding table is often not the
same as the age timer in ARP tables. Which, by the way, can lead to nice
unicast flooding effects. But that's a different story.

IIRC, default age time for MAC forwarding table is 300 seconds (IEEE
spec?).


Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands

___
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] Disabling PVST+ in mixed vendor network

[Ross Vandegrift]

On Wed, Jun 23, 2010 at 05:46:24PM +0200, j.vaningensche...@utwente.nl wrote:
> Thanks. The first one is already in our config; we were thinking about
> configuring "no spanning-tree vlan 1-4095" in a maintenance window. I
> hope that won't break our single MST instance but does kill off all
> PVST+ stuff.

Make sure you are running SXF or newer.  Previous versions of IOS ran
a pre-standard version of MST that does all kinds of weird things.
We've been running MSTP/RSTP only networks on 6500 for years now, also
with lots of HP Procurves, and have never seen any effects of the type
you're talking about.

Any idea what the trigger is?

Ross

-- 
Ross Vandegrift
r...@kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
--Woody Guthrie


signature.asc
Description: Digital signature
___
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] GigE woes

[Anton Kapela]

(noting a fresh reply to this thread, i recalled i didn't answer this one from 
wayback)

On May 17, 2010, at 1:10 PM, Tim Durack wrote:

> What is PLCP?

Short for "physical layer conformance protocol" -- basically, "yet more 
phy-specific headers" that are prepended, appended, or concatenated with 'user 
datagrams' on various networks. Depending on how these 'framers' operate on the 
providers $mystery_transport gear, various sorts of 'broken' can emerge. For 
example, a badly written PLCP framer could miss-interpret user datagram bits 
for it's own, slicing frames in half or causing all sorts of funk.

> Having a hard time coming up with a convincing test, especially with
> test sets targetted at linerate rather than low bitrate tests. Haven't
> tried varying patterns yet. Maybe that will turn something over.

Seems like 64 byte frames at high rate triggered/exposed the negative behavior 
in your follow-up post; this seems like something was indeed 'frame aware' -- 
and then when they switched to 'transparent' mode, became less so (given that 
it now works properly). 

Do we know that the previous 'less-than-transparent mode' wasn't always 
frame-aware and stat-muxed with other users' data, into some sort of VC/VT over 
a sonet-like transport piece?

Lastly, knowing something about the drop rate/frequency and intervals of the 
drops (during your high-rate 64 byte frame tests) could perhaps expose a 
drop/loss process which could indicate a FIFO somewhere in the previous config.

-Tk
___
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] Disabling PVST+ in mixed vendor network

[drrtuy]

Hi.


Thanks for the suggestion. We already do that on all access ports on the
HP switches that support it. However, on the trunks between HP and Cisco
we have to run MST or RSTP for link redundancy. I want to keep RSTP or
MST on those links, but disable PVST+.


You can try both commands "spanning-tree mode mst" and no spanning-tree 
vlan xxx" in global config mode along with certain native 802.1q vlans 
on trunk links to complete the task.


WBR
Roman A. Nozdrin



Regards,
 
Jeroen van Ingen

ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands




From: Tony [mailto:td_mi...@yahoo.com] 
Sent: woensdag 23 juni 2010 16:20

To: cisco-nsp@puck.nether.net; Ingen Schenau, J. van (ICTS)
Subject: Re: [c-nsp] Disabling PVST+ in mixed vendor network


Hi,

Have you looked at the command "spanning-tree bpdufilter enable" ?

I use it to filter stuff inbound to some cat3550 switches. The
documentation says:

"Enabling BPDU filtering on an interface is the same as disabling
spanning tree on it"



regards,
Tony.

--- On Wed, 23/6/10, j.vaningensche...@utwente.nl
 wrote:



From: j.vaningensche...@utwente.nl

Subject: [c-nsp] Disabling PVST+ in mixed vendor network
To: cisco-nsp@puck.nether.net
Received: Wednesday, 23 June, 2010, 11:49 PM


Hi,

Maybe this issue is more of a "campus" nature than NSP
related... but I
think this list reaches more knowledgeable people :)

We're running a mixed vendor network: a couple of Cat6k switches
(Sup720-3B) at the core for L3 (internal routing, BGP) and some
L2
switching on campus-wide VLANs, and a lot (300+) of HP ProCurve
switches
for all other L2 switching needs.

We'd like to completely kill proprietary STP stuff from our
network and
only run STP, RSTP and MST. Do any of you know a way to stop the
Cat6k
from generating PVST / PVST+ and, more imoprtantly, from acting
upon
accidentally received frames of that type?

We already drop PVST+ on all ProCurve switches that support it,
but once
in a while a frame makes it through. Last time that caused a 10
GE port
to go into "PVST Inconsistent" state, dropping one of our DC's
off the
network until we manually toggled the port down/up.

Due to historical, political and budgetary reasons we have to
operate
large L2 domains. That's going quite well, but the last large
disruptions we had were all due to "PVST Inconsistent" ports
while there
was nothing wrong with the logical topology. So I hope to get
some
insight how to avoid that :)


Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The
Netherlands

___
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/



___
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] SNMP descrepancy

[j.vaningenschenau]

> Actually, the 'pub...@643' community he has there gives the table for
> VLAN 643.

True, he's using community based indexing, so it's related to VLAN 643.
But Phil is correct about polling the wrong OID: TS is looking at
BRIDGE-MIB::dot1dTpFdbAddress, not ipNetToMedia.
 
> And I've seen that sort of thing before, and it seems to be random
> (there's probably some rhyme or reason, but I've learned that if I get
> the table via SNMP multiple times, at different times of day, it
> eventually catches it all).

Please note that aging time in MAC forwarding table is often not the
same as the age timer in ARP tables. Which, by the way, can lead to nice
unicast flooding effects. But that's a different story.

IIRC, default age time for MAC forwarding table is 300 seconds (IEEE
spec?).


Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands

___
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] Disabling PVST+ in mixed vendor network

[j.vaningenschenau]

Roman,

>> Thanks for the suggestion. We already do that on all access ports on
>> the HP switches that support it. However, on the trunks between HP
>> and Cisco we have to run MST or RSTP for link redundancy. I want to
>> keep RSTP or MST on those links, but disable PVST+.
> 
> You can try both commands "spanning-tree mode mst" and no
> spanning-tree vlan xxx" in global config mode along with certain
> native 802.1q vlans on trunk links to complete the task.

Thanks. The first one is already in our config; we were thinking about
configuring "no spanning-tree vlan 1-4095" in a maintenance window. I
hope that won't break our single MST instance but does kill off all
PVST+ stuff.

Still, I wonder whether it will have the desired effect. Our intention
is completely ignoring or dropping occasional inbound PVST+ frames on
the Cat6k. They might be sourced from equipment out of our control...


Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands

___
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] MPLS best practices question

[Mark Tinka]

On Wednesday 23 June 2010 08:31:03 pm Peter Rathlev wrote:

> We generally use the highest supported MTU (often 9216
>  bytes) on all internal links, in an effort to make an
>  eventual transition easier later.

We initially considered this, but when some platforms talk 
9,216 bytes, others talk 9,198 bytes, others talk 9,000 
bytes (I think we even saw one that talked 10,000 bytes, but 
I stepped far away from that box), standardizing at 9,000 
bytes was sane for us.

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] MPLS best practices question

[Mark Tinka]

On Wednesday 23 June 2010 10:27:24 pm Oliver Boehmer 
(oboehmer) wrote:

> Hmm, IGP/LDP sync addresses a different issue than
>  GR/NSF? I would consider either "IGP/LDP sync" or "LDP
>  session protection" (either one or both) to be best
>  practices.. I personally find LDP session protection
>  more straight-forward to address the link-up blackhole
>  issue than IGP/LDP sync..

I probably should have added more meat :-):

Our point of view is in the case where there has been LDP 
failure due to IGP failure (which has resulted from one or 
more problems, e.g., link failure, node failure, software 
crash, hardware failure, e.t.c.). For us, this is a more 
common scenario than a typical case where LDP-IGP 
Synchronization would be useful, e.g.:

- Failure of LDP Hello exchanges yet the IGP is alive and
  well.

- Formation of a new IGP link that has converged re: the
  IGP, but is still building FEC's re: LDP.

After studying our network performance over a 12-month 
period across the variety of platforms we have, we concluded 
that the above 2 scenarios were sufficiently rare that 
IGP/LDP Synchronization didn't make sense for us (still 
doesn't, but we keep reviewing the network's performance).

We considered LDP Session Protection, but at the time, it 
seemed to incur quite a bit of overhead as the number of 
FEC's scaled up. However, we did see some use-cases where 
its application would be quite handy, particularly if we 
constrained the protection scheme to certain "important" 
nodes. Suffice it to say, we still haven't had a reason to 
implement it.

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] SNMP descrepancy

[Phil Mayers]

On 23/06/10 16:31, Matlock, Kenneth L wrote:

Actually, the 'pub...@643' community he has there gives the table for
VLAN 643.


So it is.

Perhaps I've misunderstood the question; maybe the OP is asking why 
there's an entry in the ARP table, but no MAC/FDB entry for that MAC in 
that vlan.


In which case; good question

What does:

sh ip arp vlan 6430
sh mac-address-table dyn vl 643

...say at that time?
___
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] SNMP descrepancy

[Matlock, Kenneth L]

Actually, the 'pub...@643' community he has there gives the table for
VLAN 643.

And I've seen that sort of thing before, and it seems to be random
(there's probably some rhyme or reason, but I've learned that if I get
the table via SNMP multiple times, at different times of day, it
eventually catches it all).

Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlo...@exempla.org


-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers
Sent: Wednesday, June 23, 2010 8:33 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] SNMP descrepancy

On 23/06/10 15:11, Drew Weaver wrote:
> router#sh ip arp vlan 643
> Protocol  Address  Age (min)  Hardware Addr   Type   Interface
> Internet  10.1.164.46  2   0080.a38c.33d4  ARPA   Vlan643
> Internet  10.1.164.41  -   000f.f8a6.6d40  ARPA   Vlan643
> Internet  10.1.164.42146   0030.48bf.3230  ARPA   Vlan643
>
> [r...@dev html]# snmpwalk -v2c -c pub...@643 192.168.0.1
.1.3.6.1.2.1.17.4.3.1.1

This is the dot1dTpFdb i.e. the "sh mac-address"; and by default, its 
just for vlan 1.

> SNMPv2-SMI::mib-2.17.4.3.1.1.0.15.248.166.109.64 = Hex-STRING: 00 0F
F8 A6 6D 40
> SNMPv2-SMI::mib-2.17.4.3.1.1.0.128.163.140.51.212 = Hex-STRING: 00 80
A3 8C 33 D4
>
> Does anyone know why I appear to get different data from SNMP than I
do from the switch?

Because you're polling the wrong oid?

ipNetToMedia is the arp table.
___
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] FlexOptic

[j.vaningenschenau]

>>> Anybody have any experience with FlexOptic? Their website seems a
>>> little crazy: http://www.flexoptix.net
>>> 
>>> But they claim to have an SFP/GBIC programmer, plus tunable optics,
>>> which is what interests me.
>> 
>> We just decided to order the starter kit. If the first tests with the
>> included 1G SX SFPs succeed, we'll probably buy some LX and BX gear
>> too; maybe 10 Gbps gear later on. We'll test against Cisco Cat6k and
>> HP Procurve; I can report our findings to the list if people are
>> interested. 
> 
> Yes, please let us know.

OK, update: we received our starter kit with 10 included 1 Gbps SX
SFP's. Using the flexBox requires a Windows machine with IE browser, but
that's something we can live with. Reprogramming a SFP is easy as pie:
plug it in, select the desired compatibillty in the (online) web
interface, press the "play" button... and after about 10 secs it's done.

Programmed transceiver works in a HP switch: it's accepted, no visible
difference between a reprogrammed one and an original. Downside: with
automated inventory, you can't tell between "original original" and
"programmed to be recognised as original". Upside: so can't the vendor,
unless they change the authenticity checking procedure.

Got a trial for the Pro version this week; with the starter license it's
only possible to reprogram transceivers sold by FlexOptix, but with the
Pro license you can also reprogram 3rd party optics. This enabled us to
"upgrade" older Procurve SFP transceivers (eg J4859A) to be recognised
as newer (J4859C) versions. Now we can re-use the transceivers in newer
switches, while they would otherwise be limited to old models. Only
difference: the complexity in "authenticity check", according to
FlexOptix.

Support from the company is OK. Tech savvy, responsive. Transceiver
prices are about 5 times lower than original vendor list price.

We haven't tested the more exciting stuff yet: singlefiber transceivers,
programming an ER SFP+ to be recognised as LR (enabling extended range
on a switch that doesn't actually support it), making twinax cables that
are "vendor A" on one end and "vendor B" on the other... we'll do that
in the next couple of weeks, first have to order the necessary gear.

We won't test stuff like DWDM or even tunable DWDM, since our campus and
remote sites have enough fiber and even MAN rings are < 20 km. For us,
the cost savings on SX, LX/LH SFP's and SR / LR SFP+ are already enough
to get the Pro license. It might be worth your while to get a quote on
such a transceiver and compare it to what you'd pay for a Cisco
original...

As someone mentioned earlier, it's trading one vendor lock-in for
another. Still, the lock-in that flexOptix presents (currently credit
structure for transceiver programming, is being altered) is less
restrictive than the lock-in by our equipment vendors. Also, there are
other companies besides FlexOptix who are also in the transceiver
programming business. One could even reverse engineer the programming
device and figure out what to write to the transceivers... but
personally, I'll leave the research on transceiver programming to this
company who is already saving us money.


Since there's some Cisco-employed folk on this list too: any comments?
I've seen some nice threads about the differences between SFP, XFP and
SFP+ form factors and transceiver interface / intelligence from a device
vendor point of view. Cisco already has a command to enable 3rd party
transceivers. Is the transceiver branding mainly based on economical
arguments or technical as well?


Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands

ps: we have no affiliation with FlexOptix, I'm just happy with with my
new toy :)

___
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] SNMP descrepancy

[Phil Mayers]

On 23/06/10 15:11, Drew Weaver wrote:

router#sh ip arp vlan 643
Protocol  Address  Age (min)  Hardware Addr   Type   Interface
Internet  10.1.164.46  2   0080.a38c.33d4  ARPA   Vlan643
Internet  10.1.164.41  -   000f.f8a6.6d40  ARPA   Vlan643
Internet  10.1.164.42146   0030.48bf.3230  ARPA   Vlan643

[r...@dev html]# snmpwalk -v2c -c pub...@643 192.168.0.1 .1.3.6.1.2.1.17.4.3.1.1


This is the dot1dTpFdb i.e. the "sh mac-address"; and by default, its 
just for vlan 1.



SNMPv2-SMI::mib-2.17.4.3.1.1.0.15.248.166.109.64 = Hex-STRING: 00 0F F8 A6 6D 40
SNMPv2-SMI::mib-2.17.4.3.1.1.0.128.163.140.51.212 = Hex-STRING: 00 80 A3 8C 33 
D4

Does anyone know why I appear to get different data from SNMP than I do from 
the switch?


Because you're polling the wrong oid?

ipNetToMedia is the arp table.
___
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] MPLS best practices question

[Oliver Boehmer (oboehmer)]

> On Tue, 2010-06-22 at 09:49 -0500, cisco...@secureobscure.com wrote:
> > 2) OSPF timers or BFD? Currently my approach has been ospf timers of
> > 1/4, its fast and seems pretty compatible with everything I have
tried
> > it on. All of my links are direct between routed ports so there are
no
> > intermediate devices that would keep a link lit after equipment
> > failure. I know BFD makes sense but some of my code is old and
> > linecards are flakey so I'm curious to know who has ditched low
timers
> > for BFD or vice versa.
> 
> We ditched BFD in favour of low (IS-IS) timers, since 6500/Sup720 SXF
> couldn't handle low BFD timers well. We're running SXI now, but
haven't
> changed back. We would actually like to, since some of our (leased)
> amplified/DWDM links are very slow to see link down.
> 
> Question: Is fast BFD timers a good idea on Sup720/SXI?

I would give it another try. SXF's BFD implementation was not really
optimized and led to false positives..

> Another question: Is adjusting IGP timers (or using BFD) enough in an
> MPLS network? How does the network invalidate allocated labels and
> choosing a new LSP, disregarding FRR? Does it make sense to adjust the
> holdtime or backoff timers in LDP for faster convergence?

LDP's liberal retention mode basically ensures that once IGP switches to
a new path, there is already a label to use. So core convergence really
only depends on IGP (and failure detection). The link-up issue (where
IGP/LDP sync or LDP session protection come into play) is really the
only thing you need to look at when it comes to LDP in an IGP-tuned
core.

oli


___
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] Disabling PVST+ in mixed vendor network

[Tony]

Hi,

Have you looked at the command "spanning-tree bpdufilter enable" ?

I use it to filter stuff inbound to some cat3550 switches. The documentation 
says:

"Enabling BPDU filtering on an interface is the same as disabling spanning tree 
on it"



regards,
Tony.

--- On Wed, 23/6/10, j.vaningensche...@utwente.nl 
 wrote:

From: j.vaningensche...@utwente.nl 
Subject: [c-nsp] Disabling PVST+ in mixed vendor network
To: cisco-nsp@puck.nether.net
Received: Wednesday, 23 June, 2010, 11:49 PM

Hi,

Maybe this issue is more of a "campus" nature than NSP related... but I
think this list reaches more knowledgeable people :)

We're running a mixed vendor network: a couple of Cat6k switches
(Sup720-3B) at the core for L3 (internal routing, BGP) and some L2
switching on campus-wide VLANs, and a lot (300+) of HP ProCurve switches
for all other L2 switching needs.

We'd like to completely kill proprietary STP stuff from our network and
only run STP, RSTP and MST. Do any of you know a way to stop the Cat6k
from generating PVST / PVST+ and, more imoprtantly, from acting upon
accidentally received frames of that type?

We already drop PVST+ on all ProCurve switches that support it, but once
in a while a frame makes it through. Last time that caused a 10 GE port
to go into "PVST Inconsistent" state, dropping one of our DC's off the
network until we manually toggled the port down/up.

Due to historical, political and budgetary reasons we have to operate
large L2 domains. That's going quite well, but the last large
disruptions we had were all due to "PVST Inconsistent" ports while there
was nothing wrong with the logical topology. So I hope to get some
insight how to avoid that :)


Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands

___
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] Disabling PVST+ in mixed vendor network

[j.vaningenschenau]

Hi Tony,
 
Thanks for the suggestion. We already do that on all access ports on the
HP switches that support it. However, on the trunks between HP and Cisco
we have to run MST or RSTP for link redundancy. I want to keep RSTP or
MST on those links, but disable PVST+.
 

Regards,
 
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands




From: Tony [mailto:td_mi...@yahoo.com] 
Sent: woensdag 23 juni 2010 16:20
To: cisco-nsp@puck.nether.net; Ingen Schenau, J. van (ICTS)
Subject: Re: [c-nsp] Disabling PVST+ in mixed vendor network


Hi,

Have you looked at the command "spanning-tree bpdufilter enable" ?

I use it to filter stuff inbound to some cat3550 switches. The
documentation says:

"Enabling BPDU filtering on an interface is the same as disabling
spanning tree on it"



regards,
Tony.

--- On Wed, 23/6/10, j.vaningensche...@utwente.nl
 wrote:



From: j.vaningensche...@utwente.nl

Subject: [c-nsp] Disabling PVST+ in mixed vendor network
To: cisco-nsp@puck.nether.net
Received: Wednesday, 23 June, 2010, 11:49 PM


Hi,

Maybe this issue is more of a "campus" nature than NSP
related... but I
think this list reaches more knowledgeable people :)

We're running a mixed vendor network: a couple of Cat6k switches
(Sup720-3B) at the core for L3 (internal routing, BGP) and some
L2
switching on campus-wide VLANs, and a lot (300+) of HP ProCurve
switches
for all other L2 switching needs.

We'd like to completely kill proprietary STP stuff from our
network and
only run STP, RSTP and MST. Do any of you know a way to stop the
Cat6k
from generating PVST / PVST+ and, more imoprtantly, from acting
upon
accidentally received frames of that type?

We already drop PVST+ on all ProCurve switches that support it,
but once
in a while a frame makes it through. Last time that caused a 10
GE port
to go into "PVST Inconsistent" state, dropping one of our DC's
off the
network until we manually toggled the port down/up.

Due to historical, political and budgetary reasons we have to
operate
large L2 domains. That's going quite well, but the last large
disruptions we had were all due to "PVST Inconsistent" ports
while there
was nothing wrong with the logical topology. So I hope to get
some
insight how to avoid that :)


Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The
Netherlands

___
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] MPLS best practices question

[Oliver Boehmer (oboehmer)]

Hey,

> > 1)   IGP LDP Sync. I am really looking for some
> >  direction as to where it makes sense or not to use. The
> >  same is also true for the IGP LDP startup delay timers.
> 
> We don't use it - we instead use IETF Graceful Restart for
> LDP and IS-IS.

Hmm, IGP/LDP sync addresses a different issue than GR/NSF? I would
consider either "IGP/LDP sync" or "LDP session protection" (either one
or both) to be best practices.. I personally find LDP session protection
more straight-forward to address the link-up blackhole issue than
IGP/LDP sync..
 
oli

___
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] SNMP descrepancy

[Drew Weaver]

router#sh ip arp vlan 643
Protocol  Address  Age (min)  Hardware Addr   Type   Interface
Internet  10.1.164.46  2   0080.a38c.33d4  ARPA   Vlan643
Internet  10.1.164.41  -   000f.f8a6.6d40  ARPA   Vlan643
Internet  10.1.164.42146   0030.48bf.3230  ARPA   Vlan643

[r...@dev html]# snmpwalk -v2c -c pub...@643 192.168.0.1 .1.3.6.1.2.1.17.4.3.1.1
SNMPv2-SMI::mib-2.17.4.3.1.1.0.15.248.166.109.64 = Hex-STRING: 00 0F F8 A6 6D 
40 
SNMPv2-SMI::mib-2.17.4.3.1.1.0.128.163.140.51.212 = Hex-STRING: 00 80 A3 8C 33 
D4

Does anyone know why I appear to get different data from SNMP than I do from 
the switch? 

I assume I am doing something moronic and I'm sure you'll prove me right =)

I'm mainly interested in why 10.1.164.42   0030.48bf.3230  is not included in 
the SNMP output.

-Drew


___
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] GigE woes

[Kostas Fotiadis]

Hi Tim,

Just out of curiosity, can you provide details of provider's equipment, 
model, etc ?


Regards,
Kostas


On 23/6/2010 3:32 πμ, Tim Durack wrote:

After a month of denial, the providerjust reconfigured the GigE
circuit to be "clear channel", and it is now behaving itself |-\

Provider says we must be doing some weird encap/encryption. Nope. Just
two 6504s, SUP720-3BXL, GigE L3 interface. We replaced SFPs, tried
different 6504s, linecards, SUP720s. Tried a pair of simple HP L2
switches. No resolution.

Finally put some Anritsu GigE testers and ran RFC2544. Fails tests
with high loss at 64B frame, high loss on burst tests, and weird
latency results.

The fact that "clear channel" fixes this makes me think there is an
OEO element with a framing problem. At this point the circuit is
working, so it is academic. Like to know more for the next time
though...

Anyone else got ideas?

Tim:>

On Fri, May 14, 2010 at 2:53 PM, Tim Durack  wrote:
   

I've got a crazy GigE circuit that's having problems:

RTR-1#ping vrf v10 10.241.1.10 repeat 1 df-bit size 9000 timeout 1

Type escape sequence to abort.
Sending 1, 9000-byte ICMP Echos to 10.241.1.10, timeout is 1 seconds:
Packet sent with the DF bit set
!!
!!
!!
!!
!!
!!
!!
!!
!!!
Success rate is 100 percent (587/587), round-trip min/avg/max = 8/18/408 ms

RTR-1#ping vrf v10 10.241.1.10 repeat 1 df-bit size 200 timeout 1

Type escape sequence to abort.
Sending 1, 200-byte ICMP Echos to 10.241.1.10, timeout is 1 seconds:
Packet sent with the DF bit set
..!..!..!.!!..!..!.!!..!...!..!..!..!..!.!!...!.!..!..!!..!..!
..!..!!..!..!..!.!.!..!!.!..!..!..!..!!..!..!..!..!.!.!..!
.!..!..!..!..!!..!..!..!..!!!..!.!..!!.!!!..!..!..!..!
!.!..
Success rate is 32 percent (72/219), round-trip min/avg/max = 4/160/1180 ms

RTR-1#ping vrf v10 10.241.1.10 repeat 1 df-bit size 9000 timeout 1

Type escape sequence to abort.
Sending 1, 9000-byte ICMP Echos to 10.241.1.10, timeout is 1 seconds:
Packet sent with the DF bit set
!!
!!
!!
!
Success rate is 100 percent (255/255), round-trip min/avg/max = 12/16/228 ms

Ping with large frame size appears to pass. Small frame size results
in packet loss and unusually high rtt.

Additionally, traffic must be present in both directions for any
traffic to cross the link. I have to start the ping on both routers
simultaneously. If the ping is stopped on one side, the ping from the
other side stops returning.

Have mostly ruled out my equipment, but the carrier doesn't believe
there is anything wrong on their side. They strap a GigE tester across
the path and of course it works just fine. But try convincing arp/ospf
to work across such a link.

The link appears to be a muxponder over the carriers DWDM network, so
it is mostly optical, possibly only two OEO points at the customer
hand off.

Anyone seen anything like this before?

--
Tim:>

 



   


___
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] MPLS best practices question

[Mounir Mohamed]

Please find my comments inline.

>
> On Tue, Jun 22, 2010 at 5:49 PM,  wrote:
>
>> Good morning everyone,
>>
>>
>>
>> If I may have a moment of your time, I'm approaching a small MPLS
>> deployment
>> (L3 VPN functionality only, no TE or L2VPN) on existing infrastructure
>> primarily 6500's & ASR1k's and would very much like the opinion of the
>> list
>> on some best practices. There are several technologies that I'm trying to
>> determine the appropriateness to activate or tune and I'm scared to
>> blindly
>> enable them without a good reason to do so as I haven't seen some of them
>> used in a production environment before.
>>
>>
>>
>> 1)   IGP LDP Sync. I am really looking for some direction as to where
>> it
>> makes sense or not to use. The same is also true for the IGP LDP startup
>> delay timers.
>>
>> A) The IGP LDP Sync feature is used to prevent blackhalling of labeled
>> traffic that you might face due to fast establishment of IS-IS adjacency in
>> contrast to LDP establishment in case of link failure, however it's not
>> widely deployed, GR and LDP Session protection is used instead.
>>
>
>
>>
>> 2)   OSPF timers or BFD? Currently my approach has been ospf timers of
>> 1/4, its fast and seems pretty compatible with everything I have tried it
>> on. All of my links are direct between routed ports so there are no
>> intermediate devices that would keep a link lit after equipment failure. I
>> know BFD makes sense but some of my code is old and linecards are flakey
>> so
>> I'm curious to know who has ditched low timers for BFD or vice versa.
>>
>
> A) BFD is used to fast up link failure detection, you may need to adjust
>> some default IGP timers to fast up the adaptation (Convergence)  as well,
>> these timers include (SPF, PRC, LSP Transmit), fortunately IOS and IOS-XE
>> (ASR1k OS) have the same default IGP timers values.
>
>
>
>> As Mark said, BFD on hardware-based platforms such as ASR working  perfectly
>> because it handles via line cards (SPAs).
>>
>>
>>
>> 3)   OSPF costing, automatic bandwidth-based or manual costing of PE-P
>> and P-P links? I have seen both used in production before, I do have 10gig
>> interfaces and 40gig port-channels so I would need to alter the ospf
>> reference bandwidth if auto-costing.
>>
>> A) TE gives you more control, but if it is not desired, adjust the
>> auto-ref bandwidth to reflect your links bandwidth.
>
>
>>
>> 4)   MTU on p2p gigabit ethernet links. Currently I have stolen
>> another
>> list members MTU settings using 1530 for global & mpls MTU, and 1524 as IP
>> MTU on all PE-P and P-P interfaces. I don't have any jumbo frame
>> requirements, but do have upstream providers that may not support jumbo so
>> I'm trying to keep the MTU fairly low.
>>
>> A)  Since L3VPN is the only running application 1530 is more than enough,
>> set the interface MTU to 1530 and let MPLS inherit it, but do not set the
>> MPLS MTU directly because some IOS codes may cause forwarding issues.
>>
>>
>> 5)   Other knobs and tweeks? I'm usually a minimalist, I go forward
>> with
>> the default settings and test, then alter as little as I need to meet any
>> special needs. With that in mind, I do expect to find things that are
>> necessary to modify but really would like to see wide adoption or clear
>> requirements in doing so.
>>
>>
>>
>> Thank you for your time, please feel free to share anything off list if
>> you
>> don't want to disclose it to the general public. I really value the
>> opinions
>> that list members have provided thus far,
>>
>>
>>
>> John
>>
>>
>>
>> ___
>> 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/
>>
>
>
>
> --
> Best Regards,
> Mounir Mohamed, CCIE No.19573 (R&S, SP)
> Senior Network Engineer, Core Team.
> NOOR Data Networks, SAE
> Mobile# +2-010-2345-956
> http://mounirmohamed.wordpress.com
> http://www.linkedin.com/in/mounirmohamed
>



-- 
Best Regards,
Mounir Mohamed, CCIE No.19573 (R&S, SP)
Senior Network Engineer, Core Team.
NOOR Data Networks, SAE
Mobile# +2-010-2345-956
http://mounirmohamed.wordpress.com
http://www.linkedin.com/in/mounirmohamed
___
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] Disabling PVST+ in mixed vendor network

[j.vaningenschenau]

Hi,

Maybe this issue is more of a "campus" nature than NSP related... but I
think this list reaches more knowledgeable people :)

We're running a mixed vendor network: a couple of Cat6k switches
(Sup720-3B) at the core for L3 (internal routing, BGP) and some L2
switching on campus-wide VLANs, and a lot (300+) of HP ProCurve switches
for all other L2 switching needs.

We'd like to completely kill proprietary STP stuff from our network and
only run STP, RSTP and MST. Do any of you know a way to stop the Cat6k
from generating PVST / PVST+ and, more imoprtantly, from acting upon
accidentally received frames of that type?

We already drop PVST+ on all ProCurve switches that support it, but once
in a while a frame makes it through. Last time that caused a 10 GE port
to go into "PVST Inconsistent" state, dropping one of our DC's off the
network until we manually toggled the port down/up.

Due to historical, political and budgetary reasons we have to operate
large L2 domains. That's going quite well, but the last large
disruptions we had were all due to "PVST Inconsistent" ports while there
was nothing wrong with the logical topology. So I hope to get some
insight how to avoid that :)


Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands

___
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] ...and further ports increasing 1...

[Martin Barry]

Hi list

We saw something in some logs which we are trying to understand a little
better. The format is:


$timestamp: %SEC-6-IPACCESSLOGP: list $acl denied udp $source_ip(64013 and 
further ports increasing 1)) ($interface $mac) ->  $destination_ip(33447)


A google search for "and further ports increasing" with the quotes returns
zero results.

Does the 1 mean the increment was 1 or that there was a single additional
port?

Anyone else seen this before or someone at Cisco care to comment?

cheers
Marty
___
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] MPLS best practices question

[Peter Rathlev]

On Tue, 2010-06-22 at 09:49 -0500, cisco...@secureobscure.com wrote:
> 2) OSPF timers or BFD? Currently my approach has been ospf timers of
> 1/4, its fast and seems pretty compatible with everything I have tried
> it on. All of my links are direct between routed ports so there are no
> intermediate devices that would keep a link lit after equipment
> failure. I know BFD makes sense but some of my code is old and
> linecards are flakey so I'm curious to know who has ditched low timers
> for BFD or vice versa. 

We ditched BFD in favour of low (IS-IS) timers, since 6500/Sup720 SXF
couldn't handle low BFD timers well. We're running SXI now, but haven't
changed back. We would actually like to, since some of our (leased)
amplified/DWDM links are very slow to see link down.

Question: Is fast BFD timers a good idea on Sup720/SXI?

Another question: Is adjusting IGP timers (or using BFD) enough in an
MPLS network? How does the network invalidate allocated labels and
choosing a new LSP, disregarding FRR? Does it make sense to adjust the
holdtime or backoff timers in LDP for faster convergence?

> 3) OSPF costing, automatic bandwidth-based or manual costing of PE-P
> and P-P links? I have seen both used in production before, I do have
> 10gig interfaces and 40gig port-channels so I would need to alter the
> ospf reference bandwidth if auto-costing.

We also use manually configured costs. Auto cost cannot account for link
latency based on e.g. path length.

> 4) MTU on p2p gigabit ethernet links. Currently I have stolen another
> list members MTU settings using 1530 for global & mpls MTU, and 1524
> as IP MTU on all PE-P and P-P interfaces. I don't have any jumbo frame
> requirements, but do have upstream providers that may not support
> jumbo so I'm trying to keep the MTU fairly low.

We generally use the highest supported MTU (often 9216 bytes) on all
internal links, in an effort to make an eventual transition easier
later. All external (customer/access) links use 1500 bytes.

-- 
Peter


___
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] Etherchannel plus OSPF in GNS3

[Mikael Abrahamsson]

On Wed, 23 Jun 2010, Ivan Šimko wrote:


Port channel is set up based on src-dst-ip - how to confirm??


I've done a CCO case regarding outgoing loadsharing on 7200 port-channel 
(which I guess is the same on your 3640) and it doesn't work well. I don't 
remember exactly what the outcome was, but I decided against it since my 
use application was few flows and few IPs, and this meant etherchannel 
didn't really work.


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
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] VPN-tunnel between two Cisco routers stuck in MM_KEY_EXCH

[Ziv Leyes]

The problem doesn't seem to be related to preshared key, but more on the 
settings, are you totally sure that the other side has identical configuration?
Could you post the relevant sections of both sides running-config?


-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Daniel Dib
Sent: Wednesday, June 23, 2010 11:43 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] VPN-tunnel between two Cisco routers stuck in MM_KEY_EXCH

Hi,

I am having some trouble setting up a VPN-tunnel between two Cisco 
routers. One end is my router and the other end is controlled by 
another company.
We seem to get stuck in the key exchange in ISAKMP phase 1. This is 
strange since tunnel has been up before but won't come up again. 
Neither of us
have changed the config.

Config on my side:

crypto isakmp policy 45
encr 3des
authentication pre-share
group 2
lifetime 14400

crypto isakmp key removed address x.x.x.x

crypto map SDM_CMAP_1 24 ipsec-isakmp set peer x.x.x.x
set transform-set ESP-3DES-SHA match address 122

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac Other side:

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
lifetime 14400

crypto isakmp key removed address y.y.y.y

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
crypto ipsec profile SDM_Profile1
set transform-set ESP-3DES-SHA

crypto map SDM_CMAP_1 3 ipsec-isakmp
set peer y.y.y.y
set transform-set ESP-3DES-SHA

sh crypto isakmp sa shows the following:

x.x.x.x  y.y.y.y  MM_KEY_EXCH6360

Seems we get stuck in key exchange although we have verified we have 
the same key.
I have ran a debug crypto isakmp, full debug is available at 
http://pastebin.com/uUhBjKK6

Here are some relevant messages from debug:

2010-06-23 08:38:31 Local7.Debug413731: *Jun 23 
07:40:57.897: ISAKMP: Created a peer struct for x.x.x.x, peer port 500
2010-06-23 08:38:31 Local7.Debug413752: *Jun 23 
07:40:57.925: ISAKMP:(0:0:N/A:0): vendor ID seems Unity/DPD but major 
157 mismatch
2010-06-23 08:38:31 Local7.Debug413775: *Jun 23 
07:40:57.925: ISAKMP:(0:0:N/A:0):atts are acceptable. Next payload is 0
2010-06-23 08:38:31 Local7.Debug413829: *Jun 23 
07:40:58.029: ISAKMP: set new node -560194497 to QM_IDLE

Looks good so far, tunnel is in QM_IDLE but after this the problem starts:

2010-06-23 08:38:31 Local7.Debug413834: 
<009>unauthenticated (missing hash payload).
2010-06-23 08:38:31 Local7.Debug413835: *Jun 23 
07:40:58.029: ISAKMP:(0:628:HW:2):Rejecting unauthenticated 
RESPONDER_LIFETIME.
2010-06-23 08:38:31 Local7.Debug413836: *Jun 23 
07:40:58.029: ISAKMP:(0:628:HW:2):deleting node -560194497 error FALSE 
reason "Informational (in) state 1"
2010-06-23 08:38:31 Local7.Debug413848: *Jun 23 
07:40:58.029: ISAKMP:(0:628:HW:2):: peer matches *none* of the profiles
2010-06-23 08:38:31 Local7.Debug413853: *Jun 23 
07:40:58.033: ISAKMP:(0:628:HW:2): unable to compute hash!
2010-06-23 08:38:31 Local7.Debug413854: *Jun 23 
07:40:58.033: ISAKMP:(0:628:HW:2): Unable to compute other party's hash!
2010-06-23 08:38:31 Local7.Debug413858: *Jun 23 
07:40:58.033: ISAKMP: reserved not zero on ID payload!
2010-06-23 08:38:31 Local7.Warning  413859: *Jun 23 
07:40:58.033: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from x.x.x.x  
failed its sanity check or is malformed
2010-06-23 08:38:32 Local7.Debug413865: *Jun 23 
07:40:59.057: ISAKMP:(0:628:HW:2): phase 1 packet is a duplicate of a 
previous packet.
2010-06-23 08:38:32 Local7.Debug413866: *Jun 23 
07:40:59.057: ISAKMP:(0:628:HW:2): retransmitting due to retransmit 
phase 1
2010-06-23 08:38:32 Local7.Debug413867: *Jun 23 
07:40:59.057: ISAKMP:(0:628:HW:2): retransmitting phase 1 MM_KEY_EXCH...
2010-06-23 08:38:32 Local7.Debug413868: *Jun 23 
07:40:59.441: ISAKMP:(0:621:HW:2):purging node 188143359
2010-06-23 08:38:32 Local7.Debug413869: *Jun 23 
07:40:59.557: ISAKMP:(0:628:HW:2): retransmitting phase 1 MM_KEY_EXCH...
2010-06-23 08:38:32 Local7.Debug413870: *Jun 23 
07:40:59.557: ISAKMP:(0:628:HW:2):incrementing error counter on sa: 
retransmit phase 1
2010-06-23 08:38:33 Local7.Debug413871: *Jun 23 
07:40:59.557: ISAKMP:(0:628:HW:2): retransmitting phase 1 MM_KEY_EXCH
2010-06-23 08:38:33 Local7.Debug413872: *Jun 23 
07:40:59.557: ISAKMP:(0:628:HW:2): sending packet to x.x.x.x my_port 
500 peer_port 500 (I) MM_KEY_EXCH
2010-06-23 08:38:33 Local7.Debug413873: *Jun 23 
07:41:00.077: ISAKMP (0:268436084): received packet from x.x.x.x dport 
500 sport 500 Global (I) MM_KEY_EXCH
2010-06-23 08:38:33 Local7.Debug413874: *Jun 23 
07:41:00.077: ISAKMP:(0:628:HW:2): phase 1 packet is a duplicat

Re: [c-nsp] VTY PROBLEM

[bha Qaqish]

Its not working
Bha

From: Aftab Siddiqui [mailto:aftab.siddi...@gmail.com]
Sent: Wednesday, June 23, 2010 12:25 PM
To: Alexandre Snarskii
Cc: bha Qaqish; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] VTY PROBLEM

Yes, it worked. No more stuck session. Thanks Alex.

Regards,

Aftab A. Siddiqui

On Wed, Jun 23, 2010 at 2:16 PM, Alexandre Snarskii 
mailto:s...@snar.spb.ru>> wrote:
On Wed, Jun 23, 2010 at 01:44:39PM +0500, Aftab Siddiqui wrote:
> same issue here,
>
> Line   User   Host(s)  Idle   Location
>  194 vty 0idle19w2d 201.240.122.39
>  195 vty 1idle17w1d 41.196.124.99
>  196 vty 2idle16w4d 94.50.81.100
>  197 vty 3idle17w0d 59.182.12.209
>  198 vty 4idle 2w5d 189.27.86.223
>  199 vty 5idle 1w0d 41.178.188.74
>
> Platform 1841
> IOS: c1841-advipservicesk9-mz.124-13b.bin
>
> clear tcp line vty 0
>
> The above command doesn't work.
You may try to 'clear tcp tcb N', as described here:

http://www.gossamer-threads.com/lists/cisco/nsp/98894

>
>
> Regards,
>
> Aftab A. Siddiqui
>
>
> On Wed, Jun 23, 2010 at 1:32 PM, bha Qaqish 
> mailto:bha.qaq...@nitc.gov.jo>> wrote:
>
> > I tried it.
> > Same thing , the session still exist
> >
> > Eng. Bha Qaqish
> >
> >
> >
> > -Original Message-
> > From: Pepa Verich 
> > [mailto:josef.ver...@cesnet.cz]
> > Sent: Wednesday, June 23, 2010 10:35 AM
> > To: bha Qaqish
> > Subject: Re: [c-nsp] VTY PROBLEM
> >
> > Did you try command  "clear TCP line vty X" ?
> >
> > Key word "TCP" is very important.
> >
> >
> >Pepa
> >
> >
> > Dne 23.6.2010 7:37, bha Qaqish napsal(a):
> >  > I did it several times but did not do anything
> > >
> > > Eng. Bha Qaqish
> > >
> > >
> > > -Original Message-
> > > From: David Prall [mailto:d...@dcptech.com]
> > > Sent: Tuesday, June 22, 2010 11:13 PM
> > > To: bha Qaqish; 'Jeff Wojciechowski'; 
> > > cisco-nsp@puck.nether.net
> > > Subject: RE: [c-nsp] VTY PROBLEM
> > >
> > > Do a "who" and see who has a hold of it. Then put an acl on the ingress
> > > interface so deny it in and out. Your exec-timeout should eventually kick
> > it
> > > off. If not, at least they won't be able to connect again. I'd also do
> > > "clear line 3" and confirm a couple of times.
> > >
> > > David
> > >
> > > --
> > > http://dcp.dcptech.com
> > >
> > >
> > >> -Original Message-
> > >> From: bha Qaqish 
> > >> [mailto:bha.qaq...@nitc.gov.jo]
> > >> Sent: Tuesday, June 22, 2010 3:17 PM
> > >> To: David Prall; 'Jeff Wojciechowski'; 
> > >> cisco-nsp@puck.nether.net
> > >> Subject: RE: [c-nsp] VTY PROBLEM
> > >>
> > >> It's the same , not cleared
> > >>
> > >> Eng. Bha Qaqish
> > >>
> > >>
> > >>
> > >>
> > >> -Original Message-
> > >> From: David Prall [mailto:d...@dcptech.com]
> > >> Sent: Tuesday, June 22, 2010 10:14 PM
> > >> To: bha Qaqish; 'Jeff Wojciechowski'; 
> > >> cisco-nsp@puck.nether.net
> > >> Subject: RE: [c-nsp] VTY PROBLEM
> > >>
> > >> Should be "clear line 3"
> > >>
> > >> David
> > >>
> > >> --
> > >> http://dcp.dcptech.com
> > >>
> > >>
> > >>> -Original Message-
> > >>> From: 
> > >>> cisco-nsp-boun...@puck.nether.net
> > >>>  [mailto:cisco-nsp-
> > >>> boun...@puck.nether.net] On Behalf Of 
> > >>> bha Qaqish
> > >>> Sent: Tuesday, June 22, 2010 2:48 PM
> > >>> To: Jeff Wojciechowski; 
> > >>> cisco-nsp@puck.nether.net
> > >>> Subject: Re: [c-nsp] VTY PROBLEM
> > >>>
> > >>> Yes
> > >>> I can see the session in this command , and when I make the clear
> > >> line
> > >>> vty 3 for example , its not cleared. It still exist in the show
> > >>> command
> > >>>
> > >>> Eng. Bha Qaqish
> > >>>
> > >>>
> > >>> -Original Message-
> > >>> From: Jeff Wojciechowski 
> > >>> [mailto:jeff.wojciechow...@midlandpaper.com]
> > >>> Sent: Tuesday, June 22, 2010 9:44 PM
> > >>> To: bha Qaqish; 
> > >>> cisco-nsp@puck.nether.net
> > >>> Subject: RE: VTY PROBLEM
> > >>>
> > >>> Can you see the session using show line and then clear line X (where
> > >> X=
> > >>> line number of stuck VTY session)?
> > >>>
> > >>> -Jeff
> > >>>
> > >>> -Original Message-
> > >>> From: 
> > >>> cisco-nsp-boun...@puck.nether.net
> > >>>  [mailto:cisco-nsp-
> > >>> boun...@puck.nether.net] On Behalf Of 
> > >>> bha Qaqish
> > >>> 

Re: [c-nsp] VTY PROBLEM

[Aftab Siddiqui]

Yes, it worked. No more stuck session. Thanks Alex.

Regards,

Aftab A. Siddiqui


On Wed, Jun 23, 2010 at 2:16 PM, Alexandre Snarskii wrote:

> On Wed, Jun 23, 2010 at 01:44:39PM +0500, Aftab Siddiqui wrote:
> > same issue here,
> >
> > Line   User   Host(s)  Idle   Location
> >  194 vty 0idle19w2d 201.240.122.39
> >  195 vty 1idle17w1d 41.196.124.99
> >  196 vty 2idle16w4d 94.50.81.100
> >  197 vty 3idle17w0d 59.182.12.209
> >  198 vty 4idle 2w5d 189.27.86.223
> >  199 vty 5idle 1w0d 41.178.188.74
> >
> > Platform 1841
> > IOS: c1841-advipservicesk9-mz.124-13b.bin
> >
> > clear tcp line vty 0
> >
> > The above command doesn't work.
>
> You may try to 'clear tcp tcb N', as described here:
>
> http://www.gossamer-threads.com/lists/cisco/nsp/98894
>
> >
> >
> > Regards,
> >
> > Aftab A. Siddiqui
> >
> >
> > On Wed, Jun 23, 2010 at 1:32 PM, bha Qaqish 
> wrote:
> >
> > > I tried it.
> > > Same thing , the session still exist
> > >
> > > Eng. Bha Qaqish
> > >
> > >
> > >
> > > -Original Message-
> > > From: Pepa Verich [mailto:josef.ver...@cesnet.cz]
> > > Sent: Wednesday, June 23, 2010 10:35 AM
> > > To: bha Qaqish
> > > Subject: Re: [c-nsp] VTY PROBLEM
> > >
> > > Did you try command  "clear TCP line vty X" ?
> > >
> > > Key word "TCP" is very important.
> > >
> > >
> > >Pepa
> > >
> > >
> > > Dne 23.6.2010 7:37, bha Qaqish napsal(a):
> > >  > I did it several times but did not do anything
> > > >
> > > > Eng. Bha Qaqish
> > > >
> > > >
> > > > -Original Message-
> > > > From: David Prall [mailto:d...@dcptech.com]
> > > > Sent: Tuesday, June 22, 2010 11:13 PM
> > > > To: bha Qaqish; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
> > > > Subject: RE: [c-nsp] VTY PROBLEM
> > > >
> > > > Do a "who" and see who has a hold of it. Then put an acl on the
> ingress
> > > > interface so deny it in and out. Your exec-timeout should eventually
> kick
> > > it
> > > > off. If not, at least they won't be able to connect again. I'd also
> do
> > > > "clear line 3" and confirm a couple of times.
> > > >
> > > > David
> > > >
> > > > --
> > > > http://dcp.dcptech.com
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: bha Qaqish [mailto:bha.qaq...@nitc.gov.jo]
> > > >> Sent: Tuesday, June 22, 2010 3:17 PM
> > > >> To: David Prall; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
> > > >> Subject: RE: [c-nsp] VTY PROBLEM
> > > >>
> > > >> It's the same , not cleared
> > > >>
> > > >> Eng. Bha Qaqish
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> -Original Message-
> > > >> From: David Prall [mailto:d...@dcptech.com]
> > > >> Sent: Tuesday, June 22, 2010 10:14 PM
> > > >> To: bha Qaqish; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
> > > >> Subject: RE: [c-nsp] VTY PROBLEM
> > > >>
> > > >> Should be "clear line 3"
> > > >>
> > > >> David
> > > >>
> > > >> --
> > > >> http://dcp.dcptech.com
> > > >>
> > > >>
> > > >>> -Original Message-
> > > >>> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> > > >>> boun...@puck.nether.net] On Behalf Of bha Qaqish
> > > >>> Sent: Tuesday, June 22, 2010 2:48 PM
> > > >>> To: Jeff Wojciechowski; cisco-nsp@puck.nether.net
> > > >>> Subject: Re: [c-nsp] VTY PROBLEM
> > > >>>
> > > >>> Yes
> > > >>> I can see the session in this command , and when I make the clear
> > > >> line
> > > >>> vty 3 for example , its not cleared. It still exist in the show
> > > >>> command
> > > >>>
> > > >>> Eng. Bha Qaqish
> > > >>>
> > > >>>
> > > >>> -Original Message-
> > > >>> From: Jeff Wojciechowski [mailto:
> jeff.wojciechow...@midlandpaper.com]
> > > >>> Sent: Tuesday, June 22, 2010 9:44 PM
> > > >>> To: bha Qaqish; cisco-nsp@puck.nether.net
> > > >>> Subject: RE: VTY PROBLEM
> > > >>>
> > > >>> Can you see the session using show line and then clear line X
> (where
> > > >> X=
> > > >>> line number of stuck VTY session)?
> > > >>>
> > > >>> -Jeff
> > > >>>
> > > >>> -Original Message-
> > > >>> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> > > >>> boun...@puck.nether.net] On Behalf Of bha Qaqish
> > > >>> Sent: Tuesday, June 22, 2010 1:27 PM
> > > >>> To: cisco-nsp@puck.nether.net
> > > >>> Subject: [c-nsp] VTY PROBLEM
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> Dear
> > > >>> I have a 7206 VXR WITH npeg2, there is a problem, there is a telnet
> > > >> vty
> > > >>> sessions that stuck , I can not clear it , its stuck for 70 weeks ,
> I
> > > >>> can not restart the router cause we are an ISP, so how could I
> clear
> > > >>> the sessions , I have a --- exec-timeout 60 0 --- on the vty.
> > > >>> Please help ASAP
> > > >>>
> > > >>>
> > > >>> BR
> > > >>>
> > > >>>
> > > >>> Eng. Bha Qaqish
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>

Re: [c-nsp] VTY PROBLEM

[Alexandre Snarskii]

On Wed, Jun 23, 2010 at 01:44:39PM +0500, Aftab Siddiqui wrote:
> same issue here,
> 
> Line   User   Host(s)  Idle   Location
>  194 vty 0idle19w2d 201.240.122.39
>  195 vty 1idle17w1d 41.196.124.99
>  196 vty 2idle16w4d 94.50.81.100
>  197 vty 3idle17w0d 59.182.12.209
>  198 vty 4idle 2w5d 189.27.86.223
>  199 vty 5idle 1w0d 41.178.188.74
> 
> Platform 1841
> IOS: c1841-advipservicesk9-mz.124-13b.bin
> 
> clear tcp line vty 0
> 
> The above command doesn't work.

You may try to 'clear tcp tcb N', as described here: 

http://www.gossamer-threads.com/lists/cisco/nsp/98894

> 
> 
> Regards,
> 
> Aftab A. Siddiqui
> 
> 
> On Wed, Jun 23, 2010 at 1:32 PM, bha Qaqish  wrote:
> 
> > I tried it.
> > Same thing , the session still exist
> >
> > Eng. Bha Qaqish
> >
> >
> >
> > -Original Message-
> > From: Pepa Verich [mailto:josef.ver...@cesnet.cz]
> > Sent: Wednesday, June 23, 2010 10:35 AM
> > To: bha Qaqish
> > Subject: Re: [c-nsp] VTY PROBLEM
> >
> > Did you try command  "clear TCP line vty X" ?
> >
> > Key word "TCP" is very important.
> >
> >
> >Pepa
> >
> >
> > Dne 23.6.2010 7:37, bha Qaqish napsal(a):
> >  > I did it several times but did not do anything
> > >
> > > Eng. Bha Qaqish
> > >
> > >
> > > -Original Message-
> > > From: David Prall [mailto:d...@dcptech.com]
> > > Sent: Tuesday, June 22, 2010 11:13 PM
> > > To: bha Qaqish; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
> > > Subject: RE: [c-nsp] VTY PROBLEM
> > >
> > > Do a "who" and see who has a hold of it. Then put an acl on the ingress
> > > interface so deny it in and out. Your exec-timeout should eventually kick
> > it
> > > off. If not, at least they won't be able to connect again. I'd also do
> > > "clear line 3" and confirm a couple of times.
> > >
> > > David
> > >
> > > --
> > > http://dcp.dcptech.com
> > >
> > >
> > >> -Original Message-
> > >> From: bha Qaqish [mailto:bha.qaq...@nitc.gov.jo]
> > >> Sent: Tuesday, June 22, 2010 3:17 PM
> > >> To: David Prall; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
> > >> Subject: RE: [c-nsp] VTY PROBLEM
> > >>
> > >> It's the same , not cleared
> > >>
> > >> Eng. Bha Qaqish
> > >>
> > >>
> > >>
> > >>
> > >> -Original Message-
> > >> From: David Prall [mailto:d...@dcptech.com]
> > >> Sent: Tuesday, June 22, 2010 10:14 PM
> > >> To: bha Qaqish; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
> > >> Subject: RE: [c-nsp] VTY PROBLEM
> > >>
> > >> Should be "clear line 3"
> > >>
> > >> David
> > >>
> > >> --
> > >> http://dcp.dcptech.com
> > >>
> > >>
> > >>> -Original Message-
> > >>> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> > >>> boun...@puck.nether.net] On Behalf Of bha Qaqish
> > >>> Sent: Tuesday, June 22, 2010 2:48 PM
> > >>> To: Jeff Wojciechowski; cisco-nsp@puck.nether.net
> > >>> Subject: Re: [c-nsp] VTY PROBLEM
> > >>>
> > >>> Yes
> > >>> I can see the session in this command , and when I make the clear
> > >> line
> > >>> vty 3 for example , its not cleared. It still exist in the show
> > >>> command
> > >>>
> > >>> Eng. Bha Qaqish
> > >>>
> > >>>
> > >>> -Original Message-
> > >>> From: Jeff Wojciechowski [mailto:jeff.wojciechow...@midlandpaper.com]
> > >>> Sent: Tuesday, June 22, 2010 9:44 PM
> > >>> To: bha Qaqish; cisco-nsp@puck.nether.net
> > >>> Subject: RE: VTY PROBLEM
> > >>>
> > >>> Can you see the session using show line and then clear line X (where
> > >> X=
> > >>> line number of stuck VTY session)?
> > >>>
> > >>> -Jeff
> > >>>
> > >>> -Original Message-
> > >>> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> > >>> boun...@puck.nether.net] On Behalf Of bha Qaqish
> > >>> Sent: Tuesday, June 22, 2010 1:27 PM
> > >>> To: cisco-nsp@puck.nether.net
> > >>> Subject: [c-nsp] VTY PROBLEM
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> Dear
> > >>> I have a 7206 VXR WITH npeg2, there is a problem, there is a telnet
> > >> vty
> > >>> sessions that stuck , I can not clear it , its stuck for 70 weeks , I
> > >>> can not restart the router cause we are an ISP, so how could I clear
> > >>> the sessions , I have a --- exec-timeout 60 0 --- on the vty.
> > >>> Please help ASAP
> > >>>
> > >>>
> > >>> BR
> > >>>
> > >>>
> > >>> Eng. Bha Qaqish
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> *
> > >>>
> > >>> ___
> > >>> 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
> > 

[c-nsp] VPN-tunnel between two Cisco routers stuck in MM_KEY_EXCH

[Daniel Dib]

Hi,

I am having some trouble setting up a VPN-tunnel between two Cisco 
routers. One end is my router and the other end is controlled by 
another company.
We seem to get stuck in the key exchange in ISAKMP phase 1. This is 
strange since tunnel has been up before but won't come up again. 
Neither of us

have changed the config.

Config on my side:

crypto isakmp policy 45
encr 3des
authentication pre-share
group 2
lifetime 14400

crypto isakmp key removed address x.x.x.x

crypto map SDM_CMAP_1 24 ipsec-isakmp set peer x.x.x.x
set transform-set ESP-3DES-SHA match address 122

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac Other side:

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
lifetime 14400

crypto isakmp key removed address y.y.y.y

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
crypto ipsec profile SDM_Profile1
set transform-set ESP-3DES-SHA

crypto map SDM_CMAP_1 3 ipsec-isakmp
set peer y.y.y.y
set transform-set ESP-3DES-SHA

sh crypto isakmp sa shows the following:

x.x.x.x  y.y.y.y  MM_KEY_EXCH6360

Seems we get stuck in key exchange although we have verified we have 
the same key.
I have ran a debug crypto isakmp, full debug is available at 
http://pastebin.com/uUhBjKK6


Here are some relevant messages from debug:

2010-06-23 08:38:31 Local7.Debug413731: *Jun 23 
07:40:57.897: ISAKMP: Created a peer struct for x.x.x.x, peer port 500
2010-06-23 08:38:31 Local7.Debug413752: *Jun 23 
07:40:57.925: ISAKMP:(0:0:N/A:0): vendor ID seems Unity/DPD but major 
157 mismatch
2010-06-23 08:38:31 Local7.Debug413775: *Jun 23 
07:40:57.925: ISAKMP:(0:0:N/A:0):atts are acceptable. Next payload is 0
2010-06-23 08:38:31 Local7.Debug413829: *Jun 23 
07:40:58.029: ISAKMP: set new node -560194497 to QM_IDLE


Looks good so far, tunnel is in QM_IDLE but after this the problem starts:

2010-06-23 08:38:31 Local7.Debug413834: 
<009>unauthenticated (missing hash payload).
2010-06-23 08:38:31 Local7.Debug413835: *Jun 23 
07:40:58.029: ISAKMP:(0:628:HW:2):Rejecting unauthenticated 
RESPONDER_LIFETIME.
2010-06-23 08:38:31 Local7.Debug413836: *Jun 23 
07:40:58.029: ISAKMP:(0:628:HW:2):deleting node -560194497 error FALSE 
reason "Informational (in) state 1"
2010-06-23 08:38:31 Local7.Debug413848: *Jun 23 
07:40:58.029: ISAKMP:(0:628:HW:2):: peer matches *none* of the profiles
2010-06-23 08:38:31 Local7.Debug413853: *Jun 23 
07:40:58.033: ISAKMP:(0:628:HW:2): unable to compute hash!
2010-06-23 08:38:31 Local7.Debug413854: *Jun 23 
07:40:58.033: ISAKMP:(0:628:HW:2): Unable to compute other party's hash!
2010-06-23 08:38:31 Local7.Debug413858: *Jun 23 
07:40:58.033: ISAKMP: reserved not zero on ID payload!
2010-06-23 08:38:31 Local7.Warning  413859: *Jun 23 
07:40:58.033: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from x.x.x.x  
failed its sanity check or is malformed
2010-06-23 08:38:32 Local7.Debug413865: *Jun 23 
07:40:59.057: ISAKMP:(0:628:HW:2): phase 1 packet is a duplicate of a 
previous packet.
2010-06-23 08:38:32 Local7.Debug413866: *Jun 23 
07:40:59.057: ISAKMP:(0:628:HW:2): retransmitting due to retransmit 
phase 1
2010-06-23 08:38:32 Local7.Debug413867: *Jun 23 
07:40:59.057: ISAKMP:(0:628:HW:2): retransmitting phase 1 MM_KEY_EXCH...
2010-06-23 08:38:32 Local7.Debug413868: *Jun 23 
07:40:59.441: ISAKMP:(0:621:HW:2):purging node 188143359
2010-06-23 08:38:32 Local7.Debug413869: *Jun 23 
07:40:59.557: ISAKMP:(0:628:HW:2): retransmitting phase 1 MM_KEY_EXCH...
2010-06-23 08:38:32 Local7.Debug413870: *Jun 23 
07:40:59.557: ISAKMP:(0:628:HW:2):incrementing error counter on sa: 
retransmit phase 1
2010-06-23 08:38:33 Local7.Debug413871: *Jun 23 
07:40:59.557: ISAKMP:(0:628:HW:2): retransmitting phase 1 MM_KEY_EXCH
2010-06-23 08:38:33 Local7.Debug413872: *Jun 23 
07:40:59.557: ISAKMP:(0:628:HW:2): sending packet to x.x.x.x my_port 
500 peer_port 500 (I) MM_KEY_EXCH
2010-06-23 08:38:33 Local7.Debug413873: *Jun 23 
07:41:00.077: ISAKMP (0:268436084): received packet from x.x.x.x dport 
500 sport 500 Global (I) MM_KEY_EXCH
2010-06-23 08:38:33 Local7.Debug413874: *Jun 23 
07:41:00.077: ISAKMP:(0:628:HW:2): phase 1 packet is a duplicate of a 
previous packet.
2010-06-23 08:38:33 Local7.Debug413875: *Jun 23 
07:41:00.077: ISAKMP:(0:628:HW:2): retransmission skipped for phase 1 
(time since last transmission 520)
2010-06-23 08:38:36 Local7.Debug413876: *Jun 23 
07:41:03.185: ISAKMP:(0:623:HW:2):purging node -764606901


What could be wrong, we have the same key, I have tried reentering key 
at my side with no difference. I am waiting for other side to do the 
same thing. What else could be wrong?

Re: [c-nsp] VTY PROBLEM

[Aftab Siddiqui]

same issue here,

Line   User   Host(s)  Idle   Location
 194 vty 0idle19w2d 201.240.122.39
 195 vty 1idle17w1d 41.196.124.99
 196 vty 2idle16w4d 94.50.81.100
 197 vty 3idle17w0d 59.182.12.209
 198 vty 4idle 2w5d 189.27.86.223
 199 vty 5idle 1w0d 41.178.188.74

Platform 1841
IOS: c1841-advipservicesk9-mz.124-13b.bin

clear tcp line vty 0

The above command doesn't work.


Regards,

Aftab A. Siddiqui


On Wed, Jun 23, 2010 at 1:32 PM, bha Qaqish  wrote:

> I tried it.
> Same thing , the session still exist
>
> Eng. Bha Qaqish
>
>
>
> -Original Message-
> From: Pepa Verich [mailto:josef.ver...@cesnet.cz]
> Sent: Wednesday, June 23, 2010 10:35 AM
> To: bha Qaqish
> Subject: Re: [c-nsp] VTY PROBLEM
>
> Did you try command  "clear TCP line vty X" ?
>
> Key word "TCP" is very important.
>
>
>Pepa
>
>
> Dne 23.6.2010 7:37, bha Qaqish napsal(a):
>  > I did it several times but did not do anything
> >
> > Eng. Bha Qaqish
> >
> >
> > -Original Message-
> > From: David Prall [mailto:d...@dcptech.com]
> > Sent: Tuesday, June 22, 2010 11:13 PM
> > To: bha Qaqish; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
> > Subject: RE: [c-nsp] VTY PROBLEM
> >
> > Do a "who" and see who has a hold of it. Then put an acl on the ingress
> > interface so deny it in and out. Your exec-timeout should eventually kick
> it
> > off. If not, at least they won't be able to connect again. I'd also do
> > "clear line 3" and confirm a couple of times.
> >
> > David
> >
> > --
> > http://dcp.dcptech.com
> >
> >
> >> -Original Message-
> >> From: bha Qaqish [mailto:bha.qaq...@nitc.gov.jo]
> >> Sent: Tuesday, June 22, 2010 3:17 PM
> >> To: David Prall; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
> >> Subject: RE: [c-nsp] VTY PROBLEM
> >>
> >> It's the same , not cleared
> >>
> >> Eng. Bha Qaqish
> >>
> >>
> >>
> >>
> >> -Original Message-
> >> From: David Prall [mailto:d...@dcptech.com]
> >> Sent: Tuesday, June 22, 2010 10:14 PM
> >> To: bha Qaqish; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
> >> Subject: RE: [c-nsp] VTY PROBLEM
> >>
> >> Should be "clear line 3"
> >>
> >> David
> >>
> >> --
> >> http://dcp.dcptech.com
> >>
> >>
> >>> -Original Message-
> >>> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> >>> boun...@puck.nether.net] On Behalf Of bha Qaqish
> >>> Sent: Tuesday, June 22, 2010 2:48 PM
> >>> To: Jeff Wojciechowski; cisco-nsp@puck.nether.net
> >>> Subject: Re: [c-nsp] VTY PROBLEM
> >>>
> >>> Yes
> >>> I can see the session in this command , and when I make the clear
> >> line
> >>> vty 3 for example , its not cleared. It still exist in the show
> >>> command
> >>>
> >>> Eng. Bha Qaqish
> >>>
> >>>
> >>> -Original Message-
> >>> From: Jeff Wojciechowski [mailto:jeff.wojciechow...@midlandpaper.com]
> >>> Sent: Tuesday, June 22, 2010 9:44 PM
> >>> To: bha Qaqish; cisco-nsp@puck.nether.net
> >>> Subject: RE: VTY PROBLEM
> >>>
> >>> Can you see the session using show line and then clear line X (where
> >> X=
> >>> line number of stuck VTY session)?
> >>>
> >>> -Jeff
> >>>
> >>> -Original Message-
> >>> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> >>> boun...@puck.nether.net] On Behalf Of bha Qaqish
> >>> Sent: Tuesday, June 22, 2010 1:27 PM
> >>> To: cisco-nsp@puck.nether.net
> >>> Subject: [c-nsp] VTY PROBLEM
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Dear
> >>> I have a 7206 VXR WITH npeg2, there is a problem, there is a telnet
> >> vty
> >>> sessions that stuck , I can not clear it , its stuck for 70 weeks , I
> >>> can not restart the router cause we are an ISP, so how could I clear
> >>> the sessions , I have a --- exec-timeout 60 0 --- on the vty.
> >>> Please help ASAP
> >>>
> >>>
> >>> BR
> >>>
> >>>
> >>> Eng. Bha Qaqish
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> *
> >>>
> >>> ___
> >>> 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/
> >
> >
> > ___
> > 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] 3750X?

[Marian Ďurkovič]

On Tue, 22 Jun 2010 18:16:15 +0300, Adrian Minta wrote
> > Please don't tell me there wasn't enough space for XFP cages, which would 
> > have
> > given us full choice between LR/ER/ZR/DWDM optics. Pushing SFP+ into this
> > market is complete ignorance of SP needs.
> >
> >
> Googling for SFP+ ZR (80Km) reveal more and more results. Perhaps some 
> of them are real, perhaps C knows something here.

See e.g.http://seclists.org/nanog/2010/May/208

Well, maybe someone starts mass-production of DWDM SFP+ two years from now. But
still, what's the point of switching service provider equipment to a form
factor, which was tagetted at ultra high-density short-reach datacenter
environments? 

We know that all SONET/SDH and DWDM gear must stay with XFP due to techical
limitations of SFP+. ZR/DWDM modules are not cheap, and it's a big difference
whether you need to keep spares just for the XFP form factor, or in the worst
case for all of XENPAK, X2, XFP and now SFP+. 

BTW, we had this discussion 3 months ago:

http://www.gossamer-threads.com/lists/cisco/nsp/127408

Bottom line: for all our purchases, SFP+ is going to be a show stopper.

   M.
___
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] VTY PROBLEM

[bha Qaqish]

I tried it. 
Same thing , the session still exist 

Eng. Bha Qaqish
 


-Original Message-
From: Pepa Verich [mailto:josef.ver...@cesnet.cz] 
Sent: Wednesday, June 23, 2010 10:35 AM
To: bha Qaqish
Subject: Re: [c-nsp] VTY PROBLEM

Did you try command  "clear TCP line vty X" ?

Key word "TCP" is very important.


Pepa


Dne 23.6.2010 7:37, bha Qaqish napsal(a):
> I did it several times but did not do anything
> 
> Eng. Bha Qaqish
>  
> 
> -Original Message-
> From: David Prall [mailto:d...@dcptech.com] 
> Sent: Tuesday, June 22, 2010 11:13 PM
> To: bha Qaqish; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] VTY PROBLEM
> 
> Do a "who" and see who has a hold of it. Then put an acl on the ingress
> interface so deny it in and out. Your exec-timeout should eventually kick it
> off. If not, at least they won't be able to connect again. I'd also do
> "clear line 3" and confirm a couple of times.
> 
> David
> 
> --
> http://dcp.dcptech.com
> 
> 
>> -Original Message-
>> From: bha Qaqish [mailto:bha.qaq...@nitc.gov.jo]
>> Sent: Tuesday, June 22, 2010 3:17 PM
>> To: David Prall; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
>> Subject: RE: [c-nsp] VTY PROBLEM
>>
>> It's the same , not cleared
>>
>> Eng. Bha Qaqish
>>
>>
>>
>>
>> -Original Message-
>> From: David Prall [mailto:d...@dcptech.com]
>> Sent: Tuesday, June 22, 2010 10:14 PM
>> To: bha Qaqish; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
>> Subject: RE: [c-nsp] VTY PROBLEM
>>
>> Should be "clear line 3"
>>
>> David
>>
>> --
>> http://dcp.dcptech.com
>>
>>
>>> -Original Message-
>>> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
>>> boun...@puck.nether.net] On Behalf Of bha Qaqish
>>> Sent: Tuesday, June 22, 2010 2:48 PM
>>> To: Jeff Wojciechowski; cisco-nsp@puck.nether.net
>>> Subject: Re: [c-nsp] VTY PROBLEM
>>>
>>> Yes
>>> I can see the session in this command , and when I make the clear
>> line
>>> vty 3 for example , its not cleared. It still exist in the show
>>> command
>>>
>>> Eng. Bha Qaqish
>>>
>>>
>>> -Original Message-
>>> From: Jeff Wojciechowski [mailto:jeff.wojciechow...@midlandpaper.com]
>>> Sent: Tuesday, June 22, 2010 9:44 PM
>>> To: bha Qaqish; cisco-nsp@puck.nether.net
>>> Subject: RE: VTY PROBLEM
>>>
>>> Can you see the session using show line and then clear line X (where
>> X=
>>> line number of stuck VTY session)?
>>>
>>> -Jeff
>>>
>>> -Original Message-
>>> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
>>> boun...@puck.nether.net] On Behalf Of bha Qaqish
>>> Sent: Tuesday, June 22, 2010 1:27 PM
>>> To: cisco-nsp@puck.nether.net
>>> Subject: [c-nsp] VTY PROBLEM
>>>
>>>
>>>
>>>
>>>
>>> Dear
>>> I have a 7206 VXR WITH npeg2, there is a problem, there is a telnet
>> vty
>>> sessions that stuck , I can not clear it , its stuck for 70 weeks , I
>>> can not restart the router cause we are an ISP, so how could I clear
>>> the sessions , I have a --- exec-timeout 60 0 --- on the vty.
>>> Please help ASAP
>>>
>>>
>>> BR
>>>
>>>
>>> Eng. Bha Qaqish
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *
>>>
>>> ___
>>> 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/
> 
> 
> ___
> 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] Etherchannel plus OSPF in GNS3

[Federico Cossu]

your topology isn't so clear ivan,
i can tell you that GNS3( or better, dynamips) does not support L3
etherchanneling.
if you want to see something on the cable wireshark (on real or
virtual devices) can definitely help you.

/BR


2010/6/23 Ivan Šimko :
> Hi all
>
> I've got question for GNS experienced guys. In my attached topology I have
> routers with etherchannel groups. Then 2 VRFs light and OSPF over SVI.
> Purpose of the network is achieve load balancing on port-channels and load
> balancing over OSPF also. Better understanding is here:
>
> Router has got 2 Etherchannel groups
> Router has got VRF with 2 VLANs
> One VLAN is memmber of etherchannel group 1
> Second VLAN memmber of group 2
> Each group consists from 2 ports - I'm using two different links for
> transmitting and want use them for higher throughput, that is the reason for
> etherchannel group
> OSPF for VRF
> Both VLANs are memmber of same VRF.
> Interconnections are VLANs /30.
>
>
> Netwrok works pretty nice but only thing what I'm missing are counters on
> physical FE ports and Port-channels what are still zero. Only ones updated
> counters are SVIs.
>
> OSPF does load balancing based on flow
> Port channel is set up based on src-dst-ip - how to confirm??
>
> I want prove that portchannel is using both ports in one direction only.
> Counters should to help me  but nothing is incremented.
>
> Used devices: 3640
>
>
> Thanks for comments
>
> Ivan
>
> ___
> cisco-nsp mailing list  cisco-...@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/