[c-nsp] Cisco ACS

2012-09-06 Thread Mohammad Khalil

Hi 
Is it possible to use Cisco ACS for windows and linux servers authentication?


  
___
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] Dual Planar Core Design

2012-09-06 Thread Adam Vitkovsky
Oh yeah 3D network diagrams been here for quite some time now they look
great on paper and have some mind blowing possibilities, however the cost of
such a solution is mind blowing as well
These are usually meant for core networks = most expensive boxes in the
network - now try to convince the management that you actually need to build
a second backbone to improve availability

I had the honor to study a state of the art multi-planar control-plane
architecture which was actually used for scalability reasons rather than HA
Back then I started to play with these concepts  in the virtual lab - as I
mentioned already, these type of designs need plethora of hardware -so it
was easier to simulate them

To your question
I believe these designs are a well kept secrets of those who actually run
them so you probably won't find presentations about real deployments.
Though you can find several academic papers and studies
These popped up when I searched for: ospf tetrahedron
http://www.nyu.edu/its/pubs/connect/spring04/kyriannis_nyunet3.html
http://newsroom.cisco.com/dlls/NYU_CP.pdf


adam
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Alexander Lim
Sent: Thursday, September 06, 2012 2:40 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Dual Planar Core Design

Guys,

Do you know if there is any reference for dual planar core network design
out there?
I came to know about this from cisco live session BRKRST-3365 the evolution
of the next generation network

Thanks. 

Regards,
Alexander Lim

___
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] having a one-way vlan 1 stp issue....

2012-09-06 Thread Aaron
Any idea why I can only see spanning tree for vlan 1 in *one direction* ?
all other vlan's stp work fine.  AND if I flip the stp priority to prefer
root bridge placement on CE2 IT WORKS!  See below.  (also bidirectional
flows work for vlan 1 pings, vtp and cdp)  ONLY STP VLAN 1 is broke in one
direction ...that's the only problem I'm seeing.

Aaron

(topology)

CE2 (3750) g1/0/1 trunk all---g0/23
(me3600)---mpls-(asr9k)g0/0/0/9/.116- trunk all  g1/0/1 (3750) CE1

(configs)

--
- CE2
--

ce2-realnoc#sh run in g1/0/1

interface GigabitEthernet1/0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
end

--
 PE (3600)
--

noc-3600#sh run in g0/23

interface GigabitEthernet0/23
 description c7 tls-test
 switchport trunk allowed vlan none
 switchport mode trunk
 load-interval 30
 service instance 1 ethernet
  encapsulation dot1q 1-4094
  l2protocol tunnel cdp stp vtp dtp pagp lldp lacp udld
  xconnect 10.101.0.3 2 encapsulation mpls

--
- PE (asr9k)
--

RP/0/RSP0/CPU0:sv-b-9k#sh run l2vpn xconnect group tls-test

l2vpn
 xconnect group tls-test
  p2p tls-test
   interface GigabitEthernet0/0/0/9.116
   neighbor 10.101.12.253 pw-id 2

--
- CE1
--

ce1-top-crml#sh run in g1/0/1

interface GigabitEthernet1/0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
end


