Re: [c-nsp] ACL logging on n5k

[Lincoln Dale]

On 11/08/2010, at 3:54 PM, Tassos Chatzithomaoglou wrote:
> Just another quick question : can ethanalyser capture traffic *before *being 
> dropped by an acl?

N7K: yes.
and in fact, because the way we actually do it is implement the data plane 
forwarding in the h/w (ASIC) path with a 'rate limited copy' sent to 
control-plane for the logging action, you can even do "permit ip any any log" 
on MPPS worth of traffic and not have it melt the box.

if you're asking about N5K then the answer is 'no', at least until the 'log' 
keyword is added.
because control-plane won't see the packet otherwise.


cheers,

lincoln.
___
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] OFF LIST - open source sms gateway.

[Rocker Feller]

 Hi all,

Could anyone point me in the right direction where I can get a commercial
but open source vpn gateway with the following features?

1. has USSD features
2. An open API system for modification as per customer needs.
3. Two way communication (interactive)

Kindly contact me off list and thank you all in advance.

Rocker
___
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] ACL logging on n5k

[Tassos Chatzithomaoglou]

Thx to everyone for clearing that out.
I guess i'll have to wait for some releases until it becomes available...

Just another quick question : can ethanalyser capture traffic *before 
*being dropped by an acl?


--
Tassos

Lincoln Dale wrote on 11/08/2010 07:53:

N7K supports ACL logging, ACL time ranges, MAC packet-classify functionality 
etc., N5K does not currently support them.
the mistake is that documentation was carried over to N5K from N7K without 
being changed.


cheers,

lincoln.

On 11/08/2010, at 5:58 AM, Arie Vayner (avayner) wrote:

   

Yes, it seems that ACL logging is not yet support on N5K, and CSCth28899
is there to track its introduction (no timeframe yet...)

I am checking why the command reference shows as if it is supported...

Arie

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Arvind .cisconsp
Sent: Tuesday, August 10, 2010 15:31
To: Tassos Chatzithomaoglou
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ACL logging on n5k

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method
=fetchBugDetails&bugId=CSCth28899

State:
New
Severity: Enhancement
Version: 4.2(1)N1(1)

On Tue, Aug 10, 2010 at 7:09 AM, Tassos Chatzithomaoglou
 

wrote:
   
 

n5k(config-acl)# deny ip any any ?

dscpMatch packets with given dscp value
fragments   Check non-initial fragments
precedence  Match packets with given precedence value

n5k(config-acl)# deny ip any any log
^
% Invalid ip address at '^' marker.
n5k(config-acl)#


"time-range" option is also not available.

There must be something i'm missing...

--
Tassos


Arie Vayner (avayner) wrote on 10/08/2010 13:50:

Seems to be in 4.1(3) too...
   
 

http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
 

/reference/rel_4_1/security_cmd_ref.html#wp1279114

Strange...

Arie

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
Chatzithomaoglou
Sent: Tuesday, August 10, 2010 13:35
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ACL logging on n5k

I'm using 4.1(3)N2(1) and the "log" option is not available.
Should i guess an upgrade is needed, although release notes do not
mention anything?

--
Tassos


Arie Vayner (avayner) wrote on 10/08/2010 12:43:


 

Tassos,

Looking here:



   
 

http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
 


 

/reference/rel_4_2_1_N2_1/security_cmd_ref.html#wp1279114

I can see the 'log' option listed...

Arie

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
Chatzithomaoglou
Sent: Monday, August 09, 2010 22:22
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ACL logging on n5k

N5k datasheet says it's supported, but i couldn't find any other
reference.
Is it supported and if yes, how do you enable it?

--
Tassos

___
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] ACL logging on n5k

[Lincoln Dale]

N7K supports ACL logging, ACL time ranges, MAC packet-classify functionality 
etc., N5K does not currently support them.
the mistake is that documentation was carried over to N5K from N7K without 
being changed.


cheers,

lincoln.
  
On 11/08/2010, at 5:58 AM, Arie Vayner (avayner) wrote:

> Yes, it seems that ACL logging is not yet support on N5K, and CSCth28899
> is there to track its introduction (no timeframe yet...)
> 
> I am checking why the command reference shows as if it is supported...
> 
> Arie
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Arvind .cisconsp
> Sent: Tuesday, August 10, 2010 15:31
> To: Tassos Chatzithomaoglou
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] ACL logging on n5k
> 
> http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method
> =fetchBugDetails&bugId=CSCth28899
> 
>  d=fetchBugDetails&bugId=CSCth28899>State:
> New
> Severity: Enhancement
> Version: 4.2(1)N1(1)
> 
> On Tue, Aug 10, 2010 at 7:09 AM, Tassos Chatzithomaoglou
> > wrote:
> 
>> n5k(config-acl)# deny ip any any ?
>> 
>> dscpMatch packets with given dscp value
>> fragments   Check non-initial fragments
>> precedence  Match packets with given precedence value
>> 
>> n5k(config-acl)# deny ip any any log
>>^
>> % Invalid ip address at '^' marker.
>> n5k(config-acl)#
>> 
>> 
>> "time-range" option is also not available.
>> 
>> There must be something i'm missing...
>> 
>> --
>> Tassos
>> 
>> 
>> Arie Vayner (avayner) wrote on 10/08/2010 13:50:
>> 
>> Seems to be in 4.1(3) too...
>>> 
> http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
>>> /reference/rel_4_1/security_cmd_ref.html#wp1279114
>>> 
>>> Strange...
>>> 
>>> Arie
>>> 
>>> -Original Message-
>>> From: cisco-nsp-boun...@puck.nether.net
>>> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
>>> Chatzithomaoglou
>>> Sent: Tuesday, August 10, 2010 13:35
>>> To: cisco-nsp@puck.nether.net
>>> Subject: Re: [c-nsp] ACL logging on n5k
>>> 
>>> I'm using 4.1(3)N2(1) and the "log" option is not available.
>>> Should i guess an upgrade is needed, although release notes do not
>>> mention anything?
>>> 
>>> --
>>> Tassos
>>> 
>>> 
>>> Arie Vayner (avayner) wrote on 10/08/2010 12:43:
>>> 
>>> 
 Tassos,
 
 Looking here:
 
 
 
>>> 
> http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
>>> 
>>> 
 /reference/rel_4_2_1_N2_1/security_cmd_ref.html#wp1279114
 
 I can see the 'log' option listed...
 
 Arie
 
 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net
 [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
 Chatzithomaoglou
 Sent: Monday, August 09, 2010 22:22
 To: cisco-nsp@puck.nether.net
 Subject: [c-nsp] ACL logging on n5k
 
 N5k datasheet says it's supported, but i couldn't find any other
 reference.
 Is it supported and if yes, how do you enable it?
 
 --
 Tassos
 
 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/
 
 
 
 
>>> ___
>>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>> 
>>> 
>>> 
>> ___
>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> ___
> 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] IPv6 ACL

[Ivan]

Can anyone confirm that IPv6 ACLs successfully match packets on upper
layer protocols (ULP) such as TCP even when the Hop-by-Hop EH (extension
header) is present?

I found some information regarding matching ULPs when the AH extension
header is present but have been unable to do the same for the Hop-by-Hop
EH. 
(http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-sec_trfltr_fw.html#wp1072428)

Cheers

Ivan



___
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] Erspan on 7600

[Mack McBride]

What about software switched traffic (mostly glean traffic)?
Doesn't that get handled by the RP?

