Re: [c-nsp] revert redundant sups to single sup720

[randal k]

So far, we have confirmed that there doesn't seem to be an easy-to-use CLI
way to remove redundancy. Of the (config-red)# commands, only
'linecard-group' works with a "no" prefix, all the others have no effect.
The best idea so far is to remove the redundancy part from the config or
confreg to blank and see if no mention in the configs makes it come up
redundant or not.

Any further input would be appreciated!

Randal

Anybody have any ideas on how to downgrade dual-sups to single sup?
>
>
___
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] revert redundant sups to single sup720

[Tony]

Hi Randal,

If you go into the "redundancy" configuration mode, are there any "no" options 
you can type there or what options does the "mode" command have ?

eg.

config t
(config)# redundancy
(config-red)# no ?
(config-red)# mode ?


It does specifically state in the command reference that there is NOT a "no 
redundancy" command.

Just
 guessing, I don't have a test box with redundancy configured on it to play 
with.


regards,
Tony.


 


- Original Message -
From: randal k 
To: cisco-nsp 
Cc: 
Sent: Wednesday, 21 September 2011 3:16 AM
Subject: [c-nsp] revert redundant sups to single sup720

Collective Knowledge!

I have a lab 6509 with a sup720-3bxl with a single 6148A-GE in it, running
native IOS on 12.2(18).SXF7 . Once upon a time, it had dual supervisors, but
one was stolen to make our mpls lab. It complains that it does not pass the
TestFabricSnakeForward and TestFabricSnakeBackward online diagnostics.
Research tells me that this is a fabric test, and it is failing because it
is missing the secondary sup. This 6509 does perform beautifully otherwise
and has no operating issues in the past month or so - it is also a lab
device, so it gets pretty abused.

The mpls-lab-6509 does not exhibit the behavior (it's sup was the slave).

The problem router still believes that is has dual sups:

lab02.cos01# show redundancy

                 Hardware Mode = Duplex
    Configured Redundancy Mode = sso
     Operating Redundancy Mode = sso
              Maintenance Mode = Disabled
                Communications = Down      Reason: Simplex mode

lab02.cos01# show bootvar

Standby is not up.

Our other single-sup 6509s say "Hardware Mode = Simplex" and "Standby is not
present."

So, background established, how do I convince a once-redundant supervisor
that it is now standalone? I have searched and searched and searched and I
cannot find anything that works. The only thing I haven't tried is
offline-editing the config to remove the redundancy section and loading it
in then rebooting.

Anybody have any ideas on how to downgrade dual-sups to single sup?

Thanks!
Randal
___
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 VPN with PE over GRE tunnels

[Gert Doering]

Hi,

On Tue, Sep 20, 2011 at 12:32:13PM -0400, Ross Halliday wrote:
> Thank you Gert and Cristophe, I will give that a test tonight. Does the 
> same sort of gotcha exist on the 7200 platform? 

As it doesn't have hardware forwarding to circulate packets through, no.

> I moved the interfaces over to that router, which also runs MPLS,
> and before I corrected the VPNv4 iBGP relationships the traffic
> worked fine when the 7204 sent packets out labeled for that default
> route (which caused them to be sent back via OSPF into an SVI).
> Once I fixed the BGP peering so that the 7204 learned the far VPNv4
> route properly it exhibited the same problem as the 6509. The 7204
> is a dinky ol' NPE-225 running 12.4(22)T.

In that case, it would be "something else", though I have no idea what
it could be.

> Reading that page that Cristophe linked, I'm curious why this
> isn't default behavior. Is it just some magic knob to stump people
> on a CCIE exam or is there some performance impact or other side
> effects?

recirculation reduces forwarding performance, as (some) packets are
using twice as many cycles...

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpXuX7GkoLIu.pgp
Description: PGP 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/

[c-nsp] SCE2020 or any other traffic manager

[Juan C. Crespo R.]

Hi

Right now we're considering change one IPOQUE 1100 with one Cisco 
SCE2020 and I wonder if anyone could advices us


Bandwidth: 1G
Customers: 4000
Services: Cable Modem.
Objective: limit the P2P traffic.

PD: the license are limited by Bandwidth?

Thanks


___
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 VPN with PE over GRE tunnels

[Bruce Pinsky]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ross Halliday wrote:
> It seems I made an error in the subject of my message, should read "MPLS
> VPN with CE over GRE tunnels"... Looks like a few people didn't read far
> beyond the subject line :P
> 
> Thank you Gert and Cristophe, I will give that a test tonight. Does the
> same sort of gotcha exist on the 7200 platform? I moved the interfaces
> over to that router, which also runs MPLS, and before I corrected the
> VPNv4 iBGP relationships the traffic worked fine when the 7204 sent
> packets out labeled for that default route (which caused them to be sent
> back via OSPF into an SVI). Once I fixed the BGP peering so that the
> 7204 learned the far VPNv4 route properly it exhibited the same problem
> as the 6509. The 7204 is a dinky ol' NPE-225 running 12.4(22)T.
> 
> Reading that page that Cristophe linked, I'm curious why this isn't
> default behavior. Is it just some magic knob to stump people on a CCIE
> exam or is there some performance impact or other side effects?
> 

No, the recirculation issue is only related to the 6500.  It has to do with
what operations can be performed in the hardware in a single cycle.  The
7200 is a software switching platform and would not have such a limitation.
 If you are having a problem on the 7200, there is something else going on
here.  We terminate DMVPN in VRFs for L3VPN on 7200's all the time without
issue.

Some additional troubleshooting info would be useful such as traceroutes in
both directions, ping tests from the CE site to the PE itself, etc to see
where the transit path is breaking down.  Also, complete configs would be
useful to see if anything jumps out.

- -- 
=
bep

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk54w0cACgkQE1XcgMgrtyYubQCg93E8VwIUKVuy6+CDg/5AHqxq
bY8AnAxA0DZ951Nju4LkJD78h6QxiH18
=yrvU
-END PGP 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] 6500 dbus usage

