[c-nsp] cisco-nsp Digest, Vol 61, Issue 54

Sipes, Nathan Nathan_Sipes at kindermorgan.com
Tue Dec 18 13:39:06 EST 2007




Nathan Sipes
Sr. Network
Tel: 303-914-4996
FAX:
Kinder Morgan
370 Van Gordon St
Lakewood, CO
80228
Nathan_Sipes at kindermorgan.com



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
cisco-nsp-request at puck.nether.net
Sent: Tuesday, December 18, 2007 8:43 AM
To: cisco-nsp at puck.nether.net
Subject: cisco-nsp Digest, Vol 61, Issue 54

Send cisco-nsp mailing list submissions to
	cisco-nsp at puck.nether.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://puck.nether.net/mailman/listinfo/cisco-nsp
or, via email, send a message with subject or body 'help' to
	cisco-nsp-request at puck.nether.net

You can reach the person managing the list at
	cisco-nsp-owner at puck.nether.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-nsp digest..."


Today's Topics:

   1. GLBP over 802.1q subinterface (Ultra)
   2. BGP soft reconfiguration inbound (Mohamed Ahmad)
   3. Re: BGP soft reconfiguration inbound (Rodney Dunn)
   4. Re: BGP soft reconfiguration inbound (Dan Sabau)
   5. Re: Access Point & 2 SSID's Trunked to Vlan's
      (A.L.M.Buxey at lboro.ac.uk)
   6. Re: BGP soft reconfiguration inbound (Peter Rathlev)
   7. Re: BGP soft reconfiguration inbound (Paolo Lucente)
   8. CoPP not catching software-switched CEF (Blake Willis)
   9. Re: Access Point & 2 SSID's Trunked to Vlan's (Dan Letkeman)


----------------------------------------------------------------------

Message: 1
Date: Tue, 18 Dec 2007 13:05:01 +0100
From: Ultra <ultramajestic at yahoo.es>
Subject: [c-nsp] GLBP over 802.1q subinterface
To: cisco-nsp at puck.nether.net
Message-ID: <1197979501.5631.16.camel at hal9000>
Content-Type: text/plain

Hi all,

I tried to find the answer by myself but I didn't find it.
The question is very simple, is possible to execute GLBP over 802.1q
subinterface? I am not sure since I don't know which is going to happen
with STP.

Any experience with that?

The reason is that I want to create subinterfaces in order to use 802.1q
and VRFs but I am not sure if it is going to be possible in my actual
scenenario.

Any comments is appreciated.



------------------------------

Message: 2
Date: Tue, 18 Dec 2007 12:30:23 -0000
From: "Mohamed Ahmad" <mo at streamuk.com>
Subject: [c-nsp] BGP soft reconfiguration inbound
To: <cisco-nsp at puck.nether.net>
Message-ID: <200712181230.lBICUQrE066002 at puck.nether.net>
Content-Type: text/plain;	charset="us-ascii"

Hi guys,
 
I was wondering what was the effect of disabling "soft-reconfiguration
inbound" on our neighbor statement with our provider (basically a live
network). I was looking at the ram usage and it's been going up slowly.
We
currently receive full table from our provider but filter to get only
default (I know we can get them to just send a default but we might
remove
filter in the future to get full routes on an upgraded router). Any ill
effects of removing the "soft-reconfiguration inbound"?
 
Many thanks,
 
 


Registered Company No.: 4206916
VAT No.: GB 774 2593 02

 

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the
original. Any other use of the email by you is prohibited.

 


------------------------------

Message: 3
Date: Tue, 18 Dec 2007 08:14:14 -0500
From: Rodney Dunn <rodunn at cisco.com>
Subject: Re: [c-nsp] BGP soft reconfiguration inbound
To: Mohamed Ahmad <mo at streamuk.com>
Cc: cisco-nsp at puck.nether.net
Message-ID: <20071218131414.GH20255 at rtp-cse-489.cisco.com>
Content-Type: text/plain; charset=us-ascii

On Tue, Dec 18, 2007 at 12:30:23PM -0000, Mohamed Ahmad wrote:
> Hi guys,
>  
> I was wondering what was the effect of disabling "soft-reconfiguration
> inbound" on our neighbor statement with our provider (basically a live
> network). I was looking at the ram usage and it's been going up
slowly. We
> currently receive full table from our provider but filter to get only
> default (I know we can get them to just send a default but we might
remove
> filter in the future to get full routes on an upgraded router). Any
ill
> effects of removing the "soft-reconfiguration inbound"?