Mack McBride
Network Engineer
Viawest, Inc.

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tim Stevenson
Sent: Tuesday, August 10, 2010 8:59 AM
To: Martin Moens; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Erspan on 7600

Hi Martin,

ERSPAN is handled by the hardware, either the central replication 
engine on the sup, or by the REs on the linecards themselves (depends 
on which sup & LCs you have).

In no case do we use the sup CPU to perform ERSPAN encap/decap.

Tim

At 07:10 AM 8/10/2010, Martin Moens averred:

>Hi list,
>
>Does someone have experience with erspan on a 7600?
>Is this loading the CPU (rsp720 / ws-x6748-ge-tx) or is it handled in
>hardware?
>
>Martin
>
>___
>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/

___
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] 7606 config issue !!!

[Ge Moua]

 we just upgrade one of our core "6509 / 3bxl" to this code a few days 
ago and so far no problem; you're probably looking for feedback on the 
the 7600 platform though.


--
Regards,
Ge Moua
Network Design Engineer

University of Minnesota | OIT - NTS
--


On 8/10/10 4:28 PM, David Hughes wrote:

On 23/07/2010, at 9:45 AM, Jared Mauch wrote:


Cisco has posted sxi4a.



Has anyone identified any early issues with sxi4a ?



Thanks

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/

___
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] Nice EEM applet to protect against certain DDoS situations (sup720)

[bas]

On Mon, Aug 9, 2010 at 3:25 AM, Dobbins, Roland  wrote:
>
> On Aug 9, 2010, at 2:47 AM, bas wrote:
>
>> And now imagine if I were a bad guy that has control over 50 compromised 
>> servers in networks that do not filter
>> outbound spoofed traffic.
>
>
> We don't have to imagine it; this is a quite common scenario, except that the 
> attacker has 5K or 50K or 500K bots in his particular botnet, heh.
___
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] 7606 config issue !!!

[David Hughes]

On 23/07/2010, at 9:45 AM, Jared Mauch wrote:

> Cisco has posted sxi4a. 



Has anyone identified any early issues with sxi4a ?



Thanks

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/

Re: [c-nsp] ACL logging on n5k

[Arie Vayner (avayner)]

Yes, it seems that ACL logging is not yet support on N5K, and CSCth28899
is there to track its introduction (no timeframe yet...)

I am checking why the command reference shows as if it is supported...

Arie

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Arvind .cisconsp
Sent: Tuesday, August 10, 2010 15:31
To: Tassos Chatzithomaoglou
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ACL logging on n5k

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method
=fetchBugDetails&bugId=CSCth28899

State:
New
Severity: Enhancement
Version: 4.2(1)N1(1)

On Tue, Aug 10, 2010 at 7:09 AM, Tassos Chatzithomaoglou
 wrote:

> n5k(config-acl)# deny ip any any ?
> 
>  dscpMatch packets with given dscp value
>  fragments   Check non-initial fragments
>  precedence  Match packets with given precedence value
>
> n5k(config-acl)# deny ip any any log
> ^
> % Invalid ip address at '^' marker.
> n5k(config-acl)#
>
>
> "time-range" option is also not available.
>
> There must be something i'm missing...
>
> --
> Tassos
>
>
> Arie Vayner (avayner) wrote on 10/08/2010 13:50:
>
>  Seems to be in 4.1(3) too...
>>
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
>> /reference/rel_4_1/security_cmd_ref.html#wp1279114
>>
>> Strange...
>>
>> Arie
>>
>> -Original Message-
>> From: cisco-nsp-boun...@puck.nether.net
>> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
>> Chatzithomaoglou
>> Sent: Tuesday, August 10, 2010 13:35
>> To: cisco-nsp@puck.nether.net
>> Subject: Re: [c-nsp] ACL logging on n5k
>>
>> I'm using 4.1(3)N2(1) and the "log" option is not available.
>> Should i guess an upgrade is needed, although release notes do not
>> mention anything?
>>
>> --
>> Tassos
>>
>>
>> Arie Vayner (avayner) wrote on 10/08/2010 12:43:
>>
>>
>>> Tassos,
>>>
>>> Looking here:
>>>
>>>
>>>
>>
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
>>
>>
>>> /reference/rel_4_2_1_N2_1/security_cmd_ref.html#wp1279114
>>>
>>> I can see the 'log' option listed...
>>>
>>> Arie
>>>
>>> -Original Message-
>>> From: cisco-nsp-boun...@puck.nether.net
>>> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
>>> Chatzithomaoglou
>>> Sent: Monday, August 09, 2010 22:22
>>> To: cisco-nsp@puck.nether.net
>>> Subject: [c-nsp] ACL logging on n5k
>>>
>>> N5k datasheet says it's supported, but i couldn't find any other
>>> reference.
>>> Is it supported and if yes, how do you enable it?
>>>
>>> --
>>> Tassos
>>>
>>> ___
>>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>>
>>>
>>>
>> ___
>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
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] linux vpn client

[Quinn Snyder]

network-manager-vpnc
in the ubuntu repos.
little buggy. in my experience, no one client works for all profiles
or vpn endpoints. shrewsoft, kvpnc, and nm-vpnc all are used on my
system.

ynmv.

q.

-= sent via iphone. please excuse spelling, grammar, and brevity =-

On Aug 10, 2010, at 9:57, Jan Gregor  wrote:

> Hi,
>
> there exists network-manager plugin for vpnc. Never used it though.
>
> Best regards,
>
> Jan
>
> On 08/10/2010 02:54 PM, Deric Kwok wrote:
>> yes. it works, thank you
>>
>> but I have to type every time. How can I save configure?
>>
>> ls it possible I can use the GUI to connect?
>>
>> Thank you
>>
>> On Mon, Aug 9, 2010 at 2:10 PM, Gabriel  wrote:
>>> vpnc
>>>
>>> On Aug 9, 2010 9:07 PM, "Deric Kwok"  wrote:
>>>
>>> Hi all
>>>
>>> Can you suggest the linux vpn client?
>>>
>>> eg: fedora, suse
>>>
>>> I also try the anyconnect. but don't know how to put the configure file
>>>
>>> When I use it in xwindow, it asks me to provide  "connect to " vpn gui
>>>
>>> But I type the ip address, it won't work
>>>
>>> Thank you
>>> ___
>>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>
>> ___
>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Erspan on 7600

[Martin Moens]

Thanks Tim,

Exactly what I wanted to hear :-)

Martin

Tim Stevenson  wrote on 10/08/2010 16:59:

> Hi Martin,
> 
> ERSPAN is handled by the hardware, either the central replication
> engine on the sup, or by the REs on the linecards themselves (depends
> on which sup & LCs you have). 
> 
> In no case do we use the sup CPU to perform ERSPAN encap/decap.
> 
> Tim
> 
> At 07:10 AM 8/10/2010, Martin Moens averred:
> 
>> Hi list,
>> 
>> Does someone have experience with erspan on a 7600?
>> Is this loading the CPU (rsp720 / ws-x6748-ge-tx) or is it handled
>> in hardware? 
>> 
>> Martin
>> 
>> ___
>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>> https://p
> uck.nether.net/mailman/listinfo/cisco-nsp
>> archive at
>> http://puck.neth
>> er.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] Erspan on 7600

[Tim Stevenson]

Hi Martin,

ERSPAN is handled by the hardware, either the central replication 
engine on the sup, or by the REs on the linecards themselves (depends 
on which sup & LCs you have).


