Re: [c-nsp] Mysterious tunnel interfaces

[Tassos Chatzithomaoglou]

"sh ip pim tunnel" might give you more info.
In later releases i have seen two tunnels (pim encap/decap) created 
automatically.


--
Tassos

Ivan wrote on 12/08/2010 07:22:

I was working on a ISR 1941 with 15.0(1)M2.  I am running DMVPN on it
and using one tunnel interface.  (Tunnel 1).  No other tunnel
interfaces are configured on the router.  However when I do "show int
summary" I get this;

#sh int summary

  *: interface is up
  IHQ: pkts in input hold queue IQD: pkts dropped from input queue
  OHQ: pkts in output hold queueOQD: pkts dropped from output queue
  RXBS: rx rate (bits/sec)  RXPS: rx rate (pkts/sec)
  TXBS: tx rate (bits/sec)  TXPS: tx rate (pkts/sec)
  TRTL: throttle count

   Interface  IHQ   IQD  OHQ   OQD  RXBS RXPS  TXBS TXPS TRTL

* GigabitEthernet0/0   0 00 0  60005  600050
   GigabitEthernet0/1   0 00 0 00 000
* Serial0/0/0  0 00 0  30003  200020
   NVI0 0 00 0 00 000
* Tunnel0  0 00 0 00 000
* Tunnel1  0 0010  10002  100020
* Tunnel2  0 00 0 00 000
* Tunnel3  0 00 0 00 000

I thought may be something got left behind while I was monkeying
around in it so I reloaded the router and the tunnel 0,2,3 are still
there and it says it's up.   None of those interfaces are in the
startup or running-config.

What is going on here?  My other routers with similar config on a 1841
with 12.4(15)T* doesn't have this issue.  It doesn't seem to be
affecting the routing of traffic but it's really bothering me.

-Jay
 

I have seen similar on ASRs.  From memory I think there were some of the
mystery tunnels and then quite a few more after enabling multicast..
Would be great to see an explaination though.

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] Mysterious tunnel interfaces

[Ivan]

> I was working on a ISR 1941 with 15.0(1)M2.  I am running DMVPN on it
> and using one tunnel interface.  (Tunnel 1).  No other tunnel
> interfaces are configured on the router.  However when I do "show int
> summary" I get this;
>
> #sh int summary
>
>  *: interface is up
>  IHQ: pkts in input hold queue IQD: pkts dropped from input queue
>  OHQ: pkts in output hold queueOQD: pkts dropped from output queue
>  RXBS: rx rate (bits/sec)  RXPS: rx rate (pkts/sec)
>  TXBS: tx rate (bits/sec)  TXPS: tx rate (pkts/sec)
>  TRTL: throttle count
>
>   Interface  IHQ   IQD  OHQ   OQD  RXBS RXPS  TXBS TXPS TRTL
> 
> * GigabitEthernet0/0   0 00 0  60005  600050
>   GigabitEthernet0/1   0 00 0 00 000
> * Serial0/0/0  0 00 0  30003  200020
>   NVI0 0 00 0 00 000
> * Tunnel0  0 00 0 00 000
> * Tunnel1  0 0010  10002  100020
> * Tunnel2  0 00 0 00 000
> * Tunnel3  0 00 0 00 000
>
> I thought may be something got left behind while I was monkeying
> around in it so I reloaded the router and the tunnel 0,2,3 are still
> there and it says it's up.   None of those interfaces are in the
> startup or running-config.
>
> What is going on here?  My other routers with similar config on a 1841
> with 12.4(15)T* doesn't have this issue.  It doesn't seem to be
> affecting the routing of traffic but it's really bothering me.
>
> -Jay

I have seen similar on ASRs.  From memory I think there were some of the
mystery tunnels and then quite a few more after enabling multicast.. 
Would be great to see an explaination though.

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] SXI4a (Was: 7606 config issue !!!)

[Jared Mauch]

We have identified two distinct memory leaks that cause the dead pool to 
increase over time in our environment. One of them appears when prefix lists 
are updated. Still trying to isolate the other. 

Jared Mauch

On Aug 11, 2010, at 5:53 PM, David Hughes  wrote:

> 
> On 11/08/2010, at 8:03 AM, Ge Moua wrote:
> 
>> 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.
> 
> Thanks for the feedback.  Actually I'm interested in Cat6K / Sup720.  This 
> thread went a bit off-topic from memory and ended up talking about a couple 
> of SXI related issues.
> 
> 
> 
> Thanks
> 
> David
> ...
> 
> 
> 
> 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 ?
> 
> ___
> 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] Mysterious tunnel interfaces