(what I'm seeing)

CE2  --- stp broke in this direction ONLY FOR VLAN 1 
CE1  (from ce1 to ce2)

Ce2 *doesn't* see vlan 1 config bpdu's carrying superior bridge prio of 8193
!!


ce2-realnoc#sh sp roo

RootHello Max Fwd
Vlan   Root ID  CostTime  Age Dly  Root Port
  - - --- ---  
VLAN0001 32769 68bc.0c61.3a80 02   20  15
VLAN0010  8202 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0020  8212 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0021  8213 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0022  8214 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0023  8215 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0024  8216 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0025  8217 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0116  8308 68bc.0c61.2f80 42   20  15  Gi1/0/1

ce1-top-crml#sh sp roo

RootHello Max Fwd
Vlan   Root ID  CostTime  Age Dly  Root Port
  - - --- ---  
VLAN0001  8193 68bc.0c61.2f80 02   20  15
VLAN0010  8202 68bc.0c61.2f80 02   20  15
VLAN0020  8212 68bc.0c61.2f80 02   20  15
VLAN0021  8213 68bc.0c61.2f80 02   20  15
VLAN0022  8214 68bc.0c61.2f80 02   20  15
VLAN0023  8215 68bc.0c61.2f80 02   20  15
VLAN0024  8216 68bc.0c61.2f80 02   20  15
VLAN0025  8217 68bc.0c61.2f80 02   20  15
VLAN0116  8308 68bc.0c61.2f80 02   20  15


-

CE2  --- stp works in this direction for vlan 1   CE1
(from ce2 to ce1)

Ce1 *does* see vlan 1 config bpdu's carrying superior bridge prio of 4097

ce2-realnoc#conf t
ce2-realnoc(config)#spanning-tree vl 1 priority 4096
ce2-realnoc(config)#^Z
ce2-realnoc#sh sp roo
*Mar  2 18:58:12.604: %SYS-5-CONFIG_I: Configured from console by console

RootHello Max Fwd
Vlan   Root ID  CostTime  Age Dly  Root Port
  - - --- ---  
VLAN0001  4097 68bc.0c61.3a80 02   20  15
VLAN0010  8202 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0020  8212 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0021  8213 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0022  8214 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0023  8215 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0024  8216 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0025  8217 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0116  8308 68bc.0c61.2f80 42   20  15  Gi1/0/1
ce2-realnoc#


ce1-top-crml#sh sp roo

RootHello Max Fwd
Vlan   Root ID  CostTime  Age Dly  Root Port
  - - --- ---  
VLAN0001  4097 68bc.0c61.3a80 42   20  15  Gi1/0/1
VLAN0010  8202 68bc.0c61.2f80 

Re: [c-nsp] Dual Planar Core Design

2012-09-06 Thread Phil Bedard
We have looked at a dual plane design for both reliability and scalability.  In 
some instances the design can result in less hardware than your typical ring 
design if traffic can be balanced well enough across multiples planes.  The 
other benefit is being able to extend a network beyond two planes in order to 
eliminate density issues and having to move to more complex proprietary 
multi-chassis setups or having to upgrade to larger routers.   Similar to the 
newer leaf/spine clos data center setups.  

The biggest hurdle is usually migrating an existing core network away from a 
traditional design. 

If you talk to your SE teams they can put you in touch with folks who can 
provide more details but it's true there isn't a lot of information out there.  

Phil.

On Sep 6, 2012, at 5:29 AM, Adam Vitkovsky adam.vitkov...@swan.sk wrote:

 Oh yeah 3D network diagrams been here for quite some time now they look
 great on paper and have some mind blowing possibilities, however the cost of
 such a solution is mind blowing as well
 These are usually meant for core networks = most expensive boxes in the
 network - now try to convince the management that you actually need to build
 a second backbone to improve availability
 
 I had the honor to study a state of the art multi-planar control-plane
 architecture which was actually used for scalability reasons rather than HA
 Back then I started to play with these concepts  in the virtual lab - as I
 mentioned already, these type of designs need plethora of hardware -so it
 was easier to simulate them
 
 To your question
 I believe these designs are a well kept secrets of those who actually run
 them so you probably won't find presentations about real deployments.
 Though you can find several academic papers and studies
 These popped up when I searched for: ospf tetrahedron
 http://www.nyu.edu/its/pubs/connect/spring04/kyriannis_nyunet3.html
 http://newsroom.cisco.com/dlls/NYU_CP.pdf
 
 
 adam
 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net
 [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Alexander Lim
 Sent: Thursday, September 06, 2012 2:40 AM
 To: cisco-nsp@puck.nether.net
 Subject: [c-nsp] Dual Planar Core Design
 
 Guys,
 
 Do you know if there is any reference for dual planar core network design
 out there?
 I came to know about this from cisco live session BRKRST-3365 the evolution
 of the next generation network
 
 Thanks. 
 
 Regards,
 Alexander Lim
 
 ___
 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] having a one-way vlan 1 stp issue....resolved....bug in 3750 ce1 ios, ugh

2012-09-06 Thread Aaron
RESOLVED!

Cisco tac found a bug on my ce1 3750

Details...

tac case for tls test

sh int g0/0/0/9*
sh controllers np ports all
sh controllers np counters np1

(looked for UNKNOWN_L2_ON_L3_DISCARD)

proved that vlan 1 was arriving untagged by...

conf t
int g0/0/0/9.117
encap unta
commi

do sh int g0/0/0/9.117 and we saw packets come in and drop 1 for 1

then i disabled stp vl 1 on ce1 and saw that it was further proven that this
was infact untagged traffic coming from that ce1 3750 *untagged* EVEN THOUGH
I HAD vlan dot1q tag native globally config'd!!

cdp and vtp worked though even while stp in vlan 1 didn't.

tac said this is a bug with what i was running on ce1...
c3750-ipbase-mz.122-50.SE5.bin

i upgraded to same code on ce2... c3750-ipservicesk9-mz.122-50.SE3.bin

works fine now.




-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron
Sent: Thursday, September 06, 2012 10:36 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] having a one-way vlan 1 stp issue