In no case do we use the sup CPU to perform ERSPAN encap/decap.

Tim

At 07:10 AM 8/10/2010, Martin Moens averred:


Hi list,

Does someone have experience with erspan on a 7600?
Is this loading the CPU (rsp720 / ws-x6748-ge-tx) or is it handled in
hardware?

Martin

___
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] linux vpn client

[Jan Gregor]

Hi,

there exists network-manager plugin for vpnc. Never used it though.

Best regards,

Jan

On 08/10/2010 02:54 PM, Deric Kwok wrote:
> yes. it works, thank you
> 
> but I have to type every time. How can I save configure?
> 
> ls it possible I can use the GUI to connect?
> 
> Thank you
> 
> On Mon, Aug 9, 2010 at 2:10 PM, Gabriel  wrote:
>> vpnc
>>
>> On Aug 9, 2010 9:07 PM, "Deric Kwok"  wrote:
>>
>> Hi all
>>
>> Can you suggest the linux vpn client?
>>
>> eg: fedora, suse
>>
>> I also try the anyconnect. but don't know how to put the configure file
>>
>> When I use it in xwindow, it asks me to provide  "connect to " vpn gui
>>
>> But I type the ip address, it won't work
>>
>> Thank you
>> ___
>> 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/




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

Re: [c-nsp] Problems with dot1q trunk over EoMPLS with WS-X6148-GE-TX

[Heath Jones]

Im not sure if it helps, but I remember having a lot of trouble back doing
DSL stuff - similar issues. There was a command: 'ip tcp mss-adjust' or
something similar - might be worth having a look at..



On 8 August 2010 12:02, Marco Matarazzo  wrote:

> Hi all,
>
> was trying to configure an EoMPLS link between two 6500s:
>
> Router1
> 6506 w/VS-S720-10G IOS 12.2(33)SXI2
> Customer facing blade: WS-X6148-RJ-45
>
> Router2
> 6503 w/WS-SUP32-10GE-3B IOS 12.2(33)SXI2
> Customer facing blade: WS-X6148-GE-TX
>
> The routers are connected between via the Sup integrated 10Gb interface,
> mtu
> on them is 9000.
>
> EoMPLS works fine if there's no dot1q trunk going over the VC. If there's
> one set, everything SEEMS to work, pings go thru, dns requests are fine, I
> can access any vlans from anywhere etc. Problems is with that I cannot
> access any internet page of downloading anything, all the connections
> stall!
> Seems like a MTU problem to me so begin troubleshooting and find that the
> maximum packet size that can travel between this dot1q trunk over EoMPLS is
> 1496 instead of 1500.
>
> On both routers of course the VC is up:
>
> Router1#sh mpls l2 vc
>
> Local intf Local circuit  Dest addressVC ID  Status
> -  -- --- --
> --
> Fa2/32 Ethernet   x.y.z.56   71172104   UP
>
> Router2##sh mpls l2 vc
>
> Local intf Local circuit  Dest addressVC ID  Status
> -  -- --- --
> --
> Gi2/3  Ethernet   x.y.z.40   71172104   UP
>
> And the MTU of the VC is 1500:
>
> Router1##sh mpls l2 vc 71172104 det
> Local interface: Fa2/32 up, line protocol up, Ethernet up
>  Destination address: x.y.z.56, VC ID: 71172104, VC status: up
>Output interface: Te5/5, imposed label stack {700}
>Preferred path: not configured
>Default path: active
>Next hop: x.y.z.14
>  Create time: 03:32:35, last status change time: 03:32:35
>  Signaling protocol: LDP, peer x.y.z.56:0 up
>Targeted Hello: x.y.z.40(LDP Id) -> x.y.z.56
>MPLS VC labels: local 969, remote 700
>Group ID: local 0, remote 0
>MTU: local 1500, remote 1500
>Remote interface description: -VC-71172104--
>  Sequencing: receive disabled, send disabled
>  VC statistics:
>packet totals: receive 1959291, send 3518574
>byte totals:   receive 1809500293, send 700321865
>packet drops:  receive 0, send 0
>
> Router2##sh mpls l2 vc 71172104 det
> Local interface: Gi2/3 up, line protocol up, Ethernet up
>  Destination address: x.y.z.40, VC ID: 71172104, VC status: up
>Output interface: Te1/2, imposed label stack {969}
>Preferred path: not configured
>Default path: active
>Next hop: x.y.z.13
>  Create time: 3d19h, last status change time: 03:30:59
>  Signaling protocol: LDP, peer x.y.232.40:0 up
>Targeted Hello: x.y.z.56(LDP Id) -> x.y.z.40
>MPLS VC labels: local 700, remote 969
>Group ID: local 0, remote 0
>MTU: local 1500, remote 1500
>Remote interface description: -VC-71172104--
>  Sequencing: receive disabled, send disabled
>  VC statistics:
>packet totals: receive 50349195, send 5715589
>byte totals:   receive 10440236044, send 5129079765
>packet drops:  receive 0, send 0
>
> This is the port config:
>
> Router1#sh run int fa 2/32
> Building configuration...
>
> Current configuration : 245 bytes
> !
> interface FastEthernet2/32
>  description -VC-71172104--
>  no ip address
>  ip verify unicast source reachable-via any allow-default
>  no ip redirects
>  no ip proxy-arp
>  xconnect x.y.z.56 71172104 encapsulation mpls
>
> Router2##sh run int gi 2/3
> Building configuration...
>
> Current configuration : 257 bytes
> !
> interface GigabitEthernet2/3
>  description -VC-71172104--
>  no ip address
>  ip verify unicast source reachable-via any
>  no ip redirects
>  no ip proxy-arp
>  speed 100
>  duplex full
>  xconnect x.y.z.40 71172104 encapsulation mpls
>
>
> Unfortunately I cannot bump up the mtu on WS-X6148-GE-TX (need the A
> version
> for that!), but this is the port where the xconnect is terminating, so I
> was
> under the impression that I wouldn't need jumbo frames support as the
> labels
> would just be  passed thru the TenG mpls enabled interfaces, isn't it? I
> verified that lowering the interface mtu of the client machines makes
> everything work again. Played with the mpls mtu command, but it does not
> seem to have any effect whatsoever.
> Oddly enough, I see giants increasing on Router1, but not on Router2. I
> assume these are the dot1q trunk packets, but then why I'm seeing the
> counter increasing only on one side? The customer says on his switch
> interfaces, the mtu is 1500 on both trunks.
> So do you think I really need to bump the blade to at least WS-X6148A-GE-TX
> for this config to work, or am I missing something else?
>
> Thanks!
> ]\/[arco
> --
> I'm Winston

[c-nsp] Erspan on 7600

[Martin Moens]

Hi list,

Does someone have experience with erspan on a 7600?
Is this loading the CPU (rsp720 / ws-x6748-ge-tx) or is it handled in
hardware?

Martin

___
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] LAM / Mobile IP in modern times

[cisconsp]

Not to side step the original question, but I see this kind of discussion
frequently. This is another example of where the network can be made to
solve a problem that it's best leaving up to a higher-level mechanism.

In this case, if you have multi-site fault tolerance requirements between N
datacenters, it's far simpler to not vmotion between them. Rather, replicate
the resource tier (database & storage), stand up the presentation and
business-logic tiers in multiple sites, and front-end the service with a
load balancer. Cisco actually makes a product, the Global Site Selector
(GSS) to handle this kind of scenario. By probing the load balancer at each
site for service health checks, and manipulating DNS replies, we can
guarantee that service requests only get sent to datacenters where the
service is healthy. We can completely side-step the problem is moving an IP
address by letting the services designed to handle this kind of thing work
their magic.