[Jay Nakamura]

I was working on a ISR 1941 with 15.0(1)M2.  I am running DMVPN on it
and using one tunnel interface.  (Tunnel 1).  No other tunnel
interfaces are configured on the router.  However when I do "show int
summary" I get this;

#sh int summary

 *: interface is up
 IHQ: pkts in input hold queue IQD: pkts dropped from input queue
 OHQ: pkts in output hold queueOQD: pkts dropped from output queue
 RXBS: rx rate (bits/sec)  RXPS: rx rate (pkts/sec)
 TXBS: tx rate (bits/sec)  TXPS: tx rate (pkts/sec)
 TRTL: throttle count

  Interface  IHQ   IQD  OHQ   OQD  RXBS RXPS  TXBS TXPS TRTL

* GigabitEthernet0/0   0 00 0  60005  600050
  GigabitEthernet0/1   0 00 0 00 000
* Serial0/0/0  0 00 0  30003  200020
  NVI0 0 00 0 00 000
* Tunnel0  0 00 0 00 000
* Tunnel1  0 0010  10002  100020
* Tunnel2  0 00 0 00 000
* Tunnel3  0 00 0 00 000

I thought may be something got left behind while I was monkeying
around in it so I reloaded the router and the tunnel 0,2,3 are still
there and it says it's up.   None of those interfaces are in the
startup or running-config.

What is going on here?  My other routers with similar config on a 1841
with 12.4(15)T* doesn't have this issue.  It doesn't seem to be
affecting the routing of traffic but it's really bothering me.

-Jay
___
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 7000 MSDP peering policy woes

[Christopher.Marget]

> while there are clueful folks on this list that know N7K and NX-OS, i
> don't think cisco-nsp is an appropriate replacement for talking to the
> TAC.

Perhaps not.  I appreciate your reply, and hope my query isn't widely 
considered as inappropriate.

> but regardless, i _think_ what you're likely happening is that the
> route-map policy is in fact NOT being applied, because of the presence
> of 'deny' statements in the ACL.

No deny statements are allowed in the ACL in this context?  I'll need some time 
to absorb this :-)

My intended configuration does not include a deny, still filters the traffic.  
Maybe I have my policy logic (or perhaps my head) upside-down?

> for example, what do you expect the outcome to be of a "route-map
> (whatever) deny" that uses an IP access-list that also has 'deny ip' on
> it?
> a deny of a deny is a what? :)

I expected the route-map to move beyond sequence 5 (deny nothing), and then 
evaluate sequence 10.

Of course, I concede that the "deny nothing" business is not useful, I got 
there by trying to build a simple illustration of what I was seeing.  The real 
ACL does not include a deny, other than the implicit one (I assume it is still 
there), and I'm still not seeing the route map get evaluated past sequence 10:

2010 Aug 12 02:07:30.387585 msdp: [7070] (default-base) Originating SA message 
with data for (10.27.147.5, 239.192.1.1), IP length: 1344
2010 Aug 12 02:07:30.387804 msdp: librpm [7070] == RPM Evaluation 
starting for policy MSDP-INTRA-BUILDING-POLICY ==
2010 Aug 12 02:07:30.387824 msdp: librpm [7070]  Evaluating (rmap 
MSDP-INTRA-BUILDING-POLICY - seq 10 - cmd RPM_MATCH_IP_ADDR_ACL) 
2010 Aug 12 02:07:30.387841 msdp: librpm [7070]  Evaluation result (seq 10 
- cmd RPM_MATCH_IP_ADDR_ACL):RPM_MATCH_IGNORE 
2010 Aug 12 02:07:30.387857 msdp: librpm [7070] EVAL context->flag 0x005b
2010 Aug 12 02:07:30.387875 msdp: librpm [7070] Policy eval. returning action 
handle 0x
2010 Aug 12 02:07:30.387890 msdp: librpm [7070] == RPM Evaluation 
result RPM_MATCH_REJECT ==
2010 Aug 12 02:07:30.387919 msdp: [7070] (default-base) Entire outgoing SA to 
peer 10.255.255.228 filtered

N7K-A# undebug all
N7K-A# sho route-map MSDP-INTRA-BUILDING-POLICY
route-map MSDP-INTRA-BUILDING-POLICY, deny, sequence 10
  Match clauses:
ip address (access-lists): MSDP-FORBIDDEN-MC-GROUPS
  Set clauses:
route-map MSDP-INTRA-BUILDING-POLICY, permit, sequence 20
  Match clauses:
ip address (access-lists): RFC-2365-GLOBAL-GROUPS
  Set clauses:
N7K-A# sho ip access-lists MSDP-FORBIDDEN-MC-GROUPS

IP access list MSDP-FORBIDDEN-MC-GROUPS
10 permit ip any 224.0.0.0/24
20 permit ip any 239.255.0.0/16
N7K-A#

The ACL matched by sequence 20 doesn't have any deny either.


> historically a route-map with a 'deny' ACL invoked a "logical OR"
> operation which is often not actually what people desired or wanted.
> for that reason we don't currently support "IP access-list deny" when
> being matched by a route-map.
> 
> if this was PBR or VACL then when you tried to apply the VACL/PBR to an
> interface, you should get an error message.  maybe you aren't seeing
> the same thing for MSDP.

It MSDP did not complain (nor did the debugs) when I applied the policy with 
ACL deny.

Thanks Lincoln.  I will be talking to TAC in the morning :-)

/chris

___
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 7000 MSDP peering policy woes

[Lincoln Dale]

g'day,

On 12/08/2010, at 8:26 AM,  wrote:
> I'm trying to implement PBR-filtering of MSDP messages from a Nexus 7000 
> running 5.0(2a), and I'm starting to think that the route-map is being 
> interpreted wrong.
> 
> The relevant parts of the configuration are:
> 
> feature msdp
> feature pbr
> ip msdp originator-id loopback0
> ip msdp peer W.X.Y.Z connect-source loopback0
> ip msdp sa-policy W.X.Y.Z MSDP-INTRA-BUILDING-POLICY in
> ip msdp sa-policy W.X.Y.Z MSDP-INTRA-BUILDING-POLICY out
[..]

while there are clueful folks on this list that know N7K and NX-OS, i don't 
think cisco-nsp is an appropriate replacement for talking to the TAC.

but regardless, i _think_ what you're likely happening is that the route-map 
policy is in fact NOT being applied, because of the presence of 'deny' 
statements in the ACL.

for example, what do you expect the outcome to be of a "route-map (whatever) 
deny" that uses an IP access-list that also has 'deny ip' on it?
a deny of a deny is a what? :)

historically a route-map with a 'deny' ACL invoked a "logical OR" operation 
which is often not actually what people desired or wanted.
for that reason we don't currently support "IP access-list deny" when being 
matched by a route-map.

if this was PBR or VACL then when you tried to apply the VACL/PBR to an 
interface, you should get an error message.  maybe you aren't seeing the same 
thing for MSDP.


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] Nexus 7000 MSDP peering policy woes

[Christopher.Marget]

Huh.  The copy of this note in my outbox is formatted nicely, but the one 
forwarded back to me by the list is a mess.
I'm not sure what happened to the newlines.  Thank you, Outlook.  Trying again, 
sorry for the noise.


I'm trying to implement PBR-filtering of MSDP messages from a Nexus 7000 
running 5.0(2a), and I'm starting to think that the route-map is being 
interpreted wrong.

The relevant parts of the configuration are:

feature msdp
feature pbr
ip msdp originator-id loopback0
ip msdp peer W.X.Y.Z connect-source loopback0
ip msdp sa-policy W.X.Y.Z MSDP-INTRA-BUILDING-POLICY in
ip msdp sa-policy W.X.Y.Z MSDP-INTRA-BUILDING-POLICY out

ip access-list PERMIT-IP-ANY-ANY
 permit ip any any

route-map MSDP-INTRA-BUILDING-POLICY deny 10
  match ip address PERMIT-IP-ANY-ANY
route-map MSDP-INTRA-BUILDING-POLICY deny 20
  match ip address MSDP-FORBIDDEN-MC-GROUPS
route-map MSDP-INTRA-BUILDING-POLICY permit 30
  match ip address RFC-2365-GLOBAL-GROUPS
route-map MSDP-INTER-ENTERPRISE-POLICY deny 40

Next, I enable 'debug ip msdp' and 'debug ip msdp policy', and switch on a 
multicast source.  The debug output indicates that only the first line (deny 
10) of the route-map is being evaluated:

2010 Aug 12 00:02:40.689445 msdp: librpm [7070] == RPM Evaluation 
starting for policy MSDP-INTRA-BUILDING-POLICY ==
2010 Aug 12 00:02:40.689482 msdp: librpm [7070]  Evaluating (rmap 
MSDP-INTRA-BUILDING-POLICY - seq 10 - cmd RPM_MATCH_IP_ADDR_ACL) 
2010 Aug 12 00:02:40.689512 msdp: librpm [7070]  Evaluation result (seq 10 
- cmd RPM_MATCH_IP_ADDR_ACL):RPM_MATCH_IGNORE 
2010 Aug 12 00:02:40.689562 msdp: librpm [7070] EVAL context->flag 0x001b
2010 Aug 12 00:02:40.689668 msdp: librpm [7070] Policy eval. returning action 
handle 0x
2010 Aug 12 00:02:40.689698 msdp: librpm [7070] == RPM Evaluation 
result RPM_MATCH_REJECT ==
2010 Aug 12 00:02:40.689743 msdp: [7070] (default-base) Entire outgoing SA to 
peer W.X.Y.Z filtered

So far, so good.  'deny 10' matches everything, so the next line of the 
route-map didn't get evaluated, and the announcement for this new multicast 
source is filtered.

Now I'll insert an earlier 'deny' line into the route-map, this time with an 
ACL that matches nothing:

ip access-list DENY-IP-ANY-ANY
 deny ip any any

route-map MSDP-INTRA-BUILDING-POLICY deny 5
  match ip address DENY-IP-ANY-ANY

Clear all of the mroutes, and fire the source back up.  Debug says:

2010 Aug 12 00:40:53.064084 msdp: librpm [7070] == RPM Evaluation 
starting for policy MSDP-INTRA-BUILDING-POLICY ==
2010 Aug 12 00:40:53.064121 msdp: librpm [7070]  Evaluating (rmap 
MSDP-INTRA-BUILDING-POLICY - seq 5 - cmd RPM_MATCH_IP_ADDR_ACL) 
2010 Aug 12 00:40:53.064152 msdp: librpm [7070]  Evaluation result (seq 5 - 
cmd RPM_MATCH_IP_ADDR_ACL):RPM_MATCH_IGNORE 
2010 Aug 12 00:40:53.064181 msdp: librpm [7070] EVAL context->flag 0x005b
2010 Aug 12 00:40:53.064211 msdp: librpm [7070] Policy eval. returning action 
handle 0x
2010 Aug 12 00:40:53.064238 msdp: librpm [7070] == RPM Evaluation 
result RPM_MATCH_REJECT ==
2010 Aug 12 00:40:53.064282 msdp: [7070] (default-base) Entire outgoing SA to 
peer 10.255.255.228 filtered

Now, the earlier line (deny 5) in the route-map is being matched even though 
its ACL matches nothing (DENY-IP-ANY-ANY).

The route-map isn't getting evaluated beyond the first deny line in either case.

Could this possibly be correct behavior?

___
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 7000 MSDP peering policy woes

[Christopher.Marget]

I'm trying to implement PBR-filtering of MSDP messages from a Nexus 7000 
running 5.0(2a), and I'm starting to think that the route-map is being 
interpreted wrong.

The relevant parts of the configuration are:

feature msdp
feature pbr
ip msdp originator-id loopback0
ip msdp peer W.X.Y.Z connect-source loopback0
ip msdp sa-policy W.X.Y.Z MSDP-INTRA-BUILDING-POLICY in
ip msdp sa-policy W.X.Y.Z MSDP-INTRA-BUILDING-POLICY out

ip access-list PERMIT-IP-ANY-ANY
 permit ip any any

route-map MSDP-INTRA-BUILDING-POLICY deny 10
  match ip address PERMIT-IP-ANY-ANY
route-map MSDP-INTRA-BUILDING-POLICY deny 20
  match ip address MSDP-FORBIDDEN-MC-GROUPS
route-map MSDP-INTRA-BUILDING-POLICY permit 30
  match ip address RFC-2365-GLOBAL-GROUPS
route-map MSDP-INTER-ENTERPRISE-POLICY deny 40

Next, I enable 'debug ip msdp' and 'debug ip msdp policy', and switch on a 
multicast source.  The debug output indicates that only the first line (deny 
10) of the route-map is being evaluated:

2010 Aug 12 00:02:40.689445 msdp: librpm [7070] == RPM Evaluation 
starting for policy MSDP-INTRA-BUILDING-POLICY ==
2010 Aug 12 00:02:40.689482 msdp: librpm [7070]  Evaluating (rmap 
MSDP-INTRA-BUILDING-POLICY - seq 10 - cmd RPM_MATCH_IP_ADDR_ACL) 
2010 Aug 12 00:02:40.689512 msdp: librpm [7070]  Evaluation result (seq 10 
- cmd RPM_MATCH_IP_ADDR_ACL):RPM_MATCH_IGNORE 
2010 Aug 12 00:02:40.689562 msdp: librpm [7070] EVAL context->flag 0x001b
2010 Aug 12 00:02:40.689668 msdp: librpm [7070] Policy eval. returning action 
handle 0x
2010 Aug 12 00:02:40.689698 msdp: librpm [7070] == RPM Evaluation 
result RPM_MATCH_REJECT ==
2010 Aug 12 00:02:40.689743 msdp: [7070] (default-base) Entire outgoing SA to 
peer W.X.Y.Z filtered

So far, so good.  'deny 10' matches everything, so the next line of the 
route-map didn't get evaluated, and the announcement for this new multicast 
source is filtered.

Now I'll insert an earlier 'deny' line into the route-map, this time with an 
ACL that matches nothing:

ip access-list DENY-IP-ANY-ANY
 deny ip any any

route-map MSDP-INTRA-BUILDING-POLICY deny 5
  match ip address DENY-IP-ANY-ANY

Clear all of the mroutes, and fire the source back up.  Debug says:

2010 Aug 12 00:40:53.064084 msdp: librpm [7070] == RPM Evaluation 
starting for policy MSDP-INTRA-BUILDING-POLICY ==
2010 Aug 12 00:40:53.064121 msdp: librpm [7070]  Evaluating (rmap 
MSDP-INTRA-BUILDING-POLICY - seq 5 - cmd RPM_MATCH_IP_ADDR_ACL) 
2010 Aug 12 00:40:53.064152 msdp: librpm [7070]  Evaluation result (seq 5 - 
cmd RPM_MATCH_IP_ADDR_ACL):RPM_MATCH_IGNORE 
2010 Aug 12 00:40:53.064181 msdp: librpm [7070] EVAL context->flag 0x005b
2010 Aug 12 00:40:53.064211 msdp: librpm [7070] Policy eval. returning action 
handle 0x
2010 Aug 12 00:40:53.064238 msdp: librpm [7070] == RPM Evaluation 
result RPM_MATCH_REJECT ==
2010 Aug 12 00:40:53.064282 msdp: [7070] (default-base) Entire outgoing SA to 
peer 10.255.255.228 filtered

Now, the earlier line (deny 5) in the route-map is being matched even though 
the ACL matches nothing (DENY-IP-ANY-ANY).

The route-map isn't getting evaluated beyond the first deny line in either case.

Could this possibly be correct behavior?
___
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] SXI4a (Was: 7606 config issue !!!)

[David Hughes]

On 11/08/2010, at 8:03 AM, Ge Moua wrote:

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

Thanks for the feedback.  Actually I'm interested in Cat6K / Sup720.  This 
thread went a bit off-topic from memory and ended up talking about a couple of 
SXI related issues.



Thanks

David
...



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 ?

___
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] CAT6509 module position in chassis

[Pavel Skovajsa]

We ran into one issue when the 10G 6708 module in slot 1 of C6509-E
was shutting down due to high temperature. The Cisco suggestion was to
put it into a free slot somewhere in the middle between the Sup
(module 5) and module 1 as it supposedly has a better air flow. We
replugged it into slot3 which magically solved the issue.

I created these C6509-E rules for myself:
- if possible always make at least one slot free space between modules
for better air flow
- put the "higher throughput cards having > 60 degrees Celsius" (like
6708) more in the middle part
- in case of issues the air flow is left to right so try to find out
whether there is nothing blocking/circulating the air flow

-pavel

 On Wed, Aug 11, 2010 at 4:03 PM, Pavel Dimow  wrote:
> Hi,
>
> is there any recommended/best practices for module placement in
> CAT6509 chassis?  For example, FWSM in slot 3, ACE in slot 2 etc etc..
> ___
> 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/

[c-nsp] Cisco Security Advisory: SQL Injection Vulnerability in Cisco Wireless Control System