>From what I recall none other than not being able to see the
prefiltered
copy of the feed you get from the peer.

And it allowed you to do a soft clear so you didn't have to reset
the entire peer session.


Rodney

>  
> Many thanks,
>  
>  
> 
> 
> Registered Company No.: 4206916
> VAT No.: GB 774 2593 02
> 
>  
> 
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you have
> received it in error, please notify the sender immediately and delete
the
> original. Any other use of the email by you is prohibited.
> 
>  
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


------------------------------

Message: 4
Date: Tue, 18 Dec 2007 14:36:44 +0200
From: Dan Sabau <dan.sabau at tbm.ro>
Subject: Re: [c-nsp] BGP soft reconfiguration inbound
To: Mohamed Ahmad <mo at streamuk.com>
Cc: cisco-nsp at puck.nether.net
Message-ID: <4767BEDC.4060502 at tbm.ro>
Content-Type: text/plain; charset=ISO-8859-1

Hi,
you will free some ram, but won't have any more the recieved-routes
table.

Mohamed Ahmad wrote:
> Hi guys,
>  
> I was wondering what was the effect of disabling "soft-reconfiguration
> inbound" on our neighbor statement with our provider (basically a live
> network). I was looking at the ram usage and it's been going up
slowly. We
> currently receive full table from our provider but filter to get only
> default (I know we can get them to just send a default but we might
remove
> filter in the future to get full routes on an upgraded router). Any
ill
> effects of removing the "soft-reconfiguration inbound"?
>  
> Many thanks,
>  
>  
>
>
> Registered Company No.: 4206916
> VAT No.: GB 774 2593 02
>
>  
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you have
> received it in error, please notify the sender immediately and delete
the
> original. Any other use of the email by you is prohibited.
>
>  
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>   

-- 
Dan Sabau
TBM Invest
Manager Tehnic Date
0740078983


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



------------------------------

Message: 5
Date: Tue, 18 Dec 2007 14:17:07 +0000
From: A.L.M.Buxey at lboro.ac.uk
Subject: Re: [c-nsp] Access Point & 2 SSID's Trunked to Vlan's
To: Dan Letkeman <danletkeman at gmail.com>
Cc: cisco-nsp at puck.nether.net
Message-ID: <20071218141707.GB16980 at lboro.ac.uk>
Content-Type: text/plain; charset=us-ascii

Hi,

> If I copy this configuration to my other ap's in the building will a
> client(notebook) automatically roam from ap to ap without getting
> disconnected?

not without using other technologies - as each AP runs the
authentication
so your client needs to reauthenticate when associating with each AP

> Do you have 802.11a clients or is the 802.11a radio used for something
else?
> How would I setup the AP so there is a minimum signal level that is
> allowed?  eg, if a user is outside the building and still connected
that it
> won't work if the users device is say past -75db...

you can start off by using the 'speed' command to select the supported
connection rates - but a decent antennae may negate the 'security' of
such a setup. personally i feel that WPA2 is strong enough that it
doesnt 
matter if the signal can be received from further away. you could also
turn down the power of the antennae (antenna gain) - but, once again,
that
will affect how your own users will receive the wireless.  place
a decent zinc/neodynium mesh or somesuch in your wall cavities - there
are some papers out there describing such blocking methods.
 
> Also, I accidentally ordered LWAPP's and I have converted them back to
> autonomous ap's.  Is there any difference between a converted one vs a
> bought autonomous ap?

apart from how it appears in CDP, inventory lists and its bootloader? 
no functional difference as far as i'm aware.

alan


------------------------------

Message: 6
Date: Tue, 18 Dec 2007 15:29:22 +0100
From: Peter Rathlev <peter at rathlev.dk>
Subject: Re: [c-nsp] BGP soft reconfiguration inbound
To: cisco-nsp at puck.nether.net
Message-ID: <1197988162.17575.1.camel at localhost.localdomain>
Content-Type: text/plain

On Tue, 2007-12-18 at 12:30 +0000, Mohamed Ahmad wrote:
> Hi guys,
>  
> I was wondering what was the effect of disabling "soft-reconfiguration
> inbound" on our neighbor statement with our provider (basically a live
> network). I was looking at the ram usage and it's been going up
slowly. We
> currently receive full table from our provider but filter to get only
> default (I know we can get them to just send a default but we might
remove
> filter in the future to get full routes on an upgraded router). Any
ill
> effects of removing the "soft-reconfiguration inbound"?
>  
> Many thanks,