[Jon Marshall]

Tim 
 
Thanks, that makes sense now :-) 
 
Jon
 

> Date: Tue, 20 Sep 2011 08:27:12 -0700
> To: jms@hotmail.co.uk; pe...@rathlev.dk
> From: tstev...@cisco.com
> Subject: Re: [c-nsp] 6500 dbus usage
> CC: cisco-nsp@puck.nether.net
> 
> Hi Jon, please see inline below:
> 
> At 07:23 AM 9/20/2011, Jon Marshall contended:
> 
> >Thanks Peter
> >
> >If they do have dbus connectors then why are they not supported with a sup32.
> 
> 
> The connection to the dbus is a control path only on 67xx cards, 
> there is no data path there. 67xx cards always use the fabric for 
> data plane forwarding. It's just a question of whether the lookup 
> happens centrally via the dbus or locally via a DFC.
> 
> Sup32 does not have any fabric connection, so there would be no way 
> for traffic ingressing a 67xx card to reach the sup, or for sup 
> traffic to egress a 67xx front panel port.
> 
> 
> > I thought it was a physical connectivity issue but apparently not. 
> > So is it just a performance decision made by Cisco
> 
> 
> Don't worry, unlike most other things on this list seemingly, there's 
> not a conspiracy here. :P
> 
> 
> Hope that helps,
> Tim
> 
> 
> 
> >?
> >
> >Jon
> >
> >
> > > Subject: Re: [c-nsp] 6500 dbus usage
> > > From: pe...@rathlev.dk
> > > To: jms@hotmail.co.uk
> > > CC: cisco-nsp@puck.nether.net
> > > Date: Tue, 20 Sep 2011 16:15:38 +0200
> > >
> > > On Tue, 2011-09-20 at 14:12 +0100, Jon Marshall wrote:
> > > > My confusion is when i read on here that when the 67xx modules are
> > > > running in CFC mode they send a portion of the packet (depending on
> > > > compact/truncated mode) across the 32Gbps bus to the supervisor for a
> > > > forwarding decision to be made. But if they don't have connectors to
> > > > the 32Gbps bus then how do they access it ?
> > >
> > > They do have DBus connectors. Even the WS-X6708-10G-3C, even though the
> > > diagram doesn't show it.
> > >
> > > 
> > http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html#wp9000639
> > >
> > > > As a further question, assuming they do send lookups across the shared
> > > > bus then having classic linecards using the same bus could have a
> > > > direct impact on the performance of the 67xx modules ?
> > >
> > > AFAIK it will not impact the performance of traffic staying on
> > > fabric-enabled cards.
> > >
> > > (I'm not aware of any changes the Sup2T might introduce here.)
> > >
> > > --
> > > 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/
> 
> 
> 
> 
> Tim Stevenson, tstev...@cisco.com
> Routing & Switching CCIE #5561
> Distinguished Technical Marketing Engineer, Cisco Nexus 7000
> Cisco - http://www.cisco.com
> IP Phone: 408-526-6759
> 
> The contents of this message may be *Cisco Confidential*
> and are intended for the specified recipients only.
> 
> 
  
___
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] revert redundant sups to single sup720

[randal k]

Collective Knowledge!

I have a lab 6509 with a sup720-3bxl with a single 6148A-GE in it, running
native IOS on 12.2(18).SXF7 . Once upon a time, it had dual supervisors, but
one was stolen to make our mpls lab. It complains that it does not pass the
TestFabricSnakeForward and TestFabricSnakeBackward online diagnostics.
Research tells me that this is a fabric test, and it is failing because it
is missing the secondary sup. This 6509 does perform beautifully otherwise
and has no operating issues in the past month or so - it is also a lab
device, so it gets pretty abused.