Now, I will be the first to admit that there are some cases where this
simply doesn't work well, legacy services that only support one instance and
no replication, etc. however for the majority of modern apps that fit a
tiered model (presentation, business-logic, resource), this is a far
simpler, faster, and less complex way to achieve maximum redundancy and DR
capability.

3



-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Alexander Clouter
Sent: Tuesday, August 10, 2010 6:53 AM
To: Lincoln Dale
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] LAM / Mobile IP in modern times

Hi,

* Lincoln Dale  [2010-08-10 20:46:53+1000]:
>
> >>> The only remaining question is why for it's money have VMWare not done

> >>> the trivial task of making OSPF part of their VMotion
malarkey...*sigh*
> >> 
> >> because its not /quite/ as simple as you suggest.
> >> 
> > The awkward part I see is host based (not service) L3 connectivity.  The

> > operating system would need work happily in a multihomed configuration 
> > and to understand what a dead gateway means.  This probably would not be

> > easy to pull off on a Windows based guest, but it should be quite doable

> > onwell *any* other OS :)
> 
> the premise of VM mobility is that the OS and apps being virtualised 
> are completely unaware that they have been virtualised.
>
> what this means in reality is that you can migrate a VM from one 
> physical host to another and there is no disruption to traffic flows. 
> there are no disruptions to any TCP connections to apps running on the 
> (virtualised) server.
>
...and there would not be as the *service* IP would remain present.  It 
is the service IP that is being advertised over OSPF, *not* the host 
IPs.  The idea is you assign multiple IP's to your hosts.

Sure this approach, instead puts the complication of migration into the 
multiple number of hosts (would not be a problem if VMware did the OSPF) 
rather than in the network.  The advantage is that you are now playing 
with a very familiary technology (OSPF/iBGP) where you can find many 
engineers who can understand what is going on.

> but in order for this trick to be pulled off, you need a common L2 
> domain.
> 
No you do not.

> if you're willing to remove that requirement and potentially have an 
> outage or disruption at the host or app level, or you're willing to do 
> whatever integration work is necessary to mitigate that, then i 
> believe its technically possible to have vMotion across L3.
> 
The disruption lasts only as long as your iBGP/OSPF takes to rejiggle 
surely?  Not much worse than ARP argubly.

> but note that not all apps will be supported.  nor all hosts.  and if 
> those apps/hosts are doing any form of network-based storage access 
> (NFS, CIFS, iSCSI et al), then bad things may well happen unless you 
> can quiesce the virtual host on a migration.
>
iSCSI can re-establish transparently the connection, NFS you can put 
into UDP mode as a quick fix.  CIFS, crime and punishment ;) If you want 
to maintain TCP state, that you add to your routing table that when 
communicating with ${STORAGE_SERVER} use a particular source IP, this 
is not tricky stuff.

Cheers

-- 
Alexander Clouter
.sigmonster says: Life is like a simile.
___
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] Problems with dot1q trunk over EoMPLS with WS-X6148-GE-TX

[Everton da Silva Marques]

On Tue, Aug 10, 2010 at 08:13:37AM -0400, Dan Voyer wrote:
> Yo, the WS-6148-GE-TX does not support "large frame". You need the WS-6748
> for large frame !

6148 does not support jumbo frames, 6148A does.

Everton
___
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] Bundling ports on different WS6704 linecards

[David Hughes]

On 09/08/2010, at 5:47 PM, Rin wrote:

> We are building a Core network of 3 7609 routers connecting as a 40Gbps
> ring. On each router we have 4 WS6704 linecards. Each router will be
> connected to other routers via 4 10G-links, these links will be configured
> as Port-Channel. 

The use of 6704 LC's may not be the best option due to their limited buffers.  
There are many discussions on this list relating to the capabilities of 6704 vs 
the 6708 for example.  The 6704 _may_ suit your requirements but it would be 
worth having a quick look at the other options (even if you only use every 
second port on the 6708's for example).


Thanks

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/

Re: [c-nsp] linux vpn client

[Deric Kwok]

yes. it works, thank you

but I have to type every time. How can I save configure?

ls it possible I can use the GUI to connect?

Thank you

On Mon, Aug 9, 2010 at 2:10 PM, Gabriel  wrote:
> vpnc
>
> On Aug 9, 2010 9:07 PM, "Deric Kwok"  wrote:
>
> Hi all
>
> Can you suggest the linux vpn client?
>
> eg: fedora, suse
>
> I also try the anyconnect. but don't know how to put the configure file
>
> When I use it in xwindow, it asks me to provide  "connect to " vpn gui
>
> But I type the ip address, it won't work
>
> Thank you
> ___
> cisco-nsp mailing list  cisco-...@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

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

Re: [c-nsp] ACL logging on n5k

[Arvind .cisconsp]

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCth28899

State:
New
Severity: Enhancement
Version: 4.2(1)N1(1)

On Tue, Aug 10, 2010 at 7:09 AM, Tassos Chatzithomaoglou  wrote:

> n5k(config-acl)# deny ip any any ?
> 
>  dscpMatch packets with given dscp value
>  fragments   Check non-initial fragments
>  precedence  Match packets with given precedence value
>
> n5k(config-acl)# deny ip any any log
> ^
> % Invalid ip address at '^' marker.
> n5k(config-acl)#
>
>
> "time-range" option is also not available.
>
> There must be something i'm missing...
>
> --
> Tassos
>
>
> Arie Vayner (avayner) wrote on 10/08/2010 13:50:
>
>  Seems to be in 4.1(3) too...
>> http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
>> /reference/rel_4_1/security_cmd_ref.html#wp1279114
>>
>> Strange...
>>
>> Arie
>>
>> -Original Message-
>> From: cisco-nsp-boun...@puck.nether.net
>> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
>> Chatzithomaoglou
>> Sent: Tuesday, August 10, 2010 13:35
>> To: cisco-nsp@puck.nether.net
>> Subject: Re: [c-nsp] ACL logging on n5k
>>
>> I'm using 4.1(3)N2(1) and the "log" option is not available.
>> Should i guess an upgrade is needed, although release notes do not
>> mention anything?
>>
>> --
>> Tassos
>>
>>
>> Arie Vayner (avayner) wrote on 10/08/2010 12:43:
>>
>>
>>> Tassos,
>>>
>>> Looking here:
>>>
>>>
>>>
>> http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
>>
>>
>>> /reference/rel_4_2_1_N2_1/security_cmd_ref.html#wp1279114
>>>
>>> I can see the 'log' option listed...
>>>
>>> Arie
>>>
>>> -Original Message-
>>> From: cisco-nsp-boun...@puck.nether.net
>>> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
>>> Chatzithomaoglou
>>> Sent: Monday, August 09, 2010 22:22
>>> To: cisco-nsp@puck.nether.net
>>> Subject: [c-nsp] ACL logging on n5k
>>>
>>> N5k datasheet says it's supported, but i couldn't find any other
>>> reference.
>>> Is it supported and if yes, how do you enable it?
>>>
>>> --
>>> Tassos
>>>
>>> ___
>>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>>
>>>
>>>
>> ___
>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Bundling ports on different WS6704 linecards

[Phil Mayers]

On 10/08/10 12:15, Rin wrote:

A friend of mine suggests that all linecards should have the same DFC (3C,
3CXL, 3B etc...), else the port channel might not work properly.


I don't see why (modulo the different QoS stuff I mentioned). We do port 
channels with one member on a 6716 and one on older 6704 without any 
apparent issues.



In our case, all of the linecards are DFC3B&  no service modules will be
used so I believe it should be ok.


You should be fine.
___
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] Problems with dot1q trunk over EoMPLS with WS-X6148-GE-TX