[Cisco Systems Product Security Incident Response Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cisco Security Advisory: SQL Injection Vulnerability in Cisco
Wireless Control System

Advisory ID: cisco-sa-20100811-wcs

Revision 1.0

For Public Release 2010 August 11 1600 UTC (GMT)

+-

Summary
===

Cisco Wireless Control System (WCS) contains a SQL injection
vulnerability that could allow an authenticated attacker full access
to the vulnerable device, including modification of system
configuration; create, modify and delete users; or modify the
configuration of wireless devices managed by WCS.

Cisco has released free software updates that address this
vulnerability.

There are no workarounds for this vulnerability.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20100811-wcs.shtml

Affected Products
=

Vulnerable Products
+--

Cisco WCS devices running software 6.0.x are affected by this
vulnerability.

Note: Cisco WCS software release 7.0 is not affected by this
vulnerability. Cisco WCS version 7.0.164.0 (which is the first 7.0
version) already contains the fix for this vulnerability. Cisco WCS
software releases prior to 6.0 are not affected by this
vulnerability.

The version of WCS software installed on a particular device can be
found via the Cisco WCS HTTP management interface. Choose "Help > 
About the Software" to obtain the software version.

Products Confirmed Not Vulnerable
+

Cisco Wireless LAN Controllers (WLC) are not affected by this
vulnerability. No other Cisco products are currently known to be
affected by this vulnerability.

Details
===

Cisco WCS enables an administrator to configure and monitor one or
more WLCs and associated access points.

A SQL injection vulnerability exists in Cisco WCS. Exploitation could
allow an authenticated attacker to modify system configuration;
create, modify and delete users; or modify the configuration of
wireless devices managed by WCS.

This vulnerability is documented in Cisco bug ID CSCtf37019 and has
been assigned Common Vulnerabilities and Exposures (CVE) ID
CVE-2010-2826.

Vulnerability Scoring Details
=

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

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

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

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

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

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

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

CSCtf37019 - SQL injection in order by clause of Client List screens

CVSS Base Score - 9.0

Access Vector   - Network
Access Complexity   - Low
Authentication  - Single
Confidentiality Impact  - Complete
Integrity Impact- Complete
Availability Impact - Complete

CVSS Temporal Score - 7.4

Exploitability  - Functional
Remediation Level   - Official-Fix
Report Confidence   - Confirmed

Impact
==

Successful exploitation of this vulnerability could allow an
authenticated attacker to modify system configuration; create, modify
and delete users; or modify the configuration of wireless devices
managed by WCS.

Software Versions and Fixes
===

When considering software upgrades, also consult:

http://www.cisco.com/go/psirt

and any subsequent advisories to determine exposure and a
complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

This vulnerability is fixed in Cisco WCS version 6.0.196.0.

Cisco WCS software can be downloaded from this location:

http://tools.cisco.com/support/downloads/go/Redirect.x?mdfid=279705270

Workarounds
===

There are no workarounds for this vulnerability.

Mitigation techniques that can be deployed on Cisco devices within
the network are available in the Cisco Applied Mitigation Bulletin
companion document for this advisory:

http://www.cisco.com/warp/public/707/cisco-amb-20100811-wcs.shtml

Obtaining Fixed Software


Cisco has released free software updates that address this
vulnerability. Prior

[c-nsp] Cisco Security Advisory: Multiple Vulnerabilities in the Cisco ACE Application Control Engine Module and Cisco ACE 4710 Application Control Engine

[Cisco Systems Product Security Incident Response Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cisco Security Advisory: Multiple Vulnerabilities in the Cisco ACE
Application Control Engine Module and Cisco ACE 4710 Application
Control Engine

Advisory ID: cisco-sa-20100811-ace

Revision 1.0

For Public Release 2010 August 11 1600 UTC (GMT)

+-

Summary
===

The Cisco ACE Application Control Engine Module and Cisco ACE 4710
Application Control Engine contain the following DoS vulnerabilities:

  * Real-Time Streaming Protocol (RTSP) inspection DoS vulnerability
  * HTTP, RTSP, and Session Initiation Protocol (SIP) inspection DoS
vulnerability
  * Secure Socket Layer (SSL) DoS vulnerability
  * SIP inspection DoS vulnerability

Cisco has released free software updates for affected customers.
Workarounds that mitigate some of the vulnerabilities are available.

Note: These vulnerabilities are independent of each other. A device
may be affected by one vulnerability and not affected by another.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20100811-ace.shtml

Affected Products
=

Vulnerable Products
+--

The Cisco ACE Application Control Engine Module and Cisco ACE 4710
Application Control Engine are affected by multiple vulnerabilities.
Affected versions vary depending on the specific vulnerability. For
specific version information, refer to the Software Versions and
Fixes section of this advisory.

RTSP Inspection DoS Vulnerability
~

Cisco ACE Application Control Engine Module and Cisco ACE 4710
Application Control Engine appliances configured with RTSP inspection
are affected. RTSP inspection is disabled by default.

HTTP, RTSP, and SIP Inspection DoS Vulnerability


Cisco ACE 4710 Application Control Engine appliances configured with
HTTP, RTSP, or SIP inspection are affected. HTTP, RTSP, and SIP
inspection are disabled by default. The Cisco ACE Application Control
Engine Module is not affected by this vulnerability.

Note: This vulnerability is independent from the other RSTP and SIP
inspection vulnerabilities described in this advisory.

SSL DoS Vulnerability
~

Cisco ACE Application Control Engine Module processing SSL
transactions are affected by this vulnerability. The Cisco ACE 4710
Application Control Engine appliance is not affected by this
vulnerability.

SIP Inspection DoS Vulnerability


Cisco ACE Application Control Engine Module and Cisco ACE 4710
Application Control Engine appliances configured for SIP inspection
are affected. SIP inspection is disabled by default.

Determining Software Versions
~

To display the version of system software that is currently running
on Cisco ACE Application Control Engine, use the "show version"
command. This example displays the output of the "show version" command
on the Cisco ACE Application Control Engine software version A3(1.0):

ACE-4710/Admin# show version
Cisco Application Control Software (ACSW)
TAC support: http://www.cisco.com/tac
Copyright (c) 1985-2008 by Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.

Software
  loader:Version 0.95
  system:Version A3(1.0) [build 3.0(0)A3(0.0.148)]
  system image file: (nd)/192.168.65.31/scimitar.bin

  Device Manager version 1.1 (0) 20080805:0415

...


This example displays the output of the show version command on a
Cisco ACE Application Control Engine Module software version A2(3.0):

ACEmod/Admin# show version
Cisco Application Control Software (ACSW)
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2009, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.

Software
  loader:Version 12.2[121]
  system:Version A2<3.0> [build 3.0(0)A2(2.99.80)]
  system image file: [LCP] disk0:c6ace-t1k9-mzg.A2_2_99_80.bin
  licensed features: no feature license is installed

...


Products Confirmed Not Vulnerable
+

The Cisco ACE XML Gateway, the Cisco ACE Web Application Firewall,
and the Cisco ACE GSS 4400 Series Global Site Selector Appliances are
not affected by any of the vulnerabilities that are described in this
advisory.

N

Re: [c-nsp] Erspan on 7600

[Tim Stevenson]

It most certainly is done in h/w - as I said, both encap & decap (ie 
source & dest sessions) are hw based. At the dest box, the FE strips 
off the GRE/ERSPAN  header & dumps the original packet on the SPAN dest port.


Note that certain misconfigurations can cause a punt, particularly on 
the ERSPAN destination box. I suggest carefully following the config 
guide for the proper configuration. One key point is configuring 
identical IPs and ERSPAN IDs on the source & destination sessions.


That can all be avoided by just pointing directly to the IP of a host 
w/wireshark etc that can decode the packets with the GRE/ERSPAN still on it.


Hope that helps,
Tim

At 01:02 AM 8/11/2010, Mikael Abrahamsson averred:


On Wed, 11 Aug 2010, Phil Mayers wrote:

> We've used ERSPAN on some truly phenomenal bitrates; it *is* done in
> hardware.

Sending ERSPAN is done in hw, I've done multigigabit ERSPAN.

ERSPAN reception is not done in HW (at least not when I tested) and it
killed the box when I tried :P

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





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] CAT6509 module position in chassis

[Chris Scott]

On 11 August 2010 15:03, Pavel Dimow  wrote:
> Hi,
>
> is there any recommended/best practices for module placement in
> CAT6509 chassis?  For example, FWSM in slot 3, ACE in slot 2 etc etc..

I have my FWSM in slot 9 to keep fat fingers away from the shutdown
button when making any changes to the linecards in slots 1-3 :)