The mpls-lab-6509 does not exhibit the behavior (it's sup was the slave).

The problem router still believes that is has dual sups:

lab02.cos01# show redundancy

 Hardware Mode = Duplex
Configured Redundancy Mode = sso
 Operating Redundancy Mode = sso
  Maintenance Mode = Disabled
Communications = Down  Reason: Simplex mode

lab02.cos01# show bootvar

Standby is not up.

Our other single-sup 6509s say "Hardware Mode = Simplex" and "Standby is not
present."

So, background established, how do I convince a once-redundant supervisor
that it is now standalone? I have searched and searched and searched and I
cannot find anything that works. The only thing I haven't tried is
offline-editing the config to remove the redundancy section and loading it
in then rebooting.

Anybody have any ideas on how to downgrade dual-sups to single sup?

Thanks!
Randal
___
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 VPN with PE over GRE tunnels

[Ross Halliday]

It seems I made an error in the subject of my message, should read "MPLS VPN 
with CE over GRE tunnels"... Looks like a few people didn't read far beyond the 
subject line :P

Thank you Gert and Cristophe, I will give that a test tonight. Does the same 
sort of gotcha exist on the 7200 platform? I moved the interfaces over to that 
router, which also runs MPLS, and before I corrected the VPNv4 iBGP 
relationships the traffic worked fine when the 7204 sent packets out labeled 
for that default route (which caused them to be sent back via OSPF into an 
SVI). Once I fixed the BGP peering so that the 7204 learned the far VPNv4 route 
properly it exhibited the same problem as the 6509. The 7204 is a dinky ol' 
NPE-225 running 12.4(22)T.

Reading that page that Cristophe linked, I'm curious why this isn't default 
behavior. Is it just some magic knob to stump people on a CCIE exam or is there 
some performance impact or other side effects?


Thanks
Ross Halliday



> -Original Message-
> From: Arie Vayner (avayner) [mailto:avay...@cisco.com]
> Sent: Tuesday, September 20, 2011 10:19 AM
> To: Gert Doering; Ross Halliday
> Cc: cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] MPLS VPN with PE over GRE tunnels
> 
> Sorry for double posting... This seems to be a good reference:
> http://www.cisco.com/en/US/prod/collateral/routers/ps9343/Deploying_and
> _
> Configuring_MPLS_Virtual_Private_Networks_In_IP_Tunnel_Environment.pdf
> 
> Arie
> 
> -Original Message-
> From: Arie Vayner (avayner)
> Sent: Tuesday, September 20, 2011 17:18
> To: 'Gert Doering'; Ross Halliday
> Cc: cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] MPLS VPN with PE over GRE tunnels
> 
> On 6500 if you want to use MPLS over GRE, you would need to have your
> core facing links (through which the GRE packets are sent/received) on
> a
> SIP400 card...
> 
> Alternatively, SUP2T can support this natively.
> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_
> p
> aper_c11-652042.html#wp9000959
> 
> 
> Arie
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering
> Sent: Tuesday, September 20, 2011 10:55
> To: Ross Halliday
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] MPLS VPN with PE over GRE tunnels
> 
> Hi,
> 
> On Mon, Sep 19, 2011 at 07:18:19PM -0400, Ross Halliday wrote:
> > Currently our network has one switch that is at the hub of our
> > transition to MPLS as we cut various devices over and wait for
> maintenance windows. It has:
> 
> This "switch" would be a 6500 with all these protocols being enabled,
> and the problem spot is "packet comes in MPLS-encapsulated and needs to
> leave GRE-encapsulated" (or return path)?
> 
> > Any help or suggestions would be very appreciated!
> 
> There was something about the 6500 architecture that certain
> combinations of ingress and egress need packets to go through the
> forwarding plane twice, and you need to enable "packet recirculation"
> for it to do that.
> 
> The command I could find for that is "mls mpls tunnel-recir", but you
> might want to verify with the docs whether this is what you want.
> 
> Cisco(config)#mls mpls ?
> ...
>   tunnel-recir Recirculate Tunnel packets
> 
> gert
> 
> --
> USENET is *not* the non-clickable part of WWW!
> 
> //www.muc.de/~gert/
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> fax: +49-89-35655025
> g...@net.informatik.tu-muenchen.de

___
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] Cisco Security Advisory: Cisco Identity Services Engine Database Default Credentials Vulnerability

[Cisco Systems Product Security Incident Response Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cisco Identity Services Engine Database Default Credentials
Vulnerability

Advisory ID: cisco-sa-20110920-ise

Revision 1.0

For Public Release 2011 September 20 1600 UTC (GMT)

+-

Summary
===

Cisco Identity Services Engine (ISE) contains a set of default
credentials for its underlying database. A remote attacker could use
those credentials to modify the device configuration and settings or
gain complete administrative control of the device.

Cisco will release free software updates that address this
vulnerability on September 30th, 2011. There is no workaround for
this vulnerability.

This advisory is posted at:
http://www.cisco.com/warp/public/707/cisco-sa-20110920-ise.shtml

Affected Products
=

Vulnerable Products
+--

This vulnerability affects all releases of Cisco ISE prior to release
1.0.4.MR2. This applies to both the hardware appliance and the
software-only versions of the product.

The following methods can be used to determine which Cisco ISE
release is installed:

  * From the Cisco ISE command-line interface (CLI), issue the show
application version ise command, as shown in the following
example:
   
ise-node1/admin# show application version ise

Cisco Identity Services Engine
-
Version  : 1.0.4.558
Build Date   : Thu 18 Aug 2011 04:41:15 PM EST
Install Date : Fri 16 Sep 2011 01:38:48 PM EST  


ise-node1/admin#
   
Based on the output of the show application version ise on the
previous example, the installed Cisco ISE release is 1.0.4.588.
   
  * On the main login page of the Cisco ISE web-based interface, the
version information is displayed under the "Identity Services
Engine" heading.
  * From the Cisco ISE web-based interface, log in and click on the
"Help" button located at the bottom left corner of the screen.
From the resulting menu, select "About Identity Services Engine".
Version information is displayed on the resulting window under
the "Identity Services Engine" heading.

Products Confirmed Not Vulnerable
+

No other Cisco products are currently known to be affected by this
vulnerability.

Details
===

The Cisco Identity Services Engine provides an attribute-based access
control solution that combines authentication, authorization, and
accounting (AAA); posture; profiling; and guest management services
on a single platform. Administrators can centrally create and manage
access control policies for users and endpoints in a consistent
fashion, and gain end-to-end visibility into everything that is
connected to the network.

The Cisco ISE contains a set of default credentials for its
underlying database. A remote attacker could use those credentials to
modify the device configuration and settings or gain complete
administrative control of the device.

This vulnerability is documented in Cisco bug ID CSCts59135 
and has been assigned the CVE identifier CVE-2011-3290.

Vulnerability Scoring Details
+

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss 

* Default credentials for Oracle database on ISE 

CVSS Base Score - 10
Access Vector -Network
Access Complexity -Low
Authentication -   None
Confidentiality Impact -   Complete
Integrity Impact - Complete
Availability Impact -  Complete

CVSS Temporal Score - 9.5
Exploitability -   Functional
Remediation Level -Unavailable
Report Confidence -Confirmed

Impact
==

Successful exploitation of this vulnerability may allow an attacker
to modify the device configuration and settings or gain complete
administrative control of the device.

Software Versions and Fixes
===

When considering software upgrades, also consult 
http://www.cisco.com/go/psirt and any subsequent advisories to 
determine exposure and a complete upgrade s

[c-nsp] Police anyconnect?

[Scott Voll]

Can you Police Anyconnect VPN connections on the ASA (version 8.2)?



We are having an issues where we have telecommuters watching streaming over
there RDP connection that is using all the bandwidth.  We would like to
police our telecommuters to about 512k and see if this fixes our issue.



If it’s supported, can someone please send a sample config or link.



Thanks



Scott
___
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] Cisco 7206 overloading every four hours