[Dan Voyer]

here it is:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/intrface.html#wpmkr1044296

have fun.
On Tue, Aug 10, 2010 at 8:13 AM, Dan Voyer  wrote:

> Yo, the WS-6148-GE-TX does not support "large frame". You need the WS-6748
> for large frame !
>
> And i believe you have a sup32, well that doesnt support large frame
> either, unless it's a sup32-10GE.
>
> Maybe you could use 1 port for each VLAN, that way you don't need the 4
> bytes header from 802.1Q
>
>
> - Sometimes I wish when people buy that WS-6148 line card Cisco make
> them sign "yes I agree to buy this line card that doesnt support large
> frame".
>
> dan
>   On Sun, Aug 8, 2010 at 8:05 AM, Fabien Dedenon  > wrote:
>
>>
>>  Hi,
>>
>> Le 08/08/2010 13:33, Gert Doering a écrit :
>>
>> Hi,
>>>
>>> in addition to what Arie said:
>>>
>>> On Sun, Aug 08, 2010 at 01:02:46PM +0200, Marco Matarazzo wrote:
>>>
 Router1#sh run int fa 2/32
 Building configuration...

 Current configuration : 245 bytes
 !
 interface FastEthernet2/32
  description -VC-71172104--
  no ip address
  ip verify unicast source reachable-via any allow-default
  no ip redirects
  no ip proxy-arp
  xconnect x.y.z.56 71172104 encapsulation mpls

>>> ... just put "mtu 1504" here, to take into account that a full-sized
>>> ethernet frame *plus* dot1q header is just bigger than without... :-)
>>>
>>> (Been there, cursed, found the answer)
>>>
>> Sorry Gert but WS-X6148-GE-TX by specification just won't permit this. mtu
>> config is event not permitted (SXIx).
>>(config)#interface gigabitEthernet 4/46
>>(config-if)#mtu 1504
>>% Invalid input detected at '^' marker.
>>
>>> gert
>>>
>> Cheers,
>>
>> Fabien
>>
>> ___
>> 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] Problems with dot1q trunk over EoMPLS with WS-X6148-GE-TX

[Dan Voyer]

Yo, the WS-6148-GE-TX does not support "large frame". You need the WS-6748
for large frame !

And i believe you have a sup32, well that doesnt support large frame either,
unless it's a sup32-10GE.

Maybe you could use 1 port for each VLAN, that way you don't need the 4
bytes header from 802.1Q


- Sometimes I wish when people buy that WS-6148 line card Cisco make
them sign "yes I agree to buy this line card that doesnt support large
frame".

dan
On Sun, Aug 8, 2010 at 8:05 AM, Fabien Dedenon wrote:

>
>  Hi,
>
> Le 08/08/2010 13:33, Gert Doering a écrit :
>
> Hi,
>>
>> in addition to what Arie said:
>>
>> On Sun, Aug 08, 2010 at 01:02:46PM +0200, Marco Matarazzo wrote:
>>
>>> Router1#sh run int fa 2/32
>>> Building configuration...
>>>
>>> Current configuration : 245 bytes
>>> !
>>> interface FastEthernet2/32
>>>  description -VC-71172104--
>>>  no ip address
>>>  ip verify unicast source reachable-via any allow-default
>>>  no ip redirects
>>>  no ip proxy-arp
>>>  xconnect x.y.z.56 71172104 encapsulation mpls
>>>
>> ... just put "mtu 1504" here, to take into account that a full-sized
>> ethernet frame *plus* dot1q header is just bigger than without... :-)
>>
>> (Been there, cursed, found the answer)
>>
> Sorry Gert but WS-X6148-GE-TX by specification just won't permit this. mtu
> config is event not permitted (SXIx).
>(config)#interface gigabitEthernet 4/46
>(config-if)#mtu 1504
>% Invalid input detected at '^' marker.
>
>> gert
>>
> Cheers,
>
> Fabien
>
> ___
> 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] LAM / Mobile IP in modern times

[Alexander Clouter]

Hi,

* David Freedman  [2010-08-10 12:01:16+0100]:
> 
> > i believe the common case is that vCenter today 'forces' all hosts in
> > a 'cluster' to be in a common L2 domain, although i read something
> > somewhere that said that it can be overruled.  i haven't found the
> > nerd knob to set that if there is such a thing. but even if there is
> > such a nerd knob, its caveat emptor.  you might not like the result.
> > :)
> 
> See, given that today the VMware virtual switch implements more edge
> features (esp more when you use the n1000v), I wonder why some form of
> fast converging L3 mobility + routing protocol doesn't feature more
> prominently here.
> 
> (Now starting to go off-topic)
> 
I see your 'off-topic' and raise you 'conspiracy' :)

If you can do L3 mobility with your existing equipment, why buy new 
equipment and licenses...

Cheers

-- 
Alexander Clouter
.sigmonster says: Read terms and conditions.
___
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] LAM / Mobile IP in modern times

[Alexander Clouter]

Hi,

* Lincoln Dale  [2010-08-10 20:46:53+1000]:
>
> >>> The only remaining question is why for it's money have VMWare not done 
> >>> the trivial task of making OSPF part of their VMotion malarkey...*sigh*
> >> 
> >> because its not /quite/ as simple as you suggest.
> >> 
> > The awkward part I see is host based (not service) L3 connectivity.  The 
> > operating system would need work happily in a multihomed configuration 
> > and to understand what a dead gateway means.  This probably would not be 
> > easy to pull off on a Windows based guest, but it should be quite doable 
> > onwell *any* other OS :)
> 
> the premise of VM mobility is that the OS and apps being virtualised 
> are completely unaware that they have been virtualised.
>
> what this means in reality is that you can migrate a VM from one 
> physical host to another and there is no disruption to traffic flows. 
> there are no disruptions to any TCP connections to apps running on the 
> (virtualised) server.
>
...and there would not be as the *service* IP would remain present.  It 
is the service IP that is being advertised over OSPF, *not* the host 
IPs.  The idea is you assign multiple IP's to your hosts.

Sure this approach, instead puts the complication of migration into the 
multiple number of hosts (would not be a problem if VMware did the OSPF) 
rather than in the network.  The advantage is that you are now playing 
with a very familiary technology (OSPF/iBGP) where you can find many 
engineers who can understand what is going on.

> but in order for this trick to be pulled off, you need a common L2 
> domain.
> 
No you do not.

> if you're willing to remove that requirement and potentially have an 
> outage or disruption at the host or app level, or you're willing to do 
> whatever integration work is necessary to mitigate that, then i 
> believe its technically possible to have vMotion across L3.
> 
The disruption lasts only as long as your iBGP/OSPF takes to rejiggle 
surely?  Not much worse than ARP argubly.

