Re: [c-nsp] 1000BASE-ZX/LH multi-manufacturer interconnection

[Livio Zanol Puppim]

Michele,

Thanks for your reply!

From which manufacturers do you interconnect equipments with EX/ZX (or
ER/ZR)?

I'm worried because of the different Wavelenght Range of the transceivers...


2016-01-18 7:23 GMT-02:00 Michele Bergonzoni :

> > equipments of different vendors using 1000BASE-ZX/LH. Since 1000BASE-ZX
> > isn`t standardized by IEEE, ... Can I connect 2 equipments of different
> manufactures
> > using their own manufactured transceiver?
>
> We do it all the time and never had any problem. Of course you have to
> comply with minumum attenuation requirements (don't test them with a short
> patch, you could damage your receivers).
>
> I too am curious to hear about stories of such incompatibilities, if any.
>
> The lack of a standard means that if it actually doesn't work, you will
> have a hard time to blame it on vendors. I'm afraid you have to accept this
> risk.
>
> Regards,
>Bergonz
>
> --
> Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a.
> Phone:+39-051-6781926 e-mail: berg...@labs.it
> alt.advanced.networks.design.configure.operate
> ___
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] 1000BASE-ZX/LH multi-manufacturer interconnection

[Livio Zanol Puppim]

Well, I need manufacturers warranty for every piece of the equipment,
including the optical transceiver... That's the reason. Also, I don't know
what manufacturer will win the RFP/buying processes for each equipment

Thanks for your reply!

2016-01-16 9:34 GMT-02:00 Nick Hilliard :

> Livio Zanol Puppim wrote:
> > *So my question is: Can I connect 2 equipments of different manufactures
> > using their own manufactured transceiver? Will there be a problem in this
> > connection?*
>
> it's nearly certain to work fine - almost all transceivers use wide-band
> receivers.
>
> But why on earth are you buying vendor transceivers?  Reputable third
> party transceivers work just as well and there are several vendors with
> transceiver programmers.  Vendor transceivers are mostly a waste of money.
>
> Nick
>
>


-- 
[]'s

Lívio Zanol Puppim
___
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] 1000BASE-ZX/LH multi-manufacturer interconnection

[Livio Zanol Puppim]

Hello everybody! I have a question regarding the interconnection of
equipments of different vendors using 1000BASE-ZX/LH. Since 1000BASE-ZX
isn`t standardized by IEEE, every manufacturer produces it`s own
transceiver with different characteristics.

*So my question is: Can I connect 2 equipments of different manufactures
using their own manufactured transceiver? Will there be a problem in this
connection?*

Imagine connecting a Cisco equipment to a Juniper equipment. The optical
specifications of theirs transceiver are too different:

Cisco 1000BASE-ZX:
Wavelenght Range: 1500 to 1580
Transmit power: +5 to 0
Receive power: -3 to -23


Juniper 1000BASE-LH:
Wavelenght Range: 1460 to 1580
Transmit power: +3 to -3
Receive power: -3 to -20

References:

http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/gigabit-ethernet-gbic-sfp-modules/product_data_sheet0900aecd8033f885.html

http://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/transceiver-m-mx-t-series-1000base-optical-specifications.html#jd0e383

Thanks in advance!

--
[]'s

Lívio Zanol Puppim
___
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] Update on ME3600X, ME3600X, ME3600X-24CX & ASR903 - March 2014

[Livio Zanol Puppim]

Excelent e-mail with a lot of good information. Thank you very much!


2014-03-18 5:44 GMT-03:00 Waris Sagheer (waris) :

> Hi Team,
>
> Quick Update on ME3800X, ME3600X, ME3600X-24CX & ASR903.
>
>
> New Documents Posted on CCO:
>
> Best Practices Document
>
>
> http://www.cisco.com/c/dam/en/us/td/docs/switches/metro/me3600x_3800x/software/design/guide/Cisco_Service_Provider_Access_Products_Deployment_Best_Practices_v1.pdf
>
>
> CE2.0 Document
>
>
> http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/design/guide/CE2.0_certification_v1.pdf
>
>
> Evolved Programmable Network:
>
> ME3800X, ME3600X, ME3600X-24CX and ASR903 are part of Cisco EPN
> Infrastructure Network.
>
>
> http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-xr-software/Whitepaper_C11-730477.html
>
>
> Operational Simplicity:
>
> There is a lot effort under way to simplify Access deployments.
>
>
> Autonomic Networking
>
> Autonomic Network will allow secure touch zero touch provisioning on
> ME3800X, ME3600X, ME3600X-24CX & ASR903. Deployable solution should be
> available in the release of July 2014.
>
> It would be a good time to learn about the technology. There is a good
> session in Cisco Live 2014 on this topic. Let me know if you need more
> details as well as demo.
>
>
> http://datatracker.ietf.org/doc/draft-behringer-autonomic-network-framework/
>
>
> http://tools.ietf.org/html/draft-pritikin-bootstrapping-keyinfrastructures-00
>
>  http://tools.ietf.org/html/draft-behringer-homenet-trust-bootstrap-01).
>
>  http://www.ietf.org/id/draft-behringer-default-secure-00.txt
>
>
> Service Activation support on ME3600X-24CX & Ethernet Loopback support on
> ME3800X/ME3600X/ASR903/ME3400/ASR9K
>
> ME3600X-24CX can support traffic generation for up to 1 Gig and can
> generate L2 as well as L3 traffic. Release 3.10, July 2013 & 3.11, Nov 2013
> support this feature. It currently supports Jumbo frame and can generate up
> to 12 streams which allow the user to test all the QOS configuration in the
> data path.
>
> Let me know if you need more information on this topic as well as demo.
>
>
> http://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-4_1_S/chassis/configuration/guide/3600x_24cxscg/swy1564.html
>
>
> Auto IP
>
> Allows a Layer 3 device to be inserted in Layer 3 rings without changing
> the adjacent node IP addresses. The devices automatically change their IP
> addresses. Routed port is supported in Release 3.10, July 2013 & 3.11, Nov
> 2013.
>
> Auto-IP with Port Channel/SVI/VRF will be supported in Release 15.4(2)S
> March 2014.
>
> Let me know if you need more details as well as demo.
>
>
> Programmability Support:
>
> Cisco onePK baseline is now supported on ME and ASR903 starting Release
> 3.12, March 2014. It allows basic service set today which can be used to
> build network applications.  If you have interesting use cases, please
> reach out to me if you need any support.
>
> Below is an example of an application to enable path optimization through
> Y1731PM SLA monitoring.
>
>
> https://drive.google.com/file/d/0B5Q6qCRMe89_SGMyamMyTUZ3VUU/edit?usp=sharing
>
>
> Roadmap Update:
>
> Remote LFA: MPLS Fast Convergence in ring supported since release
> 15.3(3)S, July 2013.
>
> BGP PIC Edge & Core: BGP Fast Reroute, ME support is coming in Release
> 15.4(2)S, March 2014. ASR903 already support this functionality.
>
> 802.1ad: ME will be supporting it on bridge-domain in Release 15.4(2)S
> March 2014, Xconnect in 15.4(3)S July 2014 & ASR903 in Release 3.13, July
> 2014.
>
> BFD hardware offload: ME3600X-24CX will be supporting echo mode offload
> with timers of 3.3 msec in 15.4(2)S, March 2014. ASR903 already supports
> this functionality.
>
>
> http://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-4_1_S/chassis/configuration/guide/3600x_24cxscg/swbfd.html
>
> G8032: ME3600X-24CX will get 3.3 msec CFM hardware offload in Release
> 15.4(3)S, July 2014. ASR903 already supports this functionality.
>
>
> Sandbox Update:
>
> Sandbox has been upgraded to contain ASR903, ME3600X, ME3800X,
> ME3600X-24CX, ASR901 & ME3400E.
>
> Topology:
>
>
> https://drive.google.com/file/d/0B5Q6qCRMe89_MVpEamRtMmRoZlk/edit?usp=sharing
> <
> http://tools.cisco.com/pecx/login?URL=offeringDetail?offeringId=464657__1390860007595
> >
>
>
> SPAG Sandbox link:
>
>
> http://tools.cisco.com/pecx/login?URL=offeringDetail?offeringId=464657__1390860007595
>
>
> Recommended Release:
>
> For customers looking for the most stable release with extended scheduled
> rebuilds:
>
> Choose the latest extended-support release
>
> ASR 903: XE 3.10.2 S
>
> ME 3600X/ME 3800X/ME3600X-24CX: 15.3(3)S2
>
>
> For customers looking for the latest feature sets:
>
> Choose the latest standard-support release
>
> ASR 903: XE 3.11.1 S
>
> ME 3600X/ME 3800X/ME3600X-24CX: 15.4(1)S1
>
>
> Cisco Live San Francisco 2014:
>
> If you are planning to attend Cisco Live San Francisco scheduled in  May

Re: [c-nsp] DC and Campus with N7K

[Livio Zanol Puppim]

Can this help you?

http://www.cisco.com/en/US/netsol/ns742/networking_solutions_program_category_home.html


2012/2/23 -Hammer- 

> Henry,
>You are asking if we can explain what makes a 747 fly. There is a short
> and uninformative answer and then there are the other 10,000 pages of
> documentation we could go over.
>
> There are a multitude of Nexus specific design guides on CCO. Depending on
> your scale and your specific business requirements. You might also consider
> engaging a TSA from Cisco or a datacenter resource to help get you off the
> ground. Here's a few links from a thread I had a while back. Someone was
> nice enough to share these with me. Although we can't seem to find the
> index page on CCO
>
> http://www.cisco.com/en/US/**prod/collateral/switches/**
> ps9441/ps9670/C07-572831-00_**Dsgn_Nexus_vPC_DG.pdf
> http://www.cisco.com/en/US/**prod/collateral/switches/**
> ps9441/ps9670/C07-572833-00_**NX-OS_CLI.pdf
> http://www.cisco.com/en/US/**prod/collateral/switches/**
> ps9441/ps9670/C07-572835-00_**NX-OS_vPC_DG.pdf
> http://www.cisco.com/en/US/**prod/collateral/switches/**
> ps9441/ps9670/C07-572834-00_**STDG_NX-OS_vPC_DG.pdf
> http://www.cisco.com/en/US/**prod/collateral/switches/**
> ps9441/ps9670/C07-572830-00_**Agg_Dsgn_Config_DG.pdf
> Missing chapter 6 (anyone?)
> http://www.cisco.com/en/US/**prod/collateral/switches/**
> ps9441/ps9670/C07-572828-00_**10Gb_Conn_Win_DG.pdf
> http://www.cisco.com/en/US/**prod/collateral/switches/**
> ps9441/ps9670/C07-572832-00_**VMware_ESX4_Nexus_DG.pdf
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/23/2012 12:25 AM, Henry Huaman wrote:
>
>> Hi,
>>
>>
>> Could you suggest us the best practices to design a DC and Campus?
>>
>> Currently we have only 2xN7K and we need deployment both networks (Campus
>> and DC).
>>
>> Maybe can we set VDCs (virtual device context)  to Campus and DC?
>>
>>
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Henry
>>
>>
>>
>>
>>
>>
>>
>>
>> __**_
>> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] Central services VPNs

[Livio Zanol Puppim]

Can't this be done using routing policies?

Just a guess...

2011/12/18 MKS 

> So I have a MPLS vpn question for the masterminds on this list;)
>
> I have two central services VRFs, A and B and I need route leaking
> (same import/export) between them to optimize traffic flow. The reason
> I need two VRFs is that I have to specifiy a different default gw for
> each VRF.
> But the problem is that this setup eats up tcam space in the 6500 we
> use, and doesn't scale then adding the third or forth VRF, then the
> vrfs contain 10k routes.
>
> Can this be done in a scaleale way (tcam) but still be able to
> optimize traffic flow and support different default GWs
>
> Regards
> MKS
> ___
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] Syslog Patterns

[Livio Zanol Puppim]

My script... (sorry for the portuguese language)

You need to execute the command "file prompt quiet" at configure terminal
before running the script.

It send the running-configuration to a server (can be TFTP, FTP, SCP,
etc...) every time a user enters the configure terminal mode and exit. It
works with IOS, NX-OS and IOS XR.

the format of the file is:
_-mm-dd-hh-mm-ss_.log
example: RT066_2012-01-23-10-13-13_tinka.log

Of course it needs some tuning like "nice" configuration, priority, etc...
It doesn't check if something has changed because every OS version has
different commands (thank you business units)

Enabling the script (I have copied to the router using dynamips to test):

event manager directory user policy nvram:/
event manager policy script.tcl type user

#THE SCRIPT!
::cisco::eem::event_register_syslog pattern ".*CONFIG_I.*"
namespace import ::cisco::eem::*
namespace import ::cisco::lib::*
set servidor "192.168.1.1"

#Pega nome do ativo
set nome_ativo [info hostname]

#Pega hora do evento
set data [clock format [clock seconds] -format "%Y-%m-%d-%H-%M-%S"]

#Pega a linha que gerou o evento (linha de log quando alguem sai de
'configure terminal')
array set arr_einfo [event_reqinfo]
set config_changes $arr_einfo(msg)

#Regexp que da match pegando usuario que mudou configuracao
set result [regexp {^.*by\s(.*)\s.*} $config_changes tudo user]
if {$result == 0} {
set result [regexp {^.*by\s(.*)} $config_changes tudo user]
}

#Coloca nome do ativo antes de tudo
set nome_arquivo $nome_ativo

#Adiciona data e usuario ao nome do arquivo
append nome_arquivo "_" $data "_" $user ".log"

#comeca processo para salvar arquivo no local desejado
if [catch {cli_open} result] {
error $result $errorInfo
} else {
array set cli1 $result
}
if [catch {cli_exec $cli1(fd) "enable"} result] {
error $result $errorInfo
}
#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#Alterar linha abaixo caso mude forma de envio
#
set comando "copy running-config tftp://$servidor/$nome_arquivo";
#puts $comando
#
#Alterar linha acima caso mude forma de envio
#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
if [catch {cli_exec $cli1(fd) $comando} result] {
error $result $errorInfo
}
# Close open cli before exit.
#if [catch {cli_close $cli1(fd) $cli1(tty_id)} result] {
# error $result $errorInfo
#}
puts "Running-config salva no servidor $servidor"



2012/1/18 Peter Rathlev 

> On Wed, 2012-01-18 at 17:10 +0100, Martin Komoň wrote:
> > There is a feature configured with "parser config cache interface",
> > that caches interface configuration. On a Cat6k5 w/ Sup720 it reduces
> > time to generate running config from 7 to ~1 sec (YMMV).
> >
> > Beware of the bug CSCtd93384!
>
> Nice, that does help. :-) Just tested on one Sup720 and the "sh run"
> went from ~20 seconds to ~10 seconds. Too bad with CSCtd93384 but at
> least it's supposed to be fixed in SXI4.
>
> --
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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 - MP-BPG with multiple OSPF areas

[Livio Zanol Puppim]

Thank you very much for your answer.

Searching the Internet about this topic, I've found a draft that seems to be
a near future solution for some major MPLS networks, called "seamless MPLS".
As written in the laymann draft (
http://tools.ietf.org/id/draft-ietf-mpls-seamless-mpls-00.txt), the
implementation uses 2 levels of IS-IS (or 2 OSPF areas).

Also, pseudowires and LDP downstream on demand are used. I know it's only a
draft, but I find it usefull.

Anyway, thank you for your advices.

2011/10/20 Mark Tinka 

> On Thursday, October 20, 2011 06:39:38 AM Livio Zanol Puppim
> wrote:
>
> > About MPLS features in multiple areas, aren't there
> > solutions that can be implemented to overcome the
> > limitations like LDP prefix leaking or some solutions
> > with mGRE?
>
> The IGP already knows about the individual infrastructure
> addresses between areas, which is what helps LDP to work.
>
> But MPLS-TE is something else. Paths have to be signaled,
> and by default, ingress routers signaling paths tend to
> prefer that the tail-end of the LSP be in the same area or
> level. If that isn't the case, Inter-Area TE is required.
>
> > What issue do you see keeping a lot of routers in a
> > single area (let's say 400) versus routers in different
> > areas?
>
> In OSPFv2, Areas help the routing protocol to scale,
> primarily due to the close ties between Type 1 and Type 2
> LSA's. This isn't an issue in OSPFv3 or IS-IS, as Topology
> and Reachability information is separated.
>
> At the risk of starting a routing protocol war, IS-IS has
> been known to scale very well in single level environments
> (see Vijay Gill's OSPF-to-IS-IS migration at ATDN).
>
> We have two networks, one where we run IS-IS in one level
> (L2) and one where we use multiple levels. It scales very
> well in both, and both are fairly large.
>
> There are rumours that OSPF can scale to some 10,000 routes
> on today's kit, but I'm not sure as I don't run it.
>
> > Are there any recommendations about that or about the
> > maximum number of routers in a single area, or maybe
> > something about benefits/problems in both designs?
>
> The problem with a single area/level is that one router
> sneezing a million miles away is heard by all other routers
> at the topology level. For such a problem, OSPFv3 or IS-IS
> will react better.
>
> Areas/levels help to scale the network, but introduce issues
> like MPLS-TE. In our IPTv network, where we use NG-MVPN for
> Multicast (p2mp RSVP-TE), we use a single L2 IS-IS domain,
> just to avoid issues or configuration complexities with
> signaling p2mp paths across different parts of the country.
> The risk is increased noise, but the kit can take it.
>
> Mark.
>



-- 
[]'s

Lívio Zanol Puppim
___
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 - MP-BPG with multiple OSPF areas

[Livio Zanol Puppim]

Thanks for your replies.

About MPLS features in multiple areas, aren't there solutions that can be
implemented to overcome the limitations like LDP prefix leaking or some
solutions with mGRE?

What issue do you see keeping a lot of routers in a single area (let's say
400) versus routers in different areas?

Are there any recommendations about that or about the maximum number of
routers in a single area, or maybe something about benefits/problems in both
designs?

I can't find many information on this, only simple designs with 5 to 10
routers in a single OSPF area...

2011/10/19 David Prall 

> Livio,
> As Adam stated, I was thinking of prefix-suppression in the context of
> using
> a single Area. Or perhaps minimizing the number of ABR's.
>
> If you still want to break your network up into multiple areas. You might
> want to deploy P's that are the ABR, while all PE's are in areas other than
> 0. Therefore all traffic between PE's will be inter-area via area 0 or
> intra-area. So no traffic is directly destined to Area 0.
>
> David
>
> --
> http://dcp.dcptech.com
>
>
> > -Original Message-
> > From: Livio Zanol Puppim [mailto:livio.zanol.pup...@gmail.com]
> > Sent: Wednesday, October 19, 2011 5:53 AM
> > To: David Prall
> > Cc: cisco-nsp@puck.nether.net
> > Subject: Re: [c-nsp] MPLS - MP-BPG with multiple OSPF areas
> >
> > You're right David. There are out of order no packets, only
> > asynchronous traffic. Sorry about that...
> >
> > I don't think that only the supression would do the job, since the
> > loopbacks will still be in different areas.
> >
> >
> > 2011/10/18 David Prall 
> >
> >
> >   Livio,
> >   Where are you getting out of order packets? You do have
> > asymmetric hop
> >   counts, which most likely means asymmetric latency. But all the
> > packets
> >   should be in order. Could use DWDM so that each router isn't
> > directly
> >   connected and everything looks the same number of hops away, of
> > course more
> >   ports are required at the Area 10 edge.
> >
> >   You can use prefix-suppression to only advertise the loopback
> > using OSPF, to
> >   minimize the number of LSA's. Then use MPLS and BGP for all
> > packet
> >   forwarding, including the global table.
> >
> >   David
> >
> >   --
> >   http://dcp.dcptech.com
> >
> >
> >   > -Original Message-
> >   > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> >   > boun...@puck.nether.net] On Behalf Of Livio Zanol Puppim
> >   > Sent: Tuesday, October 18, 2011 9:34 PM
> >   > To: cisco-nsp@puck.nether.net
> >   > Subject: [c-nsp] MPLS - MP-BPG with multiple OSPF areas
> >
> >   >
> >   > Hello everybody,
> >   >
> >   > I have a doubt with a lab design that we are creating to test
> > some MPLS
> >   > topologies. I would like to know if anybody can help me solve a
> > problem
> >   > that
> >   > I am facing about routing paths. To help ilustrate the topology
> > I'm
> >   > sending
> >   > the image link below.
> >   >
> >   >
> > https://docs.google.com/leaf?id=0B4Hf34G524HsNTA3ZTc1NTItNmJlNi00ZDQyLW
> >   > I1ZDAtYTg5MTliODRjMDhk&hl=en_US
> >   >
> >   > In the topology, I have two core routers interconnected with a
> > 1 Gbps
> >   > link
> >   > and several other routers interconnected with a 100Mbps link.
> > The
> >   > interfaces
> >   > between the core routers are in the OSPF area 0 and all other
> > physical
> >   > interfaces are in the OSPF area 10. Each one of the two core
> > routers
> >   > also
> >   > have a connection to the area 10 using a 100Mbps interface.
> >   >
> >   > The router ID and the "update-source interface", on the core
> > routers
> >   > (PE1)
> >   > is a loopback interface that belongs to the OSPF area 0.
> >   > The router ID and the "update-source interface", on the access
> > routers
> >   > (PE6)
> >   > is a loopback interface that belongs to the OSPF area 10.
> >   >
> >   > After establishing OSPF adjacencies between all routers, the
> > BGP
> >   > process
> >   > starts to establish conne

Re: [c-nsp] MPLS - MP-BPG with multiple OSPF areas

[Livio Zanol Puppim]

You're right David. There are out of order no packets, only asynchronous
traffic. Sorry about that...

I don't think that only the supression would do the job, since the loopbacks
will still be in different areas.

2011/10/18 David Prall 

> Livio,
> Where are you getting out of order packets? You do have asymmetric hop
> counts, which most likely means asymmetric latency. But all the packets
> should be in order. Could use DWDM so that each router isn't directly
> connected and everything looks the same number of hops away, of course more
> ports are required at the Area 10 edge.
>
> You can use prefix-suppression to only advertise the loopback using OSPF,
> to
> minimize the number of LSA's. Then use MPLS and BGP for all packet
> forwarding, including the global table.
>
> David
>
> --
> http://dcp.dcptech.com
>
>
> > -Original Message-
> > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> > boun...@puck.nether.net] On Behalf Of Livio Zanol Puppim
> > Sent: Tuesday, October 18, 2011 9:34 PM
> > To: cisco-nsp@puck.nether.net
> > Subject: [c-nsp] MPLS - MP-BPG with multiple OSPF areas
> >
> > Hello everybody,
> >
> > I have a doubt with a lab design that we are creating to test some MPLS
> > topologies. I would like to know if anybody can help me solve a problem
> > that
> > I am facing about routing paths. To help ilustrate the topology I'm
> > sending
> > the image link below.
> >
> > https://docs.google.com/leaf?id=0B4Hf34G524HsNTA3ZTc1NTItNmJlNi00ZDQyLW
> > I1ZDAtYTg5MTliODRjMDhk&hl=en_US
> >
> > In the topology, I have two core routers interconnected with a 1 Gbps
> > link
> > and several other routers interconnected with a 100Mbps link. The
> > interfaces
> > between the core routers are in the OSPF area 0 and all other physical
> > interfaces are in the OSPF area 10. Each one of the two core routers
> > also
> > have a connection to the area 10 using a 100Mbps interface.
> >
> > The router ID and the "update-source interface", on the core routers
> > (PE1)
> > is a loopback interface that belongs to the OSPF area 0.
> > The router ID and the "update-source interface", on the access routers
> > (PE6)
> > is a loopback interface that belongs to the OSPF area 10.
> >
> > After establishing OSPF adjacencies between all routers, the BGP
> > process
> > starts to establish connection, and this undesirable behavior happens:
> >
> > When the router PE1 (area 0) wants to establish a BGP session with
> > router
> > PE6 (area 10), the packet flow through all 100Mbps (purple arrow). When
> > the
> > router PE6 (area 10) responds, the packet flow through the 1Gbps
> > connection
> > between the core routers (red arrow). Every flow that needs to use the
> > LSPs
> > will do logically the same, causing out-of-order packets at the
> > network.
> >
> > I know that this is an expected behavior, as intra-area routes are
> > preferred
> > over inter-area routes, no matter what the link cost is.
> >
> > The question is: What solution do you guys think it's better for this
> > scenario, so that the packet flow goes always through the optimal path?
> > - Sham-links;
> > - Extended area 0 to one more hop;
> > - Change the "update-source interface" for area 10;
> > - Create small areas between the core and access routers
> > - Other solutions...
> >
> > We are planning to deploy a network with more than 200 PE routers in a
> > similar scenario, and I don't think that a single OSPF area is a good
> > choice
> > for us.
> >
> > Can anybody help with some advice?
> >
> > --
> > []'s
> >
> > Lívio Zanol Puppim
> > ___
> > 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/
>
>


-- 
[]'s

Lívio Zanol Puppim
___
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] MPLS - MP-BPG with multiple OSPF areas

[Livio Zanol Puppim]

Hello everybody,

I have a doubt with a lab design that we are creating to test some MPLS
topologies. I would like to know if anybody can help me solve a problem that
I am facing about routing paths. To help ilustrate the topology I'm sending
the image link below.

https://docs.google.com/leaf?id=0B4Hf34G524HsNTA3ZTc1NTItNmJlNi00ZDQyLWI1ZDAtYTg5MTliODRjMDhk&hl=en_US

In the topology, I have two core routers interconnected with a 1 Gbps link
and several other routers interconnected with a 100Mbps link. The interfaces
between the core routers are in the OSPF area 0 and all other physical
interfaces are in the OSPF area 10. Each one of the two core routers also
have a connection to the area 10 using a 100Mbps interface.

The router ID and the "update-source interface", on the core routers (PE1)
is a loopback interface that belongs to the OSPF area 0.
The router ID and the "update-source interface", on the access routers (PE6)
is a loopback interface that belongs to the OSPF area 10.

After establishing OSPF adjacencies between all routers, the BGP process
starts to establish connection, and this undesirable behavior happens:

When the router PE1 (area 0) wants to establish a BGP session with router
PE6 (area 10), the packet flow through all 100Mbps (purple arrow). When the
router PE6 (area 10) responds, the packet flow through the 1Gbps connection
between the core routers (red arrow). Every flow that needs to use the LSPs
will do logically the same, causing out-of-order packets at the network.

I know that this is an expected behavior, as intra-area routes are preferred
over inter-area routes, no matter what the link cost is.

The question is: What solution do you guys think it's better for this
scenario, so that the packet flow goes always through the optimal path?
- Sham-links;
- Extended area 0 to one more hop;
- Change the "update-source interface" for area 10;
- Create small areas between the core and access routers
- Other solutions...

We are planning to deploy a network with more than 200 PE routers in a
similar scenario, and I don't think that a single OSPF area is a good choice
for us.

Can anybody help with some advice?

-- 
[]'s

Lívio Zanol Puppim
___
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] converting N5K to FI6100

[Livio Zanol Puppim]

Some time ago I've seen a old Digital router with an IOS image. It worked
and was pretty funny...

2011/7/7 Pete Templin 

> On 7/7/11 3:39 PM, krunal shah wrote:
>
>  I want to achieve this goal to save cost for lab purpose. We have already
>> two 5010s and we do not want to spend more money in buying two extra 6100s
>> for UCS cluster. So when some wants to practice on UCS cluster we can load
>> UCS FI's image on 5010 chassis and convert into 6100 when UCS cluster is
>> not
>> being used we can load 5010 image and practice with N5Ks.
>>
>
> I've heard multiple times from Cisco peeps that the UCS FI is a Nexus 5k
> plus three integrated circuits that handle UCS management functions. Hence,
> you can't convert.  One might think that you can go the other way, but I
> would certainly guess that doesn't work either.
>
> pt
>
> __**_
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] Nexus vPC loop avoidance details?

[Livio Zanol Puppim]

I don't know if this is your case, but we've had some similar problem on
that. The problem was that some hosts weren't using the HSRP IP as the
gateway, they were using the physical IP of one of the Nexus 7000 box.
Changing the gateway to the HSRP IP solved the problem.

The TAC wasn't helpfull on this case.

2011/4/23 Tóth András 

> Hi,
>
> There's a good reason why it's not supported, mainly because it's not
> expected to work. It might work but there's no guarantee.
>
> You might consider opening a TAC case and do some further ELAM
> captures on the 6500 and N7k switches to see where the packets are
> seen, how and with which source/destination. This could explain the
> strange behavior you are seeing. Albeit, you might get the same
> information from TAC about the unsupported configuration.
>
> Best regards,
> Andras
>
>
> On Sat, Apr 23, 2011 at 6:46 PM, Adrian Chung 
> wrote:
> > Even with peer-gateway this is still unsupported, but I'm trying to
> understand why some traffic flows that appear to take the same layer 2 and
> layer 3 paths work while others don't.
> >
> >
> > --
> > Adrian Chung (adrian at enfusion-group dot com)
> > http://www.enfusion-group.com/~adrian/
> > GPG Fingerprint: C620 C8EA 86BA 79CC 384C E7BE A10C 353B 919D 1A17
> >
> > - Original Message -
> > From: Tóth András [mailto:diosbej...@gmail.com]
> > Sent: Saturday, April 23, 2011 12:43 PM
> > To: Adrian Chung
> > Cc: cisco-nsp@puck.nether.net 
> > Subject: Re: [c-nsp] Nexus vPC loop avoidance details?
> >
> > Hi,
> >
> > Have you tried with peer-gateway enabled? Is it working with that?
> >
> > Please keep in mind the following limitation:
> > When you attach a Layer 3 device to a vPC domain, the peering of
> > routing protocols using a VLAN also carried on the vPC peer-link is
> > not supported. If routing protocol adjacencies are needed between vPC
> > peer devices and a generic Layer 3 device, you must use physical
> > routed interfaces for the interconnection. Use of the vPC peer-gateway
> > feature does not change this requirement.
> >
> > Refer to the following link:
> >
> http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/interfaces/configuration/guide/if_vPC.html
> >
> > Best regards,
> > Andras
> >
> >
> > On Sat, Apr 23, 2011 at 3:08 AM, Adrian Chung 
> wrote:
> >> We've got 2 6500s (.145 and .146) connected to 2 Nexus 7Ks (.148, .149)
> >> running 5.1.3.
> >>
> >> The 6500s each have two ten gigE interfaces in a port-channel connected
> up
> >> to vPCs on the 7K side.  On top of this, each 6500 is forming an OSPF
> >> adjacency with each 7K.  The adjacencies form without a problem, and
> we're
> >> not using peer-gateway.
> >>
> >> I know this isn't a supported configuration, and we're looking at
> changing
> >> it, but in testing I've seen some weird scenarios that I can partly
> >> explain based on vPC loop avoidance, but other scenarios which I think
> >> should be blocked but don't seem to be.
> >>
> >> Here are a few scenarios, all based on two destination IPs .1 (an SVI on
> >> the 7K) and .10 (a server) in a subnet that is learned via OSPF and
> >> preferred via .149 (7K-2).  The destination subnet is routed from the
> 7Ks
> >> over a vPC to a service chassis on a transit subnet which goes to an
> FWSM.
> >>  The inside interface of the FWSM is on another transit subnet that
> comes
> >> back up the same vPC to a different VRF on the 7Ks which the destination
> >> subnet resides in.
> >>
> >> 1) from 6500 #1 (.145) attempting to ping an address ending in .10.
>  This
> >> works, with no packet loss.  If I calculate the port-channel hash on
> >> 6500-1 it uses the port-channel member that goes to 7K-2 (which is also
> >> where the L3 nexthop is.  7K-2 from what I can gather should send the
> >> traffic out its local vPC member port facing the service chassis.  On
> the
> >> service chassis, return packets hash to the port-channel member which
> goes
> >> to 7K-2.  No cross vPC peer-link traffic.
> >>
> >> 2) from 6500-1 (.145) attempting to ping the .1 IP which is an HSRP IP
> on
> >> an SVI on the 7Ks.  This doesn't work at all.  Port-channel hash on
> 6500-1
> >> sends to port-channel member that goes to 7K-1.  Since the nexthop is
> .149
> >> and is across the vPC peer-link, my understanding is it gets the loop
> >> avoidance bit set and sent across the peer-link, but since the egress
> port
> >> to the service chassis is on a vPC, and the vPC member port on 7K-1 is
> >> active, the packet gets dropped.
> >>
> >> That makes sense so far.  From 6500-2 (.146) the opposite scenarios
> work,
> >> can ping .1, but not .10.  For both, behaviour is consistent in that
> >> anything that crosses the peer-link gets filtered/dropped...
> >>
> >> But when testing with an IP that is upstream from the 6500s (204.x.x.x)
> I
> >> can ping both the .1 and .10 IPs with absolutely no problems, even when
> >> the traffic appears to cross the peer-link and takes the same path as 1)
> >> and 2) above.
> >>

[c-nsp] ASR 9000 as border router

[Livio Zanol Puppim]

Hello,

Anyone had experience using ASR 9000 as a border router using full BGP? We
want to use it to route BGP full with initialy 2 links.

-- 
[]'s

Lívio Zanol Puppim
___
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] Limiting Interface Traffic

[Livio Zanol Puppim]

Off Topic, but I've seen this happening in linux machines using tc and HTB
as queue discipline in interfaces with trunk, matching packets at virtual
VLANs interfaces. Also, input control is not so cool in linux. If I can
remember, I think that output policy was working right.

2010/10/5 Tony 

> Hi Bill,
>
>
> --- On Wed, 6/10/10, Bill Blackford  wrote:
>
> > I am trying to get a working
> > configuration that can limit traffic bandwidth to a fixed
> > rate in both ingress and egress directions on a given
> > interface. I have customer handoffs that I'm linking at 1g
> > and need to limit to 200M, 100M each, etc.
> >
> > My platform is a fixed switch, Cisco 3750G. I know I can't
> > apply a service-policy outbound (only inbound) so I'm
> > looking at other options.
> >
> > I've configured 'mls qos'
> >
> > I am testing with a single flow using Iperf (two hosts).
>
>
> >
> > 3. Policy-map. Applying a policy-map as a service-policy
> > input, I see that limiting is happening (ingress) but not at
> > the rate I specified.
> > Can policing input start to reach the configured limit when
> > using multiple flows? IOW, I'm only getting 36M (not 200M)
> > testing with a single flow.
> >
>
> If you're testing with a single flow then that might explain the throughput
> you're seeing. Have you tried with multiple flows ? If what you're seeing is
> due to TCP backoff then you would expect to see the typical "sawtooth" line
> if you graph the traffic through the interface although 36M seems a little
> low, but might depend on burst parameters.
>
> If you're not already, then I would suggest using UDP in iperf so that you
> can verify if what you are seeing is due to TCP behaviour. Using multiple
> TCP threads you should get closer to your full rate.
>
> Also suggest that you test in one direction at a time and only then do both
> directions at the same time.
>
>
> regards,
> Tony.
>
>
>
>
>
> ___
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] ASIC to switch port mapping

[Livio Zanol Puppim]

This is a VERY interesting topic. We need to have more attention at buffers
size in our next aquisition. Thanks guy.

2010/9/12 Keegan Holley 

> You can always buy more switches and move ports.  The 2960 and the hundreds
> of other switches (and blades) just like it is a wiring closet switch for
> the enterprise.  It should be common knowledge (no offense if this is new
> information to you) that they are oversubscribed, have tiny buffers and are
> not suitable for anything but.  The fact is that these switches cost
> anywhere from $800 - $2200 and support is also cheap.  This allows us all
> to
> get all the users and printers connected on the cheap.  4900's, Juniper
> EX's
> and the hundreds of other switches (and blades)that are not oversubscribed,
> have large queues and can switch at line rate are about $4k - $20k.  It may
> actually be cheaper to just buy another 2960 than to upgrade to something
> beefier.  Is this really user traffic?  Is the user actually pushing 1g of
> traffic or are the ASICs just filling up faster than the frames can be
> switched off the buffers? I've never actually seen queues overrun by
> something that wasn't server/enterprise grade.
>
>
>
> On Sun, Sep 12, 2010 at 4:45 PM, Gert Doering  wrote:
>
> > Hi,
> >
> > On Sun, Sep 12, 2010 at 08:41:49PM +0200, Andrew Miehs wrote:
> > > > 2960s are especially prone to drops (esp if mls qos enabled).
> > >
> > > Does this include 2960Gs?
> >
> > Yes.
> >
> > 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/
> >
> ___
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] arista 7500 versus cisco nexus

[Livio Zanol Puppim]

"lookslike" a good switch. But I haven't read too much articles neither the
datasheet.

I have found this document comparing switches manufacturers:
http://www.networkworld.com/community/node/57999

I'm interested in information about this switch too...

2010/7/22 Kevin Hatem 

> Has anyone seen any actual (real network) performance stats on Arista's
> 7500 "flagship" switch or have one in production?  I cannot seem to find
> anyone who has one of these boxes or any info on how they really perform
> under a load, especially compared to the Nexus 7k (or even the 5k).
>
> This e-mail, including any attachments and response string, may contain
> proprietary information which is confidential and may be legally privileged.
> It is for the intended recipient only. If you are not the intended recipient
> or transmission error has misdirected this e-mail, please notify the author
> by return e-mail and delete this message and any attachment immediately. If
> you are not the intended recipient you must not use, disclose, distribute,
> forward, copy, print or rely on this e-mail in any way except as permitted
> by the author.
> ___
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] Nexus family rate-limit monitor via SNMP

[Livio Zanol Puppim]

Hello,

Does anybody knows if it's possible to monitor rate-limit utilization using
SNMP in any equipements of the "nexus family"? I haven't found any MIB with
this information (
ftp://ftp-sj.cisco.com/pub/mibs/supportlists/nexus7000/Nexus7000MIBSupportList.html
).

Thanks in advance.

-- 
[]'s

Lívio Zanol Puppim
___
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] circuit degradation/error simulator

[Livio Zanol Puppim]

NETEM is a very good choice for this. We have a test enviroment using this
including automatic graphs generation with RRDtool.

http://www.linuxfoundation.org/collaborate/workgroups/networking/netem


2010/5/12 

> > For some testing I'm looking for a piece of software which is capable of
> > inserting various degradation and/or errors into a traffic stream.
> >
> > The setup I thought of is setting up a PC with two NIC which passes
> > traffic between the interfaces. In the middle the software should be
> > able to generate packetloss, delay, jitter, fragmentation, reordering
> > and alike within the traffic stream passed on.
>
> A FreeBSD box with dummynet can do this nicely.
>
>
> http://info.iet.unipi.it/~luigi/dummynet/
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> ___
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] Nexus 2000 vs Catalyst 4948 for access layer

[Livio Zanol Puppim]

Correcting my last e-mail:
Actually, It's a new datacenter for existing servers and at the same time it
must support new applications.

Christopher,
We are planning to use only Fiber Optics, no twinax cables. Also, I can't
use 10G/FCoE at Nexus 7000. But you have a good argument.

2010/2/12 

> Given the pricing, I'd be more concerned about "losing ports" on the Nexus
> 7000 than on the 5000.
>
>
> A modest Nexus 7010 (two sups, four 32-port cards, two power supplies, LAN
> software license) lists for just under US$400,000 using bundle pricing.
>
> That gets you 128 10Gb/s ports, oversubscribed 4:1.
>
> So, US$3125 per port (US$12,500 per non-blocking port).
>
> Those ports don't support the inexpensive twinax cables, so add another
> US$3,600 to put SR optics on both ends of each link.
>
> The Nexus 5000 OTOH lists for about US$40,000 (dual power 5020 with 40
> ports and base license).  US$1,000 per non-blocking port.  And these ports
> support the twinax cables ($150-$250 / cable)
>
> With optics (on both ends), N7K: $6,700 to $15,100 per port.
> With twinax cables, N5K: $1,200 per port.
>
> And the N5K pricing gets even better when you price the bundle option with
> 6 2148Ts, optics and twinax cables.
>
> If you have a requirement for several hundred 1Gb/s ports with no
> oversubscription through the core, then the 5K might not be any help.
>
> /chris
>
>
> -Original Message-----
> From: cisco-nsp-boun...@puck.nether.net [mailto:
> cisco-nsp-boun...@puck.nether.net] On Behalf Of Livio Zanol Puppim
> Sent: Friday, February 12, 2010 10:38 AM
> To: Tony Varriale
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Nexus 2000 vs Catalyst 4948 for access layer
>
> Ok...
>
> Let's try again, more simplyfied.
>
> Using a DC topology with Nexus family, I must have, for gigabit
> connectivity, Nexus 2000 -> Nexus 5000 -> Nexus 7000.
>
> Using traditional way I can have Catalyst 4948 -> Nexus 7000, saving 10G
> ports from Nexus 5000 for access.
>
> That's my only problem, loosing ports com 5000... Is it clear enought?
>
> Can you give me a good reason to use the first design?
>
> 2010/2/12 Tony Varriale 
>
> > - Original Message - From: "Livio Zanol Puppim" <
> >> livio.zanol.pup...@gmail.com>
> >> To: "Jason Plank" 
> >> Cc: "Cisco NSP ((E-mail))'" 
> >> Sent: Thursday, February 11, 2010 7:18 PM
> >>
> >> Subject: Re: [c-nsp] Nexus 2000 vs Catalyst 4948 for access layer
> >>
> >>
> >  Brad,
> >>
> >> Can't I make "the cloud" with traditional switches (4948 for example)?
> >>
> >
> > You can call it what you'd like.
> >
> >
> >  As I've said before, my only concern is that I'll loose A LOT of access
> >> ports
> >> on Nexus 5000 that could be used by servers with 10GE/FCoE.
> >>
> >
> > Ok, maybe I missed something.  What are you trying to do?  High density 1
> > gig?  5k does that (with 2k).  Cheap and layer 2 high density 10g?  5k
> does
> > that.
> >
> >
> >  I'm expecting that 10G(with FCoE) will dominate the servers design, so
> my
> >> loss will be huge.
> >>
> >
> > It will be a large part of the future, no doubt.  Your loss?
> >
> >
> >  f Nexux 2000 could be attached directly to an Nexus 7000 (it is not
> quite
> >> dfficult to make that works) the deisgn would perfect fit for our needs.
> >>
> >
> > As I've stated before, there is no if.  Not sure how many more times I
> have
> > to say it...
> >
> > tv
> > ___
> > 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/
> >
>
>
>
> --
> []'s
>
> Lívio Zanol Puppim
> ___
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] Nexus 2000 vs Catalyst 4948 for access layer

[Livio Zanol Puppim]

Yes.

2010/2/12 Manu Chao 

> Is it a new Datacenter?
>
> On Fri, Feb 12, 2010 at 4:37 PM, Livio Zanol Puppim <
> livio.zanol.pup...@gmail.com> wrote:
>
>> Ok...
>>
>> Let's try again, more simplyfied.
>>
>> Using a DC topology with Nexus family, I must have, for gigabit
>> connectivity, Nexus 2000 -> Nexus 5000 -> Nexus 7000.
>>
>> Using traditional way I can have Catalyst 4948 -> Nexus 7000, saving 10G
>> ports from Nexus 5000 for access.
>>
>> That's my only problem, loosing ports com 5000... Is it clear enought?
>>
>> Can you give me a good reason to use the first design?
>>
>> 2010/2/12 Tony Varriale 
>>
>> > - Original Message - From: "Livio Zanol Puppim" <
>> >> livio.zanol.pup...@gmail.com>
>> >> To: "Jason Plank" 
>> >> Cc: "Cisco NSP ((E-mail))'" 
>> >> Sent: Thursday, February 11, 2010 7:18 PM
>> >>
>> >> Subject: Re: [c-nsp] Nexus 2000 vs Catalyst 4948 for access layer
>> >>
>> >>
>> >  Brad,
>> >>
>> >> Can’t I make “the cloud” with traditional switches (4948 for example)?
>> >>
>> >
>> > You can call it what you'd like.
>> >
>> >
>> >  As I’ve said before, my only concern is that I’ll loose A LOT of access
>> >> ports
>> >> on Nexus 5000 that could be used by servers with 10GE/FCoE.
>> >>
>> >
>> > Ok, maybe I missed something.  What are you trying to do?  High density
>> 1
>> > gig?  5k does that (with 2k).  Cheap and layer 2 high density 10g?  5k
>> does
>> > that.
>> >
>> >
>> >  I’m expecting that 10G(with FCoE) will dominate the servers design, so
>> my
>> >> loss will be huge.
>> >>
>> >
>> > It will be a large part of the future, no doubt.  Your loss?
>> >
>> >
>> >  f Nexux 2000 could be attached directly to an Nexus 7000 (it is not
>> quite
>> >> dfficult to make that works) the deisgn would perfect fit for our
>> needs…
>> >>
>> >
>> > As I've stated before, there is no if.  Not sure how many more times I
>> have
>> > to say it...
>> >
>> > tv
>> > ___
>> > 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/
>> >
>>
>>
>>
>> --
>> []'s
>>
>> Lívio Zanol Puppim
>>   ___
>> 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/
>>
>
>


-- 
[]'s

Lívio Zanol Puppim
___
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] Fw: Nexus 2000 vs Catalyst 4948 for access layer

[Livio Zanol Puppim]

I need 8 x 48 ports, and I do not want to use 4 modules at my
Distribution/Core switches for this purpose. Also, this will bring a lot of
cable complexity

My planned core/distribution line cards:
2 supervisors, X fabrics, 2 10GbE

2010/2/12 Tony Varriale 

>
> >- Original Message -
> >From: Livio Zanol Puppim
> >To: Tony Varriale
> >Cc: cisco-nsp@puck.nether.net
> >Sent: Friday, February 12, 2010 9:37 AM
> >Subject: Re: [c-nsp] Nexus 2000 vs Catalyst 4948 for access layer
> >
>
> >Ok...
> >
> >Let's try again, more simplyfied.
> >
> >Using a DC topology with Nexus family, I must have, for gigabit
> connectivity, Nexus 2000 -> Nexus 5000 -> Nexus 7000.
>
> Why not just plug directly into the 7k?  It has 48 port 1g blades...tx and
> fiber.
>
> tv
> ___
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] Nexus 2000 vs Catalyst 4948 for access layer

[Livio Zanol Puppim]

Now we're talking. Replies later

2010/2/12 

> Given the pricing, I'd be more concerned about "losing ports" on the Nexus
> 7000 than on the 5000.
>
>
> A modest Nexus 7010 (two sups, four 32-port cards, two power supplies, LAN
> software license) lists for just under US$400,000 using bundle pricing.
>
> That gets you 128 10Gb/s ports, oversubscribed 4:1.
>
> So, US$3125 per port (US$12,500 per non-blocking port).
>
> Those ports don't support the inexpensive twinax cables, so add another
> US$3,600 to put SR optics on both ends of each link.
>
> The Nexus 5000 OTOH lists for about US$40,000 (dual power 5020 with 40
> ports and base license).  US$1,000 per non-blocking port.  And these ports
> support the twinax cables ($150-$250 / cable)
>
> With optics (on both ends), N7K: $6,700 to $15,100 per port.
> With twinax cables, N5K: $1,200 per port.
>
> And the N5K pricing gets even better when you price the bundle option with
> 6 2148Ts, optics and twinax cables.
>
> If you have a requirement for several hundred 1Gb/s ports with no
> oversubscription through the core, then the 5K might not be any help.
>
> /chris
>
>
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:
> cisco-nsp-boun...@puck.nether.net] On Behalf Of Livio Zanol Puppim
> Sent: Friday, February 12, 2010 10:38 AM
> To: Tony Varriale
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Nexus 2000 vs Catalyst 4948 for access layer
>
> Ok...
>
> Let's try again, more simplyfied.
>
> Using a DC topology with Nexus family, I must have, for gigabit
> connectivity, Nexus 2000 -> Nexus 5000 -> Nexus 7000.
>
> Using traditional way I can have Catalyst 4948 -> Nexus 7000, saving 10G
> ports from Nexus 5000 for access.
>
> That's my only problem, loosing ports com 5000... Is it clear enought?
>
> Can you give me a good reason to use the first design?
>
> 2010/2/12 Tony Varriale 
>
> > - Original Message - From: "Livio Zanol Puppim" <
> >> livio.zanol.pup...@gmail.com>
> >> To: "Jason Plank" 
> >> Cc: "Cisco NSP ((E-mail))'" 
> >> Sent: Thursday, February 11, 2010 7:18 PM
> >>
> >> Subject: Re: [c-nsp] Nexus 2000 vs Catalyst 4948 for access layer
> >>
> >>
> >  Brad,
> >>
> >> Can't I make "the cloud" with traditional switches (4948 for example)?
> >>
> >
> > You can call it what you'd like.
> >
> >
> >  As I've said before, my only concern is that I'll loose A LOT of access
> >> ports
> >> on Nexus 5000 that could be used by servers with 10GE/FCoE.
> >>
> >
> > Ok, maybe I missed something.  What are you trying to do?  High density 1
> > gig?  5k does that (with 2k).  Cheap and layer 2 high density 10g?  5k
> does
> > that.
> >
> >
> >  I'm expecting that 10G(with FCoE) will dominate the servers design, so
> my
> >> loss will be huge.
> >>
> >
> > It will be a large part of the future, no doubt.  Your loss?
> >
> >
> >  f Nexux 2000 could be attached directly to an Nexus 7000 (it is not
> quite
> >> dfficult to make that works) the deisgn would perfect fit for our needs.
> >>
> >
> > As I've stated before, there is no if.  Not sure how many more times I
> have
> > to say it...
> >
> > tv
> > ___
> > 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/
> >
>
>
>
> --
> []'s
>
> Lívio Zanol Puppim
> ___
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] Nexus 2000 vs Catalyst 4948 for access layer

[Livio Zanol Puppim]

Ok...

Let's try again, more simplyfied.

Using a DC topology with Nexus family, I must have, for gigabit
connectivity, Nexus 2000 -> Nexus 5000 -> Nexus 7000.

Using traditional way I can have Catalyst 4948 -> Nexus 7000, saving 10G
ports from Nexus 5000 for access.

That's my only problem, loosing ports com 5000... Is it clear enought?

Can you give me a good reason to use the first design?

2010/2/12 Tony Varriale 

> - Original Message ----- From: "Livio Zanol Puppim" <
>> livio.zanol.pup...@gmail.com>
>> To: "Jason Plank" 
>> Cc: "Cisco NSP ((E-mail))'" 
>> Sent: Thursday, February 11, 2010 7:18 PM
>>
>> Subject: Re: [c-nsp] Nexus 2000 vs Catalyst 4948 for access layer
>>
>>
>  Brad,
>>
>> Can’t I make “the cloud” with traditional switches (4948 for example)?
>>
>
> You can call it what you'd like.
>
>
>  As I’ve said before, my only concern is that I’ll loose A LOT of access
>> ports
>> on Nexus 5000 that could be used by servers with 10GE/FCoE.
>>
>
> Ok, maybe I missed something.  What are you trying to do?  High density 1
> gig?  5k does that (with 2k).  Cheap and layer 2 high density 10g?  5k does
> that.
>
>
>  I’m expecting that 10G(with FCoE) will dominate the servers design, so my
>> loss will be huge.
>>
>
> It will be a large part of the future, no doubt.  Your loss?
>
>
>  f Nexux 2000 could be attached directly to an Nexus 7000 (it is not quite
>> dfficult to make that works) the deisgn would perfect fit for our needs…
>>
>
> As I've stated before, there is no if.  Not sure how many more times I have
> to say it...
>
> tv
> ___
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] Nexus 2000 vs Catalyst 4948 for access layer

[Livio Zanol Puppim]

Brad,

Can’t I make “the cloud” with traditional switches (4948 for example)? As
I’ve said before, my only concern is that I’ll loose A LOT of access ports
on Nexus 5000 that could be used by servers with 10GE/FCoE. Again, the only
reasons you are giving me to use this design is “management facility” and
vPC.

So, putting it in a balance I see more losses than benefits. What’s the big
problem on connecting to another device to manage it? Is this really a big
loss? It’ll take 5 minutes more to make a service. I don’t think that this
is the best benefit of this design. I would really appreciate to have all
switches of the same series managed by the same program (cisco DCNM),
unfortunally I think we are going the other way. Loosing 20 access
interfaces, isn’t a good option for me…

I’m not talking about a huge datacenter. I will only need 10 1G switch for
the next years, so “big L2 domain” for me isn’t to much trouble. If you
could explain better this problem maybe I change my mind…

I’m expecting that 10G(with FCoE) will dominate the servers design, so my
loss will be huge. I’ll maintain 1Gbps only for backward compatibility (10
years? hehehe).

If Nexux 2000 could be attached directly to an Nexus 7000 (it is not quite
difficult to make that works) the deisgn would perfect fit for our needs…

2010/2/10 Jason Plank 

> Brad,
>
> You just made a terrible assumption. :)
>
> Jason
>
> >> Then you should post from your gmail account.
> >
> > What difference would that make? We're all adults here.
> >
> >
> > Cheers,
> > Brad
> >
> >
> > --
> > Brad Hedlund, CCIE #5530
> > Technology Solutions Architect, Data Center
> > bhedl...@cisco.com
> > http://www.internetworkexpert.org
> >
> > ___
> > 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/
> >
>
>
>
> --
> --
> Jason Plank
> (CCIE #16560)
> ___
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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] Nexus 2000 vs Catalyst 4948 for access layer

[Livio Zanol Puppim]

Neus 2000 does not have FCoE.

2010/2/9 Manu Chao 

> Two key advantages:
> - Technical: FCoE, vPC
> - Management: you needn't to manage N2Ks
>
> R/
> Manu
>
> On Tue, Feb 9, 2010 at 11:40 AM, Livio Zanol Puppim <
> livio.zanol.pup...@gmail.com> wrote:
>
>> Yeah, You are right.
>>
>> But I would like to use my nexus 5000 10GE/FCoE ports just for access
>> servers, maximizing it's use... The uplinks from Nexus 2000 could easially
>> go directly to my distribution/core. Unfortunally, nexus 2000 is just an
>> fabric extender and can ONLY be attached to Nexus 5000... Maybe CISCO
>> changes it's later...
>>
>> Let's think:
>>
>> 10 nexus 2000 using all uplink ports = 40 ports. Yes, 40 ports that I must
>> use at my nexus 5000. That's more than 1 entirelly switch (1RU) and almost
>> 1
>> switch (2RU).
>>
>> I haven't figure out yet what's the advantage of having this design (nexus
>> 2000 -> nexus 5000) other than the "old" one (catalyst 4948 -> nexus
>> 7000/cisco 6500). That's what I'm talking about.
>>
>> The only REAL advantage so far is the vPC...
>>
>> 2010/2/2 Brad Hedlund 
>>
>> >
>> > True, the Nexus 2000 does not locally switch, but lets explore that for
>> a
>> > second...
>> >
>> > 1) a typical enterprise Data Center is running applications that are not
>> > latency sensitive, where latencies in the 10s of microseconds are
>> perfectly
>> > OK and nobody is really counting anyway. Only in the small minority of
>> Data
>> > Centers running high frequency trading, grid computing, or some other
>> ultra
>> > low latency application, every *nanosecond* matters and local switching
>> with
>> > fewer hops is of paramount importance. Furthermore, these applications
>> are
>> > quickly migrating away from 1GE to 10GE attached servers for the obvious
>> low
>> > latency advantages.
>> >
>> > 2) the Nexus 2000 has 4x10GE uplink bandwidth versus the 2x10GE uplink
>> for
>> > 4948.  This results in a possible 1:1.2 oversubscription ratio for Nexus
>> > 2000 to handle the additional uplink load that may otherwise not be
>> present
>> > on a 4948.
>> >
>> > 3) The upstream Nexus 5000 implements cut-through switching, and the
>> Nexus
>> > 2000 itself also uses cut-through for frames entering on 1GE and
>> egressing
>> > on 10GE.  The two combined often results in port-to-port latencies
>> similar
>> > to a Catalyst 6500, even without the "local switching".  If you are
>> > comfortable with your Catalyst 6500 local switching latencies, you can
>> > expect similar performance from a Nexus 2000/5000 combination.
>> >
>> >
>> > --
>> > Brad Hedlund, CCIE #5530
>> > Consulting Systems Engineer, Data Center
>> > bhedl...@cisco.com
>> > http://www.internetworkexpert.org
>> >
>> >
>> >
>> > On Jan 31, 2010, at 5:25 PM, David Hughes wrote:
>> >
>> > >
>> > > On 29/01/2010, at 6:54 AM, Livio Zanol Puppim wrote:
>> > >
>> > >> Can anyone please tell me the advantages of using Nexus 2000 over
>> > Catalyst
>> > >> 4948 as access layers switches?
>> > >> Using Nexus 2000, I have to use at least 2 ports at my Nexus 5000,
>> that
>> > >> could be used by servers with 10GbE/FCoE servers.
>> > >
>> > > The N2K does no local switching so if you have any east-west traffic
>> > between ports on the same switch you'll be better served by a more
>> > "traditional" access switch.  Naturally the N2K offers centralised
>> > management etc etc but that may or may not be of interest depending on
>> the
>> > size of your deployment.
>> > >
>> > >
>> > >
>> > > David
>> > > ...
>> > > ___
>> > > 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/
>> >
>> >
>>
>>
>> --
>> []'s
>>
>> Lívio Zanol Puppim
>>  ___
>> 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/
>>
>
>


-- 
[]'s

Lívio Zanol Puppim
___
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] Nexus 2000 vs Catalyst 4948 for access layer

[Livio Zanol Puppim]

Yeah, You are right.

But I would like to use my nexus 5000 10GE/FCoE ports just for access
servers, maximizing it's use... The uplinks from Nexus 2000 could easially
go directly to my distribution/core. Unfortunally, nexus 2000 is just an
fabric extender and can ONLY be attached to Nexus 5000... Maybe CISCO
changes it's later...

Let's think:

10 nexus 2000 using all uplink ports = 40 ports. Yes, 40 ports that I must
use at my nexus 5000. That's more than 1 entirelly switch (1RU) and almost 1
switch (2RU).

I haven't figure out yet what's the advantage of having this design (nexus
2000 -> nexus 5000) other than the "old" one (catalyst 4948 -> nexus
7000/cisco 6500). That's what I'm talking about.

The only REAL advantage so far is the vPC...

2010/2/2 Brad Hedlund 

>
> True, the Nexus 2000 does not locally switch, but lets explore that for a
> second...
>
> 1) a typical enterprise Data Center is running applications that are not
> latency sensitive, where latencies in the 10s of microseconds are perfectly
> OK and nobody is really counting anyway. Only in the small minority of Data
> Centers running high frequency trading, grid computing, or some other ultra
> low latency application, every *nanosecond* matters and local switching with
> fewer hops is of paramount importance. Furthermore, these applications are
> quickly migrating away from 1GE to 10GE attached servers for the obvious low
> latency advantages.
>
> 2) the Nexus 2000 has 4x10GE uplink bandwidth versus the 2x10GE uplink for
> 4948.  This results in a possible 1:1.2 oversubscription ratio for Nexus
> 2000 to handle the additional uplink load that may otherwise not be present
> on a 4948.
>
> 3) The upstream Nexus 5000 implements cut-through switching, and the Nexus
> 2000 itself also uses cut-through for frames entering on 1GE and egressing
> on 10GE.  The two combined often results in port-to-port latencies similar
> to a Catalyst 6500, even without the "local switching".  If you are
> comfortable with your Catalyst 6500 local switching latencies, you can
> expect similar performance from a Nexus 2000/5000 combination.
>
>
> --
> Brad Hedlund, CCIE #5530
> Consulting Systems Engineer, Data Center
> bhedl...@cisco.com
> http://www.internetworkexpert.org
>
>
>
> On Jan 31, 2010, at 5:25 PM, David Hughes wrote:
>
> >
> > On 29/01/2010, at 6:54 AM, Livio Zanol Puppim wrote:
> >
> >> Can anyone please tell me the advantages of using Nexus 2000 over
> Catalyst
> >> 4948 as access layers switches?
> >> Using Nexus 2000, I have to use at least 2 ports at my Nexus 5000, that
> >> could be used by servers with 10GbE/FCoE servers.
> >
> > The N2K does no local switching so if you have any east-west traffic
> between ports on the same switch you'll be better served by a more
> "traditional" access switch.  Naturally the N2K offers centralised
> management etc etc but that may or may not be of interest depending on the
> size of your deployment.
> >
> >
> >
> > David
> > ...
> > ___
> > 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/
>
>


-- 
[]'s

Lívio Zanol Puppim
___
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] Nexus 2000 vs Catalyst 4948 for access layer

[Livio Zanol Puppim]

Hi folks,

Can anyone please tell me the advantages of using Nexus 2000 over Catalyst
4948 as access layers switches?
Using Nexus 2000, I have to use at least 2 ports at my Nexus 5000, that
could be used by servers with 10GbE/FCoE servers.

Also, are there any advantages on NX-OS compared to IOS?

Thanks.

-- 
[]'s

Lívio Zanol Puppim
___
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] tacacs+ restrictions

[Livio Zanol Puppim]

Have you  added "aaa authorization config-commands" to the configuration at
the router?

2009/12/12 Peter Rathlev 

> On Sat, 2009-12-12 at 15:15 +0100, Arne Larsen wrote:
> > Hi all.
> >
> > I know it's a bit of topic, but anyway.
> > I'm trying to get tacacs+ to restrict access and commands for users.
> > I can't seem to get it right. Whatever I do, I ether get no
> > configurations commands rejected or all get rejected.
> > I would like to make a user that only can change vlan tag under
> > interfaces configuration This is what I tried to configure..
> >
> [...]
> >
> > Have anyone of you tried to do something similar, any input would be
> > appreciated very much.
> > Or does someone know where I can seek help.
>
> We have an "operator" group with limited access to some datacenter
> switches, configured like this:
>
> acl = access-sw-only {
>permit = ^10\.77\.24[456]\.
> }
>
> group = operator {
>default service = deny
>login = PAM
>service = exec {
>priv-lvl = 15
>}
> Exec level commands 
>cmd = show {
>permit "."
>}
>cmd = exit {
>permit "$"
>}
>cmd = quit {
>permit "$"
>}
>cmd = write {
>permit "terminal $"
>permit "memory $"
>}
> Configure commands 
>cmd = configure {
>permit "^terminal $"
>}
>#--- Allow the exec level commands from configure mode ---#
>cmd = do {
>permit "^show .*"
>}
>#--- Allow entering interfaces ---#
>cmd = interface {
>#--- Disallow configuring uplinks ---#
>deny "^GigabitEthernet [12]/0/2[34] $"
>#--- Allow configuring physical interfaces ---#
>permit "^(Gigabit|Fast)Ethernet.*"
>}
>#--- Allow a range of specific interface conf commands ---#
>cmd = switchport {
>permit "^access vlan [128][0-9][0-9] $"
>permit "^mode access $"
>}
>cmd = description {
>permit "."
>}
>cmd = shutdown {
>permit "^$"
>permit "^$"
>}
>cmd = spanning-tree {
>permit "^portfast $"
>permit "^bpduguard enable $"
>}
>cmd = mls {
>permit "^qos cos 3 $"
>permit "^qos cos override $"
>}
>#--- Allow creation and naming of VLANs 100-299 + 800-899 ---#
>cmd = vlan {
>permit "^[128][0-9][0-9] $"
>}
>cmd = name {
>permit "."
>}
>#--- Allow unshutting interfaces, and clearing descriptions ---#
>cmd = no {
>permit "^shutdown $"
>permit "^description .*"
>}
>acl = access-sw-only
> }
>
> You can enable debugging for the tac_plus daemon to see exactly what the
> device asks to have accepted/rejected.
>
> --
> 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/
>



-- 
[]'s

Lívio Zanol Puppim
___
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/