[Mack McBride]

The not supported message is only important if you are trying to get TAC 
support.
Otherwise that does not seem to be the issue.  The others may be on the right 
track
regarding memory.  It is possible the ARP is causing a spike in memory usage 
resulting in issues.

Mack

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of chris stand
Sent: Tuesday, September 20, 2011 4:26 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Cisco 7206 overloading every four hours

>   3. Re: Cisco 7206 overloading every four hours (Howard Leadmon)
You did see the message that the version of code you are running is
NOT supported on the hardware you have ?

> --
> This Version of Cisco IOS Software is not supported on NPE300.
> Please select a version of Cisco IOS software compatible with this processor
> from http://www.cisco.com.
> --


Do you really need a BGP feed, could you get by with a defaul advertisement ?

>
> Message: 3
> Date: Mon, 19 Sep 2011 20:44:29 -0400
> From: "Howard Leadmon" 
> To: "'Joseph Mays'" , 
> Subject: Re: [c-nsp] Cisco 7206 overloading every four hours
> Message-ID: <019101cc772e$76d0ad10$64720730$@leadmon.net>
> Content-Type: text/plain;       charset="us-ascii"
>
>  You didn't say if you were taking a full BGP feed or not, but if that 1
> feed is full, then I suspect your running out of RAM since the NPE-300 maxes
> out at 256M RAM.    If you need BGP on the cheap in that router, I would
> guess you could get an NPE-400 which will at least handle 512M RAM, and even
> today I suspect should take a full BGP feed.    Without a doubt the G1 and
> G2's are a much better solution, but also much more costly.
>
> Setup logging, or at least a buffered log, and see what shows up after the
> spike, I'd almost bet it's bitching about memory, but that would just be my
> personal guess.  I used to have a 7206/NPE-300 years ago, and before the
> routing table got this large, it worked fine..
>
>
>
> ---
> Howard Leadmon
>
>
>
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Joseph Mays
> Sent: Monday, September 19, 2011 2:58 PM
> To: Walter Keen; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Cisco 7206 overloading every four hours
>
>> What are the npe/mem specs of this box, and how many bgp peers are you
>> getting partial or full routes from?
>
> Only 1 peer for this box (at the moment). Show ver info below.
>
> core-gw1.noc>show ver
> Cisco Internetwork Operating System Software IOS (tm) 7200 Software
> (C7200-IK9SU2-M), Version 12.3(23), RELEASE SOFTWARE
> (fc5)
> Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2007
> by cisco Systems, Inc.
> Compiled Tue 24-Jul-07 21:42 by stshen
> Image text-base: 0x60008AF4, data-base: 0x61F54BE0
>
> ROM: System Bootstrap, Version 12.2(1r) [dchih 1r], RELEASE SOFTWARE (fc1)
> BOOTLDR: 7200 Software (C7200-BOOT-M), Version 12.0(24)S, EARLY DEPLOYMENT
> RELEASE SOFTWARE (fc1)
>
> core-gw1.noc uptime is 37 weeks, 1 day, 8 hours, 11 minutes System returned
> to ROM by power-on System restarted at 05:39:25 EST Sun Jan 2 2011 System
> image file is "disk0:c7200-ik9su2-mz.123-23.bin"
>
>
> This product contains cryptographic features and is subject to United States
> and local country laws governing import, export, transfer and use. Delivery
> of Cisco cryptographic products does not imply third-party authority to
> import, export, distribute or use encryption.
> Importers, exporters, distributors and users are responsible for compliance
> with U.S. and local country laws. By using this product you agree to comply
> with applicable laws and regulations. If you are unable to comply with U.S.
> and local laws, return this product immediately.
>
> A summary of U.S. laws governing Cisco cryptographic products may be found
> at:
> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>
> If you require further assistance please contact us by sending email to
> exp...@cisco.com.
>
> cisco 7206VXR (NPE300) processor (revision D) with 262144K/32768K bytes of
> memory.
> Processor board ID 20399590
> R7000 CPU at 262MHz, Implementation 39, Rev 2.1, 256KB L2 Cache
> 6 slot VXR midplane, Version 2.0
>
> Last reset from power-on
> Bridging software.
> X.25 software, Version 3.0.0.
>
> --
> This Version of Cisco IOS Software is not supported on NPE300.
> Please select a version of Cisco IOS software compatible with this processor
> from http://www.cisco.com.
> --
>
> PCI bus mb0_mb1 (Slots 0, 1, 3 and 5) has a capacity of 600 bandwidth
> points.
> Current configuration on bus mb0_mb1 has a total of 200 bandwidth points.
> This configuration is within the PCI bus capacity and is