This shouldn't reset your BGP session, so you should be able to do it on
a live network. I've only tested it on our CE-boxes (C3560) so I don't
know for sure though.

Regards,
Peter Rathlev




------------------------------

Message: 7
Date: Tue, 18 Dec 2007 14:43:32 +0000
From: Paolo Lucente <pl+list at pmacct.net>
Subject: Re: [c-nsp] BGP soft reconfiguration inbound
To: Mohamed Ahmad <mo at streamuk.com>
Cc: cisco-nsp at puck.nether.net
Message-ID: <20071218144332.GA13896 at london.pmacct.net>
Content-Type: text/plain; charset=us-ascii

Hi Mohamed,

to add to what has already been said that if the BGP session with your
neighbor supports Route Refresh capability, you will still be able to
apply new policies softly - which helps overcoming the major drawback
of resetting the session thus impacting the live service. 

To check this out: "show ip bgp neighbor  <IP address>" and then look
at the "Neighbor capabilities" section.

Cheers,
Paolo


On Tue, Dec 18, 2007 at 12:30:23PM -0000, Mohamed Ahmad wrote:
> Hi guys,
>  
> I was wondering what was the effect of disabling "soft-reconfiguration
> inbound" on our neighbor statement with our provider (basically a live
> network). I was looking at the ram usage and it's been going up
slowly. We
> currently receive full table from our provider but filter to get only
> default (I know we can get them to just send a default but we might
remove
> filter in the future to get full routes on an upgraded router). Any
ill
> effects of removing the "soft-reconfiguration inbound"?
>  
> Many thanks,
>  
>  
> 
> 
> Registered Company No.: 4206916
> VAT No.: GB 774 2593 02



------------------------------

Message: 8
Date: Tue, 18 Dec 2007 15:57:21 +0100 (CET)
From: Blake Willis <cnsp at 2112.net>
Subject: [c-nsp] CoPP not catching software-switched CEF
To: cisco-nsp at puck.nether.net
Message-ID: <Pine.BSO.4.62.0712181356310.29786 at bastille.2112.net>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Greetings all,

 	During an attack towards a customer yesterday, it seems that on
one 
router the attack traffic was punted and interrupt-switched in the 
software-switched CEF path (on 720/3BXL, SXD7b).  The destination was
far far 
away from the router in question and the router was not the ingress or
egress 
point in the network for the flow.  The flow (grabbed with
software-switched 
netflow) was:

Single flow, IP proto 0, src port 0, dst port 0, TOS 0, tcp_flags 0x10
(ACK)

Flows  Packets    Bytes    pps     bps      bpp
     1  63.5 M     5.2 G    51799   33.2 M   84

 	The ingress router had no trouble forwarding this with its PFC,
but the 
next one didn't (about the only difference between the two is that the
input 
interface on the affected router is an L3 LACP channel on a 6516 and
output is 
an enhanced OSM).  Netint forwarding is using about 30% cpu, and shows
about 7k 
netint throttles/sec (mask is 1k/2k):

suffering-bxl#proc
CPU utilization for five seconds: 46%/31%; one minute: 48%; five
minutes: 48%
suffering-bxl#sh msfc netint | incl count
  throttle count=231480922, timer count=98903862
suffering-bxl#sh msfc netint | incl count
  throttle count=231487564, timer count=98909697
suffering-bxl#sh msfc netint | incl count
  throttle count=231494050, timer count=98915276
suffering-bxl#proc
CPU utilization for five seconds: 40%/33%; one minute: 49%; five
minutes: 48%

It isn't hitting an MLS rate limiter (otherwise it would be rate-limited
and not eating cpu):

suffering-bxl#sh mls rate-limit usage | ex #
                              Rate Limiter Type     Packets/s   Burst
                            ---------------------   ---------   -----
                                    ICMP REDIRECT          10     255
                                      MTU FAILURE          10     255
                                  UCAST IP OPTION          10     255
                                      TTL FAILURE         500     255
                                        CEF GLEAN         500     255
                                   ACL BRIDGED IN          10     255
                                  ACL BRIDGED OUT          10     255
                                   IP RPF FAILURE          10     255
                            ICMP UNREAC. NO-ROUTE          10     255
                            ICMP UNREAC. ACL-DROP          10     255
                                        IP ERRORS          10     255
                                      IP FEATURES          10     255
                                      CAPTURE PKT        1000       1