> but note that not all apps will be supported.  nor all hosts.  and if 
> those apps/hosts are doing any form of network-based storage access 
> (NFS, CIFS, iSCSI et al), then bad things may well happen unless you 
> can quiesce the virtual host on a migration.
>
iSCSI can re-establish transparently the connection, NFS you can put 
into UDP mode as a quick fix.  CIFS, crime and punishment ;) If you want 
to maintain TCP state, that you add to your routing table that when 
communicating with ${STORAGE_SERVER} use a particular source IP, this 
is not tricky stuff.

Cheers

-- 
Alexander Clouter
.sigmonster says: Life is like a simile.
___
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] Bundling ports on different WS6704 linecards

[Rin]

A friend of mine suggests that all linecards should have the same DFC (3C,
3CXL, 3B etc...), else the port channel might not work properly. 
In our case, all of the linecards are DFC3B & no service modules will be
used so I believe it should be ok. 

Thanks,

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ivan
Sent: Tuesday, August 10, 2010 3:02 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Bundling ports on different WS6704 linecards

On 9/Aug/2010 11:22 p.m., Phil Mayers wrote:
> On 09/08/10 08:47, Rin wrote:
>> Hi group,
>>
>>
>>
>> We are building a Core network of 3 7609 routers connecting as a 40Gbps
>> ring. On each router we have 4 WS6704 linecards. Each router will be
>> connected to other routers via 4 10G-links, these links will be
>> configured
>> as Port-Channel.
>>
>>
>>
>> Should we place each link of the port-channel on different linecard on
>> each
>> router or should we allocate all 4 links on the same linecard? Anyone has
>> any problem with configuring etherchannel for ports on different WS6704
>> linecards?
>
> We do that extensively. It works fine. It is better to have
> cross-linecard portchannels in general.
>
> HOWEVER - there are a couple of caveats to be aware of. One is if you've
> got different linecards with different QoS queuing, you will need:
>
> int PoX
> no mls qos channel-consistency
>
> Second is that there are some issues with cross-linecard portchannels if
> you have service modules (ACE, FWSM, WiSM) in the chassis. I can't
> remember the details or find the link at the moment.
> ___
> 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/

I was bitten by the FWSM and DEC.  The link that was referred to is
probably http://www.cisco.com/en/US/ts/fn/610/fn61935.html

Field Notice: FN - 61935 - Catalyst 6500 Series and 7600 Series Service
Module Incompatibility With Distributed EtherChannel and Packet
Re-Circulation

"Problem Description
When the listed service modules transmit packets to VLANs also used with
Distributed EtherChannel (DEC), those packets may be dropped and lost.

Background

The listed service modules do not support packet re-circulation. Packet
re-circulation is a specific means to forward packets internal to the
chassis between modules. When the service module attempts to forward a
packet onto such a VLAN with packet-recirculation enabled, it may fail and
the packet might be lost. When packet re-circulation is not enabled on the
destination VLAN, even if DEC is present, this problem will not be
encountered."

We ended up getting rid of the DEC and using plain EC and "no monitor
session servicemodule" as the span sessions were required for other
purposes.
(http://www.cisco.com/en/US/products/hw/modules/ps2706/products_qanda_item09
186a00801e9e26.shtml#q44)

Cheers

Ivan
___
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] ACL logging on n5k

[Tassos Chatzithomaoglou]

n5k(config-acl)# deny ip any any ?

  dscpMatch packets with given dscp value
  fragments   Check non-initial fragments
  precedence  Match packets with given precedence value

n5k(config-acl)# deny ip any any log
 ^
% Invalid ip address at '^' marker.
n5k(config-acl)#


"time-range" option is also not available.

There must be something i'm missing...

--
Tassos


Arie Vayner (avayner) wrote on 10/08/2010 13:50:

Seems to be in 4.1(3) too...
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
/reference/rel_4_1/security_cmd_ref.html#wp1279114

Strange...

Arie

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
Chatzithomaoglou
Sent: Tuesday, August 10, 2010 13:35
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ACL logging on n5k

I'm using 4.1(3)N2(1) and the "log" option is not available.
Should i guess an upgrade is needed, although release notes do not
mention anything?

--
Tassos


Arie Vayner (avayner) wrote on 10/08/2010 12:43:
   

Tassos,

Looking here:

 

http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
   

/reference/rel_4_2_1_N2_1/security_cmd_ref.html#wp1279114

I can see the 'log' option listed...

Arie

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
Chatzithomaoglou
Sent: Monday, August 09, 2010 22:22
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ACL logging on n5k

N5k datasheet says it's supported, but i couldn't find any other
reference.
Is it supported and if yes, how do you enable it?

--
Tassos

___
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] LAM / Mobile IP in modern times

[David Freedman]

> i believe the common case is that vCenter today 'forces' all hosts in
> a 'cluster' to be in a common L2 domain, although i read something
> somewhere that said that it can be overruled.  i haven't found the
> nerd knob to set that if there is such a thing. but even if there is
> such a nerd knob, its caveat emptor.  you might not like the result.
> :)

See, given that today the VMware virtual switch implements more edge
features (esp more when you use the n1000v), I wonder why some form of
fast converging L3 mobility + routing protocol doesn't feature more
prominently here.

(Now starting to go off-topic)


> 
> 
> cheers,
> 
> lincoln.
> 
> 
> ___ 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/
> 


-- 


David Freedman
Group Network Engineering
Claranet Group
___
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] ACL logging on n5k

[Arie Vayner (avayner)]

Seems to be in 4.1(3) too...
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
/reference/rel_4_1/security_cmd_ref.html#wp1279114

Strange...

Arie

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
Chatzithomaoglou
Sent: Tuesday, August 10, 2010 13:35
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ACL logging on n5k

I'm using 4.1(3)N2(1) and the "log" option is not available.
Should i guess an upgrade is needed, although release notes do not 
mention anything?

--
Tassos


Arie Vayner (avayner) wrote on 10/08/2010 12:43:
> Tassos,
>
> Looking here:
>
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
> /reference/rel_4_2_1_N2_1/security_cmd_ref.html#wp1279114
>
> I can see the 'log' option listed...
>
> Arie
>
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
> Chatzithomaoglou
> Sent: Monday, August 09, 2010 22:22
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] ACL logging on n5k
>
> N5k datasheet says it's supported, but i couldn't find any other
> reference.
> Is it supported and if yes, how do you enable it?
>
> --
> Tassos
>
> ___
> 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] LAM / Mobile IP in modern times

[Alexander Clouter]

Hi,

* Lincoln Dale  [2010-08-10 19:56:21+1000]:
>
> On 10/08/2010, at 6:35 PM, Alexander Clouter wrote:
>
> > I was toying with the idea internally of putting a tiny OSPF router into 
> > our VM cluster to drag IP's from one side of our organisation to the 
> > other.  
> 
> reality is that many hosts and applications require and expect layer 2 
> connectivity for things other than IP unicast when they think they are 
> in the same IP subnet another host.
>
Thought it was obvious I was talking L3 here, maybe not.  If you are 
coupling hosts at L2 then you would be nuts to not move them as a group 
surely?  I probably was not clear when talking about the 'dead zone' 
VLAN at either site, there just would be no router on that VLAN.  An 
amendment is that you have a dedicated locally scoped same-VLAN-ID VLAN 
for just those nodes that need L2 lovin' to work on, have another pair 
of VLAN's for the L3.
 
> > The only remaining question is why for it's money have VMWare not done 
> > the trivial task of making OSPF part of their VMotion malarkey...*sigh*
> 
> because its not /quite/ as simple as you suggest.
> 
The awkward part I see is host based (not service) L3 connectivity.  The 
operating system would need work happily in a multihomed configuration 
and to understand what a dead gateway means.  This probably would not be 
easy to pull off on a Windows based guest, but it should be quite doable 
onwell *any* other OS :)