Re: [c-nsp] 6500 dbus usage

[Tim Stevenson]

Hi Jon, please see inline below:

At 07:23 AM 9/20/2011, Jon Marshall contended:


Thanks  Peter

If they do have dbus connectors then why are they not supported with a sup32.



The connection to the dbus is a control path only on 67xx cards, 
there is no data path there. 67xx cards always use the fabric for 
data plane forwarding. It's just a question of whether the lookup 
happens centrally via the dbus or locally via a DFC.


Sup32 does not have any fabric connection, so there would be no way 
for traffic ingressing a 67xx card to reach the sup, or for sup 
traffic to egress a 67xx front panel port.



 I thought it was a physical connectivity issue but apparently not. 
So is it just a performance decision made by Cisco



Don't worry, unlike most other things on this list seemingly, there's 
not a conspiracy here. :P



Hope that helps,
Tim




?

Jon


> Subject: Re: [c-nsp] 6500 dbus usage
> From: pe...@rathlev.dk
> To: jms@hotmail.co.uk
> CC: cisco-nsp@puck.nether.net
> Date: Tue, 20 Sep 2011 16:15:38 +0200
>
> On Tue, 2011-09-20 at 14:12 +0100, Jon Marshall wrote:
> > My confusion is when i read on here that when the 67xx modules are
> > running in CFC mode they send a portion of the packet (depending on
> > compact/truncated mode) across the 32Gbps bus to the supervisor for a
> > forwarding decision to be made. But if they don't have connectors to
> > the 32Gbps bus then how do they access it ?
>
> They do have DBus connectors. Even the WS-X6708-10G-3C, even though the
> diagram doesn't show it.
>
> 
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html#wp9000639

>
> > As a further question, assuming they do send lookups across the shared
> > bus then having classic linecards using the same bus could have a
> > direct impact on the performance of the 67xx modules ?
>
> AFAIK it will not impact the performance of traffic staying on
> fabric-enabled cards.
>
> (I'm not aware of any changes the Sup2T might introduce here.)
>
> --
> 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/





Tim Stevenson, tstev...@cisco.com
Routing & Switching CCIE #5561
Distinguished Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759

The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.


___
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] 6500 dbus usage

[Peter Rathlev]

On Tue, 2011-09-20 at 15:23 +0100, Jon Marshall wrote:
> If [67xx cards] do have dbus connectors then why are they not
> supported with a sup32. I thought it was a physical connectivity issue
> but apparently not. So is it just a performance decision made by
> Cisco ?

I'd guess that implementing DBus forwarding would maybe significantly
limit and complexify the cards. Or something.

And the Sup32 must for some reason not appear attractive at all. E.g.
why can't you get an XL PFC for a Sup32? :-)

-- 
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] 6500 dbus usage

[Jon Marshall]

Thanks  Peter
 
If they do have dbus connectors then why are they not supported with a sup32. I 
thought it was a physical connectivity issue but apparently not. So is it just 
a performance decision made by Cisco ? 
 
Jon
 

> Subject: Re: [c-nsp] 6500 dbus usage
> From: pe...@rathlev.dk
> To: jms@hotmail.co.uk
> CC: cisco-nsp@puck.nether.net
> Date: Tue, 20 Sep 2011 16:15:38 +0200
> 
> On Tue, 2011-09-20 at 14:12 +0100, Jon Marshall wrote:
> > My confusion is when i read on here that when the 67xx modules are
> > running in CFC mode they send a portion of the packet (depending on
> > compact/truncated mode) across the 32Gbps bus to the supervisor for a
> > forwarding decision to be made. But if they don't have connectors to
> > the 32Gbps bus then how do they access it ? 
> 
> They do have DBus connectors. Even the WS-X6708-10G-3C, even though the
> diagram doesn't show it.
> 
> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html#wp9000639
> 
> > As a further question, assuming they do send lookups across the shared
> > bus then having classic linecards using the same bus could have a
> > direct impact on the performance of the 67xx modules ? 
> 
> AFAIK it will not impact the performance of traffic staying on
> fabric-enabled cards.
> 
> (I'm not aware of any changes the Sup2T might introduce here.)
> 
> -- 
> 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] MPLS VPN with PE over GRE tunnels

[Arie Vayner (avayner)]

Sorry for double posting... This seems to be a good reference:
http://www.cisco.com/en/US/prod/collateral/routers/ps9343/Deploying_and_
Configuring_MPLS_Virtual_Private_Networks_In_IP_Tunnel_Environment.pdf

Arie

-Original Message-
From: Arie Vayner (avayner) 
Sent: Tuesday, September 20, 2011 17:18
To: 'Gert Doering'; Ross Halliday
Cc: cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] MPLS VPN with PE over GRE tunnels

On 6500 if you want to use MPLS over GRE, you would need to have your
core facing links (through which the GRE packets are sent/received) on a
SIP400 card...

Alternatively, SUP2T can support this natively.
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_p
aper_c11-652042.html#wp9000959


Arie 

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering
Sent: Tuesday, September 20, 2011 10:55
To: Ross Halliday
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] MPLS VPN with PE over GRE tunnels