Any idea why I can only see spanning tree for vlan 1 in *one direction* ?
all other vlan's stp work fine.  AND if I flip the stp priority to prefer
root bridge placement on CE2 IT WORKS!  See below.  (also bidirectional
flows work for vlan 1 pings, vtp and cdp)  ONLY STP VLAN 1 is broke in one
direction ...that's the only problem I'm seeing.

Aaron

(topology)

CE2 (3750) g1/0/1 trunk all---g0/23
(me3600)---mpls-(asr9k)g0/0/0/9/.116- trunk all  g1/0/1 (3750) CE1

(configs)

--
- CE2
--

ce2-realnoc#sh run in g1/0/1

interface GigabitEthernet1/0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
end

--
 PE (3600)
--

noc-3600#sh run in g0/23

interface GigabitEthernet0/23
 description c7 tls-test
 switchport trunk allowed vlan none
 switchport mode trunk
 load-interval 30
 service instance 1 ethernet
  encapsulation dot1q 1-4094
  l2protocol tunnel cdp stp vtp dtp pagp lldp lacp udld
  xconnect 10.101.0.3 2 encapsulation mpls

--
- PE (asr9k)
--

RP/0/RSP0/CPU0:sv-b-9k#sh run l2vpn xconnect group tls-test

l2vpn
 xconnect group tls-test
  p2p tls-test
   interface GigabitEthernet0/0/0/9.116
   neighbor 10.101.12.253 pw-id 2

--
- CE1
--

ce1-top-crml#sh run in g1/0/1

interface GigabitEthernet1/0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
end