--
Chris



-- 
Chris

___
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] CAT6509 module position in chassis

[Nick Hilliard]

On 11/08/2010 15:03, Pavel Dimow wrote:

is there any recommended/best practices for module placement in
CAT6509 chassis?  For example, FWSM in slot 3, ACE in slot 2 etc etc..


No.  Other than that the sup720 needs to be plugged into slot 5 or 6, there 
are no other limitations.



http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856_ps2797_Products_Data_Sheet.html#wp9000238table405


(see "Slot requirements").

Nick

___
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] CAT6509 module position in chassis

[Pavel Dimow]

Hi,

is there any recommended/best practices for module placement in
CAT6509 chassis?  For example, FWSM in slot 3, ACE in slot 2 etc etc..
___
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]

Well, I guess this post as been beaten to death now.

I wanted to correct something i said earlier though .. a normal sup-32 can
support jumbo frame.

On Tue, Aug 10, 2010 at 10:20 AM, Heath Jones  wrote:

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

Re: [c-nsp] EBGP Export VPN4 route only

[Pshem Kowalczyk]

Hi,


On 11 August 2010 21:11, Good One  wrote:
{cut}

> Can you please me know all the possibilities of exporting just MPLS L3VPN 
> routes to EBGP neighbors. The reason for this to export only VPN4 routes for 
> inter-AS vpn.