Hi,

On Mon, Sep 19, 2011 at 07:18:19PM -0400, Ross Halliday wrote:
> Currently our network has one switch that is at the hub of our 
> transition to MPLS as we cut various devices over and wait for
maintenance windows. It has:

This "switch" would be a 6500 with all these protocols being enabled,
and the problem spot is "packet comes in MPLS-encapsulated and needs to
leave GRE-encapsulated" (or return path)?

> Any help or suggestions would be very appreciated!

There was something about the 6500 architecture that certain
combinations of ingress and egress need packets to go through the
forwarding plane twice, and you need to enable "packet recirculation"
for it to do that.

The command I could find for that is "mls mpls tunnel-recir", but you
might want to verify with the docs whether this is what you want.

Cisco(config)#mls mpls ?
...
  tunnel-recir Recirculate Tunnel packets

gert

--
USENET is *not* the non-clickable part of WWW!
 
//www.muc.de/~gert/
Gert Doering - Munich, Germany
g...@greenie.muc.de
fax: +49-89-35655025
g...@net.informatik.tu-muenchen.de

___
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 VPN with PE over GRE tunnels

[Arie Vayner (avayner)]

On 6500 if you want to use MPLS over GRE, you would need to have your
core facing links (through which the GRE packets are sent/received) on a
SIP400 card...

Alternatively, SUP2T can support this natively.
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_p
aper_c11-652042.html#wp9000959


Arie 

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering
Sent: Tuesday, September 20, 2011 10:55
To: Ross Halliday
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] MPLS VPN with PE over GRE tunnels

Hi,

On Mon, Sep 19, 2011 at 07:18:19PM -0400, Ross Halliday wrote:
> Currently our network has one switch that is at the hub of our 
> transition to MPLS as we cut various devices over and wait for
maintenance windows. It has:

This "switch" would be a 6500 with all these protocols being enabled,
and the problem spot is "packet comes in MPLS-encapsulated and needs to
leave GRE-encapsulated" (or return path)?

> Any help or suggestions would be very appreciated!

There was something about the 6500 architecture that certain
combinations of ingress and egress need packets to go through the
forwarding plane twice, and you need to enable "packet recirculation"
for it to do that.

The command I could find for that is "mls mpls tunnel-recir", but you
might want to verify with the docs whether this is what you want.

Cisco(config)#mls mpls ?
...
  tunnel-recir Recirculate Tunnel packets

gert

--
USENET is *not* the non-clickable part of WWW!
 
//www.muc.de/~gert/
Gert Doering - Munich, Germany
g...@greenie.muc.de
fax: +49-89-35655025
g...@net.informatik.tu-muenchen.de

___
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] 6500 dbus usage

[Peter Rathlev]

On Tue, 2011-09-20 at 14:12 +0100, Jon Marshall wrote:
> My confusion is when i read on here that when the 67xx modules are
> running in CFC mode they send a portion of the packet (depending on
> compact/truncated mode) across the 32Gbps bus to the supervisor for a
> forwarding decision to be made. But if they don't have connectors to
> the 32Gbps bus then how do they access it ? 

They do have DBus connectors. Even the WS-X6708-10G-3C, even though the
diagram doesn't show it.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html#wp9000639
 
> As a further question, assuming they do send lookups across the shared
> bus then having classic linecards using the same bus could have a
> direct impact on the performance of the 67xx modules ? 

AFAIK it will not impact the performance of traffic staying on
fabric-enabled cards.

(I'm not aware of any changes the Sup2T might introduce here.)

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

[c-nsp] 6500 dbus usage

[Jon Marshall]

I thought i understood 6500 architecture but after reading some of the posts on 
here now am not so sure !
 
My understanding was you basically had - 
 
1) classic linecards - only connect to shared 32Gbps bus  eg. WS-X61xx/63xx
 
2) fabric enabled - connections to both shared bus and crossbar switch fabric 
eg. WS-X65xx 
 
3) fabric only - only has connections to switch fabric eg. WS-X67xx 
 
It's 3) i am confused about. The 67xx won't work with the sup32 and i always 
thought that was because these modules didn't have connectors to the shared 
32Gbps bus and the sup32 only provides a connection to the 32Gbps bus.  
 
My confusion is when i read on here that when the 67xx modules are running in 
CFC mode they send a portion of the packet (depending on compact/truncated 
mode) across the 32Gbps bus to the supervisor for a forwarding decision to be 
made. But if they don't have connectors to the 32Gbps bus then how do they 
access it ? 
 
As a further question, assuming they do send lookups across the shared bus then 
having classic linecards using the same bus could have a direct impact on the 
performance of the 67xx modules ? 
 
Could someone clarify this please
 
Jon   
___
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 VPN with PE over GRE tunnels

[Christophe Fillot]

Gert Doering wrote:

Hello,


There was something about the 6500 architecture that certain combinations
of ingress and egress need packets to go through the forwarding plane twice,
and you need to enable "packet recirculation" for it to do that.
  

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/pfc3mpls.html

Especially:

In certain cases, the PFC3BXL or PFC3B provides the capability to 
recirculate the packets. Recirculation can be used to perform additional 
lookups in the ACL or QoS TCAMs, the NetFlow table, or the FIB TCAM 
table. Recirculation is necessary in these situations:


- To push more than three labels on imposition

- To pop more than two labels on disposition

- To pop an explicit null top label

- When the VPN Routing and Forwarding (VRF) number is more than 511