As a mentioned before though, unfortunately I never got this beyond the 
planning stage due to the 'quality' of the VMware consultants we hired :-/

Cheers

-- 
Alexander Clouter
.sigmonster says: Minnie Mouse is a slow maze learner.
___
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] LAM / Mobile IP in modern times

[Lincoln Dale]

g'day,
> 
>>> The only remaining question is why for it's money have VMWare not done 
>>> the trivial task of making OSPF part of their VMotion malarkey...*sigh*
>> 
>> because its not /quite/ as simple as you suggest.
>> 
> The awkward part I see is host based (not service) L3 connectivity.  The 
> operating system would need work happily in a multihomed configuration 
> and to understand what a dead gateway means.  This probably would not be 
> easy to pull off on a Windows based guest, but it should be quite doable 
> onwell *any* other OS :)

the premise of VM mobility is that the OS and apps being virtualised are 
completely unaware that they have been virtualised.

what this means in reality is that you can migrate a VM from one physical host 
to another and there is no disruption to traffic flows.
there are no disruptions to any TCP connections to apps running on the 
(virtualised) server.

but in order for this trick to be pulled off, you need a common L2 domain.

if you're willing to remove that requirement and potentially have an outage or 
disruption at the host or app level, or you're willing to do whatever 
integration work is necessary to mitigate that, then i believe its technically 
possible to have vMotion across L3.

but note that not all apps will be supported.  nor all hosts.  and if those 
apps/hosts are doing any form of network-based storage access (NFS, CIFS, iSCSI 
et al), then bad things may well happen unless you can quiesce the virtual host 
on a migration.


> 
> As a mentioned before though, unfortunately I never got this beyond the 
> planning stage due to the 'quality' of the VMware consultants we hired :-/

i believe the common case is that vCenter today 'forces' all hosts in a 
'cluster' to be in a common L2 domain, although i read something somewhere that 
said that it can be overruled.  i haven't found the nerd knob to set that if 
there is such a thing.
but even if there is such a nerd knob, its caveat emptor.  you might not like 
the result. :)


cheers,

lincoln.


___
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] ACL logging on n5k

[Tassos Chatzithomaoglou]

I'm using 4.1(3)N2(1) and the "log" option is not available.
Should i guess an upgrade is needed, although release notes do not 
mention anything?


--
Tassos


Arie Vayner (avayner) wrote on 10/08/2010 12:43:

Tassos,

Looking here:
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
/reference/rel_4_2_1_N2_1/security_cmd_ref.html#wp1279114

I can see the 'log' option listed...

Arie

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
Chatzithomaoglou
Sent: Monday, August 09, 2010 22:22
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ACL logging on n5k

N5k datasheet says it's supported, but i couldn't find any other
reference.
Is it supported and if yes, how do you enable it?

--
Tassos

___
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] LAM / Mobile IP in modern times

[Lincoln Dale]

On 10/08/2010, at 6:35 PM, Alexander Clouter wrote:
> I was toying with the idea internally of putting a tiny OSPF router into 
> our VM cluster to drag IP's from one side of our organisation to the 
> other.  

reality is that many hosts and applications require and expect layer 2 
connectivity for things other than IP unicast when they think they are in the 
same IP subnet another host.

your suggested approach would cause those applications to fail.
whether the apps are doing the right or wrong this is somewhat academic.  "they 
work today" is the mantra i hear.

i can show you any number of RFC-breaking apps. :)

> That's how I would do things.

sounds like a nice exercise in ensuring your continued employment. :)


> The only remaining question is why for it's money have VMWare not done 
> the trivial task of making OSPF part of their VMotion malarkey...*sigh*

because its not /quite/ as simple as you suggest.


cheers,

lincoln.


___
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] LAM / Mobile IP in modern times

[Lincoln Dale]

[i had replied to David off list but it seems his reply to me was bcc'd here.  
so to keep things relevant i'm posting the reply here too]


On 10/08/2010, at 6:53 PM, David Freedman wrote:

> I should have mentioned that my target trains are 12.2SX and 12.2SR :)

6500/7600 are capable of MPLS/VPLS/EoMPLS/EoMPLSoGRE i believe, so certainly 
you have some mechanisms available to you for transporting L2 between your 
physical sites across your infrastructure, be it over IP or MPLS as the 
underlying transport.

>> 1. OTV 
>> 
>> 2. EoMPLSoGRE 
>> > c11_493718.pdf>
> 
> Great, but both layer 2 solutions and both suffering from the same l3
> symmetry issue. 

correct, these are technologies around how you make a single L2 subnet 
available at multiple location(s) when they are not necessarily L2 connected.

> This is an MPLS network and as such the VPLS sledgehammer could be
> brandished, I'm just trying to avoid it.

a wise move (i think) - but since you already have a MPLS network, there is no 
reason why you should not perhaps use it for a L2 transport, e.g. EoMPLS (e.g. 
xconnect), A-VPLS or VPLS.

again - this gets you the span-L2-betwen sites -- but to acheve the 'optimal 
L3->L2' you still need a mechanism to achieve that.

>> you have a few options.
>> 1. deaggregate / announce host routes (may work ok for an enterprise, less so
>> for other environments)
> 
> Don't see this as being a problem in a well managed SP network.

there ya go then.  do that.  you mentioned in email that this was for vMotion, 
you can have a 'script' run on a vMotion event, you could have that trigger 
some backend system to advertise a host route.

i would not necessarily recommend this approach.  it only really works if its 
you guys that control the "hosts".  if this is a 3rd party then caveat emptor 
having all your routes deaggregated. :)

>> 2. announce the server subnet out both/multiple locations with same metric,
>> return traffic will arrive at closest site or loadbalance across them with
>> ECMP.
> 
> Similar problems as with layer 2, return traffic has to come back to a deagg
> of some sort or be bridged across to where it needs to go somehow

my experience is that most folks have a LOT of bandwidth between their data 
centers, less so to the internet or branch offices if in an enterprise 
environment.
so some traffic statistically arriving in the "wrong" physical data center 
generally is not an issue.

if it is, then your solutions are: (1) deaggregate, (2) LISP