So normally any punted traffic that doesn't hit an MLS RL is picked up
by CoPP, right?

suffering-bxl#sh policy-map control-plane | incl rate
         5 minute offered rate 3104 bps
       5 minute offered rate 10000 bps, drop rate 0 bps
         5 minute offered rate 0 bps
       5 minute offered rate 0 bps, drop rate 0 bps
       5 minute offered rate 57000 bps, drop rate 0 bps

Nope.  BTW my CoPP looks like this:

ip access-list extended critical-protocols
  deny <bunch of core protocols>
  permit ip any any
class-map match-all copp-ip
   match access-group name critical-protocols
policy-map copp-policy
   class pingme
      police 256000 64000 64000 conform-action transmit exceed-action
drop
   class copp-ip
      police 32000 8000 8000 conform-action transmit exceed-action drop
   class class-default	! don't police IS-IS

This traffic doesn't hit the CoPP ACL (although IP proto 0 is "ip any
any"):

suffering-bxl#sh access-lists critical-protocols | incl permit
     380 permit ip any any (33882814 matches)
suffering-bxl#sh access-lists critical-protocols | incl permit
     380 permit ip any any (33882867 matches)
suffering-bxl#sh access-lists critical-protocols | incl permit
     380 permit ip any any (33882901 matches)

or show up on the EOBC:

suffering-bxl#sh eobc | incl rate
         rx rate (bits/sec) = 2340000    rx rate (packets/sec) = 222
         tx rate (bits/sec) = 112000     tx rate (packets/sec) = 216

(BTW, about the same rate on the SP side of the EOBC as well).

 	So, it seems that CoPP doesn't catch software-switched CEF
(netint) 
traffic as it apparently isn't punted to the MSFC via the EOBC.  I
suppose a 
workaround could be to apply a CoPP-like policy to every interface on
the box 
using CAR ("rate-limit input access-group...") as that would likely
catch it 
just as soft-switched netflow does, but that's fairly logistically
annoying.

 	I won't have a chance to simulate this in the lab until after
the 
holidays.  Any experiences or comments are welcome...

---
  Blake Willis
  Network Engineer
  blake at 2112 dot net


------------------------------

Message: 9
Date: Tue, 18 Dec 2007 09:42:47 -0600
From: "Dan Letkeman" <danletkeman at gmail.com>
Subject: Re: [c-nsp] Access Point & 2 SSID's Trunked to Vlan's
To: A.L.M.Buxey at lboro.ac.uk, cisco-nsp at puck.nether.net
Message-ID:
	<dcbb85870712180742u1200ec96le5f38d69a1a2df00 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

That all makes sense.  What other technologies, besides wireless lan
controllers, would make it possible to roam from ap to ap?

Dan.

On Dec 18, 2007 8:17 AM, <A.L.M.Buxey at lboro.ac.uk> wrote:

> Hi,
>
> > If I copy this configuration to my other ap's in the building will a
> > client(notebook) automatically roam from ap to ap without getting
> > disconnected?
>
> not without using other technologies - as each AP runs the
authentication
> so your client needs to reauthenticate when associating with each AP
>
> > Do you have 802.11a clients or is the 802.11a radio used for
something
> else?
> > How would I setup the AP so there is a minimum signal level that is
> > allowed?  eg, if a user is outside the building and still connected
that
> it
> > won't work if the users device is say past -75db...
>
> you can start off by using the 'speed' command to select the supported
> connection rates - but a decent antennae may negate the 'security' of
> such a setup. personally i feel that WPA2 is strong enough that it
doesnt
> matter if the signal can be received from further away. you could also
> turn down the power of the antennae (antenna gain) - but, once again,
that
> will affect how your own users will receive the wireless.  place
> a decent zinc/neodynium mesh or somesuch in your wall cavities - there
> are some papers out there describing such blocking methods.
>
> > Also, I accidentally ordered LWAPP's and I have converted them back
to
> > autonomous ap's.  Is there any difference between a converted one vs
a
> > bought autonomous ap?
>
> apart from how it appears in CDP, inventory lists and its bootloader?
> no functional difference as far as i'm aware.
>
> alan
>


------------------------------

_______________________________________________
cisco-nsp mailing list
cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp

End of cisco-nsp Digest, Vol 61, Issue 54
*****************************************



More information about the cisco-nsp mailing list