- For IP ACL on the egress interface (for nonaggregate (per-prefix) 
labels only)


Packet recirculation occurs only on a particular packet flow; other 
packet flows are not affected.The rewrite of the packet occurs on the 
modules; the packets are then forwarded back to the PFC3BXL or PFC3B for 
additional processing.



___
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] P2MP MPLS TE - Update!

[Mark Tinka]

On Monday, September 19, 2011 09:51:24 PM Mark Tinka wrote:
 
> Given how important the architecture is, I expect Juniper
> to provide decent support for mLDP, and Cisco to provide
> decent support for NG-MVPN :-).

Well, here we go:

http://www.juniper.net/techpubs/en_US/junos11.2/topics/example/mcast-
mbgp-mvpn-ldp.html


Juniper now seem to have a working release of mLDP for their 
NG-MVPN implementation, in addition to their already-
existing support for RSVP-TE. Not bad!

Now just waiting for Cisco to catch up and implement NG-MVPN 
also.

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/

[c-nsp] Cisco 7206 overloading every four hours

[chris stand]

>   3. Re: Cisco 7206 overloading every four hours (Howard Leadmon)
You did see the message that the version of code you are running is
NOT supported on the hardware you have ?

> --
> This Version of Cisco IOS Software is not supported on NPE300.
> Please select a version of Cisco IOS software compatible with this processor
> from http://www.cisco.com.
> --


Do you really need a BGP feed, could you get by with a defaul advertisement ?

>
> Message: 3
> Date: Mon, 19 Sep 2011 20:44:29 -0400
> From: "Howard Leadmon" 
> To: "'Joseph Mays'" , 
> Subject: Re: [c-nsp] Cisco 7206 overloading every four hours
> Message-ID: <019101cc772e$76d0ad10$64720730$@leadmon.net>
> Content-Type: text/plain;       charset="us-ascii"
>
>  You didn't say if you were taking a full BGP feed or not, but if that 1
> feed is full, then I suspect your running out of RAM since the NPE-300 maxes
> out at 256M RAM.    If you need BGP on the cheap in that router, I would
> guess you could get an NPE-400 which will at least handle 512M RAM, and even
> today I suspect should take a full BGP feed.    Without a doubt the G1 and
> G2's are a much better solution, but also much more costly.
>
> Setup logging, or at least a buffered log, and see what shows up after the
> spike, I'd almost bet it's bitching about memory, but that would just be my
> personal guess.  I used to have a 7206/NPE-300 years ago, and before the
> routing table got this large, it worked fine..
>
>
>
> ---
> Howard Leadmon
>
>
>
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Joseph Mays
> Sent: Monday, September 19, 2011 2:58 PM
> To: Walter Keen; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Cisco 7206 overloading every four hours
>
>> What are the npe/mem specs of this box, and how many bgp peers are you
>> getting partial or full routes from?
>
> Only 1 peer for this box (at the moment). Show ver info below.
>
> core-gw1.noc>show ver
> Cisco Internetwork Operating System Software IOS (tm) 7200 Software
> (C7200-IK9SU2-M), Version 12.3(23), RELEASE SOFTWARE
> (fc5)
> Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2007
> by cisco Systems, Inc.
> Compiled Tue 24-Jul-07 21:42 by stshen
> Image text-base: 0x60008AF4, data-base: 0x61F54BE0
>
> ROM: System Bootstrap, Version 12.2(1r) [dchih 1r], RELEASE SOFTWARE (fc1)
> BOOTLDR: 7200 Software (C7200-BOOT-M), Version 12.0(24)S, EARLY DEPLOYMENT
> RELEASE SOFTWARE (fc1)
>
> core-gw1.noc uptime is 37 weeks, 1 day, 8 hours, 11 minutes System returned
> to ROM by power-on System restarted at 05:39:25 EST Sun Jan 2 2011 System
> image file is "disk0:c7200-ik9su2-mz.123-23.bin"
>
>
> This product contains cryptographic features and is subject to United States
> and local country laws governing import, export, transfer and use. Delivery
> of Cisco cryptographic products does not imply third-party authority to
> import, export, distribute or use encryption.
> Importers, exporters, distributors and users are responsible for compliance
> with U.S. and local country laws. By using this product you agree to comply
> with applicable laws and regulations. If you are unable to comply with U.S.
> and local laws, return this product immediately.
>
> A summary of U.S. laws governing Cisco cryptographic products may be found
> at:
> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>
> If you require further assistance please contact us by sending email to
> exp...@cisco.com.
>
> cisco 7206VXR (NPE300) processor (revision D) with 262144K/32768K bytes of
> memory.
> Processor board ID 20399590
> R7000 CPU at 262MHz, Implementation 39, Rev 2.1, 256KB L2 Cache
> 6 slot VXR midplane, Version 2.0
>
> Last reset from power-on
> Bridging software.
> X.25 software, Version 3.0.0.
>
> --
> This Version of Cisco IOS Software is not supported on NPE300.
> Please select a version of Cisco IOS software compatible with this processor
> from http://www.cisco.com.
> --
>
> PCI bus mb0_mb1 (Slots 0, 1, 3 and 5) has a capacity of 600 bandwidth
> points.
> Current configuration on bus mb0_mb1 has a total of 200 bandwidth points.
> This configuration is within the PCI bus capacity and is supported.
>
> PCI bus mb2 (Slots 2, 4, 6) has a capacity of 600 bandwidth points.
> Current configuration on bus mb2 has a total of 380 bandwidth points This
> configuration is within the PCI bus capacity and is supported.
>
> Please refer to the following document "Cisco 7200 Series Port Adaptor
> Hardware Configuration Guidelines" on Cisco.com  for
> c7200 bandwidth points oversubscription and usage guidelines.
>
>
> 2 FastEthernet/IEEE 802.3 interface(s)
> 2 Serial network interface(s)
> 125K bytes of non-vo