(what I'm seeing)

CE2  --- stp broke in this direction ONLY FOR VLAN 1 
CE1  (from ce1 to ce2)

Ce2 *doesn't* see vlan 1 config bpdu's carrying superior bridge prio of 8193
!!


ce2-realnoc#sh sp roo

RootHello Max Fwd
Vlan   Root ID  CostTime  Age Dly  Root Port
  - - --- ---  
VLAN0001 32769 68bc.0c61.3a80 02   20  15
VLAN0010  8202 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0020  8212 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0021  8213 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0022  8214 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0023  8215 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0024  8216 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0025  8217 68bc.0c61.2f80 42   20  15  Gi1/0/1
VLAN0116  8308 68bc.0c61.2f80 42   20  15  Gi1/0/1

ce1-top-crml#sh sp roo

RootHello Max Fwd
Vlan   Root ID  CostTime  Age Dly  Root Port
  - - --- ---  
VLAN0001  8193 68bc.0c61.2f80 02   20  15
VLAN0010  8202 68bc.0c61.2f80 02   20  15
VLAN0020  8212 68bc.0c61.2f80 02   20  15
VLAN0021  8213 68bc.0c61.2f80 02   20  15
VLAN0022  8214 68bc.0c61.2f80 02   20  15
VLAN0023  8215 68bc.0c61.2f80 02   20  15
VLAN0024  8216 68bc.0c61.2f80 02   20  15
VLAN0025  8217 68bc.0c61.2f80 02   20  15
VLAN0116  8308 68bc.0c61.2f80 02   20  15


-

CE2  --- stp works in this direction for vlan 1   CE1
(from ce2 to ce1)

Ce1 *does* see vlan 1 config bpdu's carrying superior bridge prio of 4097

ce2-realnoc#conf t
ce2-realnoc(config)#spanning-tree vl 1 priority 4096 ce2-realnoc(config)#^Z
ce2-realnoc#sh sp roo *Mar  2 18:58:12.604: %SYS-5-CONFIG_I: Configured from
console by console

RootHello Max Fwd
Vlan   Root ID  CostTime  Age Dly  Root Port

[c-nsp] Cisco to Juniper LAG/LACP - Juniper not sending traffic over both links.

2012-09-06 Thread Joseph Jackson
Hey networkers,

I have 3 sites connected to a service providers MPLS network.  Two of
those sites (Dallas and LA) are configured as etherchannel/LACP ports
with 2 1gig uplinks in them.  On our end we have Catalyst 6506-E
switches the provider side is Juniper gear (I don't have model info).
The issue I am seeing is that on our side we are sending traffic out
of both interfaces and appear to be load balancing correctly.  The
provider (juniper) side is only sending traffic inbound to us over 1
of the links and not using the full etherchannel to load balance in
coming bandwidth.  On the LA end the juniper routers are seeing two
mac addresses learned on that etherchannel - one mac is the SVI and
one mac is one of the member ports.  The Dallas side is only seeing
one mac address.  The service provider is telling me that their
hardware is working correctly and that the hashing algorithm on the
juniper boxes is deciding that only one link should receive traffic.
Anyone else see this issue or can provide any tips.

Thanks!

Joseph
___
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 to Juniper LAG/LACP - Juniper not sending traffic over both links.

2012-09-06 Thread Joseph Jackson
Just got word from the provider.  They are using the default hashing
algorithm which is based on mac address.

On Thu, Sep 6, 2012 at 4:33 PM, Andrew Miehs and...@2sheds.de wrote:
 Which hashing algorithm are the using? One based on MAC address will do 
 exactly as you are describing.

 Andrew

 Sent from a mobile device

 On 07/09/2012, at 6:58, Joseph Jackson recou...@gmail.com wrote:

 Hey networkers,

 I have 3 sites connected to a service providers MPLS network.  Two of
 those sites (Dallas and LA) are configured as etherchannel/LACP ports
 with 2 1gig uplinks in them.  On our end we have Catalyst 6506-E
 switches the provider side is Juniper gear (I don't have model info).
 The issue I am seeing is that on our side we are sending traffic out
 of both interfaces and appear to be load balancing correctly.  The
 provider (juniper) side is only sending traffic inbound to us over 1
 of the links and not using the full etherchannel to load balance in
 coming bandwidth.  On the LA end the juniper routers are seeing two
 mac addresses learned on that etherchannel - one mac is the SVI and
 one mac is one of the member ports.  The Dallas side is only seeing
 one mac address.  The service provider is telling me that their
 hardware is working correctly and that the hashing algorithm on the
 juniper boxes is deciding that only one link should receive traffic.
 Anyone else see this issue or can provide any tips.

 Thanks!

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


[c-nsp] Outbound PACL

2012-09-06 Thread Paul Wozney
Hello NSP folks,

I hacked around in the feature navigator and I couldn't come to any direct
evidence that this can or cannot be done.

But the configuration guide suggests that we can configure an outbound PACL
on the 4500 platform.  Can anyone confirm or deny that this will work?

---
Paul Wozney
Network Consultant
phone: +1 604-629-9975
toll free: +1 866-748-0516
email: p...@wozney.ca
web: http://wozney.ca
___
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/