Depending on your individual circumstances you can either:
1. Disable ipv4 completly (no bgp default ipv4-unicast)
2. not activate (or deactivate if becomes active automatically) the
neighbour in the ipv4 family at all
3. Apply some filtering on the extended communities towards neighbour
- only export those that have the community you want to advertise to
the other AS.

kind regards
Pshem
___
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] EBGP Export VPN4 route only

[Good One]

 

Dear All,

 

Can you please me know all the possibilities of exporting just MPLS L3VPN 
routes to EBGP neighbors. The reason for this to export only VPN4 routes for 
inter-AS vpn.
 
Thanks
 
BR//
Andres
___
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

[LM]

Works perfectly.
Dont import the .pcf file, use to have problems, much better if you 
configured the account manually, not a big deal.


El 10/08/10 16:57, Jan Gregor escribió:

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

[Mikael Abrahamsson]

On Wed, 11 Aug 2010, Phil Mayers wrote:

FWIW we seldom (In fact I'm not sure ever!) use an actual 6500 as an 
erspan receiver; we use "gulp" on a Unix box, or the wireshark ERSPAN 
decoder, depending on the requirements.


Yes, I usually tcpdump it to a pcap file and analyse it with wireshark.

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

Re: [c-nsp] Erspan on 7600

[Phil Mayers]

On 08/11/2010 09:02 AM, Mikael Abrahamsson wrote:

On Wed, 11 Aug 2010, Phil Mayers wrote:


We've used ERSPAN on some truly phenomenal bitrates; it *is* done in
hardware.


Sending ERSPAN is done in hw, I've done multigigabit ERSPAN.

ERSPAN reception is not done in HW (at least not when I tested) and it
killed the box when I tried :P



Really? That seems odd.

FWIW we seldom (In fact I'm not sure ever!) use an actual 6500 as an 
erspan receiver; we use "gulp" on a Unix box, or the wireshark ERSPAN 
decoder, depending on the requirements.

___
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

[Mikael Abrahamsson]

On Wed, 11 Aug 2010, Phil Mayers wrote:

We've used ERSPAN on some truly phenomenal bitrates; it *is* done in 
hardware.


Sending ERSPAN is done in hw, I've done multigigabit ERSPAN.

ERSPAN reception is not done in HW (at least not when I tested) and it 
killed the box when I tried :P


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

Re: [c-nsp] Erspan on 7600

[Dobbins, Roland]

On Aug 11, 2010, at 2:45 PM, Phil Mayers wrote:

> We've used ERSPAN on some truly phenomenal bitrates; it *is* done in hardware.

One thing to keep in mind is to be sure and transport ERSPAN traffic over the 
DCN or a dedicated telemetry export network so as to avoid the hall-of-mirrors 
effect.

;>

---
Roland Dobbins  // 

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken




___
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

[Phil Mayers]

On 08/10/2010 11:46 PM, Mack McBride wrote:

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


Yes. But such traffic must come in via a gigE or vlan interface, and 
ERSPAN can capture it there (in hardware)


You can *also* span the RP/SP itself, and as I understand it again this 
is done in hardware. Effectively it SPANs the internal gigE port facing 
the RP/SP


We've used ERSPAN on some truly phenomenal bitrates; it *is* done in 
hardware.

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