Re: [c-nsp] 7200 DSCP-to-EXP Mapping

[ar]

Thanks for this info.

Though I thought during the POP hop, top label will be copied to the bottom 
label for Uniform,short pipe mode? is this right?

--- On Mon, 9/19/11, Vitkovsky, Adam  wrote:

From: Vitkovsky, Adam 
Subject: RE: [c-nsp] 7200 DSCP-to-EXP Mapping
To: "ar" 
Cc: "cisco-nsp@puck.nether.net" 
Date: Monday, September 19, 2011, 9:11 PM




 
 

 







 



Yes please during the swap operation the
exp value of the incoming label is automatically used with the outgoing label 

However during the pop operation the incoming
label and it’s exp value is lost and packet is dispatched with whatever
remaining labels in the stack 

   

So either you make sure that at the ingress
PE -during the label imposition the exp value has been set accordingly on all 
the
labels in the stack (usually NH-label and VPN-label) 

-this way even though the topmost label
and it’s exp marking is lost during the POP operation 

 the remaining label carries the same
exp value as the top most one  –so you can use it to schedule the
packet accordingly 

   

Or on each penultimate hop node you
manually copy the exp value of the top-most label that is going to be discarded
during the POP operation and use it to set the newly exposed label’s exp
value  

  

   



adam 



   









From: ar
[mailto:ar_...@yahoo.com] 

Sent: Monday, September 19, 2011
2:40 PM

To: Vitkovsky, Adam

Cc: cisco-nsp@puck.nether.net

Subject: Re: [c-nsp] 7200
DSCP-to-EXP Mapping 



   


 
  
  I believe as the packet travels the MPLS domain,
  same EXP bits are applied as they swap top labels..this means I can always
  match on the same exp bit as it was mapped at the ingress PE. Do I still need
  the qos-groups in this case?

  

  

  

  --- On Mon, 9/19/11, Vitkovsky, Adam 
  wrote: 
  

  From: Vitkovsky, Adam 

  Subject: Re: [c-nsp] 7200 DSCP-to-EXP Mapping

  To: "Oliver Boehmer (oboehmer)" , "
 cisco-nsp@puck.nether.net " <
 cisco-nsp@puck.nether.net >

  Date: Monday, September 19, 2011, 8:13 PM 
  
  Speaking of pipe modes :)

  

  I also failed to use the pipe mode with 12.2.33 SR codes

  As I was not able to use the qos-groups to keep track of the EXP value on the
  egress PE

  So on 7200s I pretty much got stuck with a short pipe mode and "set
  mpls-exp imposition" at the ingress PE 

  

  adam

  -Original Message-

  From: cisco-nsp-boun...@puck.nether.net
  [mailto:cisco-nsp-boun...@puck.nether.net]
  On Behalf Of Oliver Boehmer (oboehmer)

  Sent: Monday, September 19, 2011 1:43 PM

  To: cisco-nsp@puck.nether.net

  Subject: Re: [c-nsp] 7200 DSCP-to-EXP Mapping

  

  

  > >

  > > > I don't think there is in alternative to "set dscp

  > > > default" on ingress policy-maps to effectively remark

  > > > ingress traffic on an edge-LSR device.

  > >

  > > Not sure what you mean - as in you don't think we can mark

  > > anything other than 'default' on ingress?

  > 

  > 'course not, sorry.. I meant to replace "default" by
  "" before

  > sending, but forgot :-|

  

  and before someone argues: the above is obviously not relevant when

  using pipe/short-pipe mode, then you do NOT want to touch the ingress

  DSCP at all...

  

      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/

  

  ___

  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 VPN with PE over GRE tunnels

[Gert Doering]

Hi,

On Mon, Sep 19, 2011 at 07:18:19PM -0400, Ross Halliday wrote:
> Currently our network has one switch that is at the hub of our transition to 
> MPLS as we cut various devices over and wait for maintenance windows. It has:

This "switch" would be a 6500 with all these protocols being enabled, and
the problem spot is "packet comes in MPLS-encapsulated and needs to leave
GRE-encapsulated" (or return path)?

> Any help or suggestions would be very appreciated!

There was something about the 6500 architecture that certain combinations
of ingress and egress need packets to go through the forwarding plane twice,
and you need to enable "packet recirculation" for it to do that.

The command I could find for that is "mls mpls tunnel-recir", but you
might want to verify with the docs whether this is what you want.

Cisco(config)#mls mpls ?
...
  tunnel-recir Recirculate Tunnel packets

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgp4mEH9krO4T.pgp
Description: PGP 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] P2MP MPLS TE

[Phil Mayers]

On 09/19/2011 10:34 PM, Pavel Lunin wrote:

   1. Where you used PIM for the control plane, you now
  use BGP.


What's wrong with PIM?



http://books.google.com/books?id=2lxbaQ-VN8sC&lpg=PP1&hl=ru&pg=PA307#v=onepage&q&f=false:)

Let me guys ask a reverse question. Is anyone here using draft-rosen in
production? Would appreciate you feedback. Is it as dreadful as it's
sometimes said? :) Mark?


We use draft-rosen. It's not so terrible.
___
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/