>> since they probably aren't palatable to you, we also have another way on the
>> way.
>> 
>> 3. LISP. 
> 
> LISP/HIP is great, but quite far from production use, especially in this
> scenario (but I have been following your LISP efforts with great interest)
> 
>> 
>> 
>>> I personally think LAM and
>>> sufficiently convergence tuned network should be almost if not as good.
>> 
>> LAM is for unicast traffic only and IP unicast traffic to be precise.  there
>> are many protocols / use-cases where that is not sufficient.
>> i think its widely acknowledged that it doesn't really scale.
> 
> Disagree, we are only talking about host route deaggregation for hosts which
> need to migrate for some reason or another, it doesn't appear to be a
> complicated or dangerous thing to do providing active number of deaggregates
> is managed, granted point about the multicast but don't think it will hamper
> the product much (inter-datacenter multicast isn't a problem anyway)

thing about LAM is its intended for "IP traffic" and "unicast IP" at that.

once you have things like hosts and vMotion hapenning you really don't have 
control over what the hosts and apps themselves running on these virtual 
servers are doing.
my experience is that things that you THINK don't require multicast often does. 
 and often hosts and apps that expect L2 connectivity also have requirements 
for non-IP traffic too.
i don't think LAM will accomodate either scenario as it was not intended to, 
and predates a lot of the virtual-machine-mobility brave new world.

> 
> I note from 
> http://www.cisco.com/en/US/docs/ios/ipmobility/command/reference/imo_01.html
> it seems to have made it into XE, quite why this was chosen (and not SX/SR)
> is beyond me!

probably because ASR1K is targeted primarily where things like the 7200 router 
workhorse was traditionally used.

just for the same reasons that things like Nexus 7000 don't have features that 
cause the box to drop to software forwarding, i'd say that LAM on 6500/7600 
fits the same category.
or maybe it is there and just not talked about, because its not a wise thing to 
do.


cheers,

lincoln.

> 
> 
> Appreciate the advice.
> 
> 
> Dave.
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://p

Re: [c-nsp] ACL logging on n5k

[Arie Vayner (avayner)]

Tassos,

Looking here:
http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/command
/reference/rel_4_2_1_N2_1/security_cmd_ref.html#wp1279114

I can see the 'log' option listed...

Arie

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos
Chatzithomaoglou
Sent: Monday, August 09, 2010 22:22
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ACL logging on n5k

N5k datasheet says it's supported, but i couldn't find any other
reference.
Is it supported and if yes, how do you enable it?

--
Tassos

___
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] LAM / Mobile IP in modern times

[Alexander Clouter]

David Freedman  wrote:
>
> Had the idea of testing LAM to support an application without resorting to
> inter-datacenter bridging(*) (Vmotion in this case) ,
> 
> Astonished to find the documentation old and out of date, coupled with a
> lack of vrf support (no "redistribute mobile" in the VRF BGP context) ,
> 
> Can't seem to find anything suggesting a feature which could quite easily be
> a superb alternative to bridging is even remotely vrf aware.
> 
> Any advice/pointers appreciated.
> 
I was toying with the idea internally of putting a tiny OSPF router into 
our VM cluster to drag IP's from one side of our organisation to the 
other.  

I then found out that our consultants had decided to deploy for us a two 
site with two node configuration where A|B where on one site, C|D on the 
other...but you could not do any (A|B)<->(C|D) migration *sigh* :-/

You could actually put the OSPF daemon on the UNIX guests themselves but 
for Windows guests, you used to be able to use OSPF with Windows, but 
apparently (news to me) OSPF is not used much in the industry according 
to Microsoft I guess you could use RIP.

I'm thinking of OSPF across two subnets on a trunk link to your guest.  
On one VM node one of the VLAN's goes to no where so there are no OSPF 
(or RIP, yay) neighbours, on the other, the other VLAN is the blackhole.  
The guest then advertises it's 'service' IP to it's OSPF neighbours and 
things should work.

That's how I would do things.  No silly over-engineered datacenter 
bridging technologies, no over priced licencing needing to be forked out 
for, etc etc.  Of course that's with OSPF on a 'small' scale, but I 
guess you could feed that into a iBGP advertisement.

The only remaining question is why for it's money have VMWare not done 
the trivial task of making OSPF part of their VMotion malarkey...*sigh*

Cheers

-- 
Alexander Clouter
.sigmonster says: An avocado-tone refrigerator would look good on your resume.

___
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] LAM / Mobile IP in modern times

[David Freedman]

I should have mentioned that my target trains are 12.2SX and 12.2SR :)


> 
> 1. OTV 
> 
> 2. EoMPLSoGRE 
>  c11_493718.pdf>


Great, but both layer 2 solutions and both suffering from the same l3
symmetry issue. 

This is an MPLS network and as such the VPLS sledgehammer could be
brandished, I'm just trying to avoid it.


> you have a few options.
> 1. deaggregate / announce host routes (may work ok for an enterprise, less so
> for other environments)

Don't see this as being a problem in a well managed SP network.


> 2. announce the server subnet out both/multiple locations with same metric,
> return traffic will arrive at closest site or loadbalance across them with
> ECMP.

Similar problems as with layer 2, return traffic has to come back to a deagg
of some sort or be bridged across to where it needs to go somehow

> 
> since they probably aren't palatable to you, we also have another way on the
> way.
> 
> 3. LISP. 

LISP/HIP is great, but quite far from production use, especially in this
scenario (but I have been following your LISP efforts with great interest)

> 
> 
>> I personally think LAM and
>> sufficiently convergence tuned network should be almost if not as good.
> 
> LAM is for unicast traffic only and IP unicast traffic to be precise.  there
> are many protocols / use-cases where that is not sufficient.
> i think its widely acknowledged that it doesn't really scale.

Disagree, we are only talking about host route deaggregation for hosts which
need to migrate for some reason or another, it doesn't appear to be a
complicated or dangerous thing to do providing active number of deaggregates
is managed, granted point about the multicast but don't think it will hamper
the product much (inter-datacenter multicast isn't a problem anyway)

I note from 
http://www.cisco.com/en/US/docs/ios/ipmobility/command/reference/imo_01.html
it seems to have made it into XE, quite why this was chosen (and not SX/SR)
is beyond me!


Appreciate the advice.


Dave.

___
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] LAM / Mobile IP in modern times

[Lincoln Dale]

On 10/08/2010, at 5:43 PM, David Freedman wrote:
> Can't seem to find anything suggesting a feature which could quite easily be
> a superb alternative to bridging is even remotely vrf aware.
> 
> Any advice/pointers appreciated.

1. OTV 

2. EoMPLSoGRE 


the former is where we (cisco) have put a lot of effort when it comes to 
solving real world issues for enterprise data centers.
there is a flash demo on the above url that shows details of how it works.  the 
configuration is incredibly straight forward and removes a lot of the pitfalls 
of alternative approaches.


> http://blogs.cisco.com/datacenter/comments/cisco_and_vmware_validated_archit
> ecture_for_long_distance_vmotion/
> 
> This is a terrible thing IMHO as you are still left to pick up the pieces as
> to who owns the subnet for routing purposes,

you have a few options.
1. deaggregate / announce host routes (may work ok for an enterprise, less so 
for other environments)
2. announce the server subnet out both/multiple locations with same metric, 
return traffic will arrive at closest site or loadbalance across them with ECMP.

since they probably aren't palatable to you, we also have another way on the 
way.

3. LISP. 


> I personally think LAM and
> sufficiently convergence tuned network should be almost if not as good.

LAM is for unicast traffic only and IP unicast traffic to be precise.  there 
are many protocols / use-cases where that is not sufficient.
i think its widely acknowledged that it doesn't really scale.


cheers,

lincoln.


___
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] LAM / Mobile IP in modern times

[David Freedman]

Had the idea of testing LAM to support an application without resorting to
inter-datacenter bridging(*) (Vmotion in this case) ,

Astonished to find the documentation old and out of date, coupled with a
lack of vrf support (no "redistribute mobile" in the VRF BGP context) ,

Can't seem to find anything suggesting a feature which could quite easily be
a superb alternative to bridging is even remotely vrf aware.

Any advice/pointers appreciated.


* 
http://blogs.cisco.com/datacenter/comments/cisco_and_vmware_validated_archit
ecture_for_long_distance_vmotion/

This is a terrible thing IMHO as you are still left to pick up the pieces as
to who owns the subnet for routing purposes, I personally think LAM and
sufficiently convergence tuned network should be almost if not as good.

-- 

David Freedman
Claranet 
http://www.clara.net

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