Re: [c-nsp] Inter-VRF with NAT

[David Prall]

Supported in IOS-XE. VASI on the GSR has been long gone. IOS-XR had it at one 
point as well. 

David
--
http://dcp.dcptech.com
 

On 9/3/19, 4:32 AM, "James Bensley"  wrote:

On Tue, 3 Sep 2019 at 00:39, David Prall  wrote:
>
> Have you looked at VASI configuration. 
https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/200255-Configure-VRF-Aware-Software-Infrastruct.html
>
> David
> --
> http://dcp.dcptech.com

I'm happy to be wrong here, but I though the VASI stuff had been killed off?

Cheers,
James.



___
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] Inter-VRF with NAT

[David Prall]

Have you looked at VASI configuration. 
https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/200255-Configure-VRF-Aware-Software-Infrastruct.html

David
--
http://dcp.dcptech.com
 

On 8/19/19, 8:58 AM, "cisco-nsp on behalf of Aaron Gould" 
 wrote:

We have lots of zyxel's and manage all them with their public address.  Why 
don't you just do that? 

-Aaron

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mike
Sent: Sunday, August 18, 2019 3:14 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Inter-VRF with NAT


> Hi Mike,
>
> I'm not sure I've understood your network topology to be honest. Are you 
saying that you have Cisco devices with a single WAN link that doesn't support 
logical separation such as VLANs, e.g. ADSL [1] to run multiple VRFs over 
different VLANs, e.g. internet in global routing table over VLAN 10, management 
VRF over VLAN 20 etc? And you basically want multiple VRFs between the CPE and 
it's gateway (BNG/LNS/PE) do that you don't have to NAT your management traffic 
or need layer 2 connectivity to every CPE?

My cpe devices are typically zyxel. On the wan interface of these
devices, we usually have one service which is customer internet access
(pppoe or dhcp), and then another service which is mapped at either a
different vlan or a different vci/vpl, which is for management (and it's
always dhcp). So, from the perspective of the device, it only has one
routing table - the global table - and the 'default route' will normally
be the internet service gateway.  A common short-sightedness in these is
that they can't do policy routing, and they can't have a seperate
routing table where management network traffic uses a gateway different
than the internet service gateway.

The broadband aggregation router will have layer 2 to the subscriber.
So, vlan 10 would service pppoe/dhcp to the internet, while vlan 20
would be management traffic. I would like to have vlan 20 in a seperate
vrf, and I would like to be able to assign it an ip address
(172.16.1.1), and I want to hand out addresses to the cpe in the range
of 172.16.1.x. But, because the CPE are braindead, I need to arrange
things so management access to the cpe all appear to come from
172.16.1.1. That way, the devices won't need to consult the routing
table for a gateway and will instead simply arp for the  172.16.1.1 as
it's on the same l3 network segment. This is the only way to deal with
devices that don't know the correct gateway back. The only way I know
how to accomplish this is with nat, unless there was some other socks
type proxy on my asr1000 I don't know about.


Mike-




___
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] memory issue asr1002-x

[David Prall]

This is how much memory has been assigned to iosd. Show version will display 
memory allocated to iosd and the total memory installed. 

David
--
http://dcp.dcptech.com
On 11/21/17, 5:56 AM, "cisco-nsp on behalf of caroyy via cisco-nsp" 
 
wrote:

___
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] NAT problem on ISR 4331

[David Prall]

NVI isn’t supported within XE as you’ve stated. Have you tested with 
match-in-vrf on the ip nat command. 
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/xe-2/nat-xe-2-book/iadnat-match-vrf.html

As well your pool does not include the VRF that the pool belongs to. 

David

--
http://dcp.dcptech.com







On 3/16/16, 7:16 AM, "cisco-nsp on behalf of Eugen Şerban" 
 wrote:

>Hello,
>
>I tried to implement the NVI, but according to cisco: NAT Virtual
>Interfaces (NVIs) are not supported in the Cisco IOS XE software.
>
>I cannot put the guest and the internet in the same VRF. As you can see
>from the routing tables, the default route for both guest and hotspot is in
>a separate tunnel (400 for guest and 600 for hotspot). If I put them in the
>internet VRF I'd have to implement PBR, which I don't.
>
>From your configuration, I can see that you also have the internet in a
>different VRF (not the global).
>
>Just to recap, everything works if I create the nat per interface, but it
>doesn't work if the nat is per pool.
>
>This works:
>ip nat inside source list Guest2Internet interface gi 0/0/2 vrf guest
>overload
>
>This does not work:
>ip nat pool GuestNAT 1.2.3.91 1.2.3.91 netmask 255.255.255.248
>ip nat inside source list Guest2Internet pool GuestNAT vrf guest overload
>
>
>2016-03-16 11:54 GMT+01:00 Nick Cutting :
>
>> Sorry Global table... not global vrf
>>
>> Also - you may get more options using the NVI rather than ip nat inside /
>> outside when the internet is in a vrf - but less when the internet is in
>> the global table is involved.  I cannot remember the specifics - but stick
>> to this rule.
>>
>> This is on a router with ADSL default route in a VRF, and the guest wifi
>> in the same VRF
>>
>> interface GigabitEthernet0/0.201
>>  ip nat enable
>>
>> ip nat source list GUEST-WIFI-NAT interface GigabitEthernet0/0.201 vrf
>> ADSL overload
>>
>>
>>
>> -Original Message-
>> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
>> Nick Cutting
>> Sent: 16 March 2016 10:37
>> To: Eugen Şerban; c...@marenda.net
>> Cc: cisco-nsp@puck.nether.net
>> Subject: Re: [c-nsp] NAT problem on ISR 4331
>>
>> These routers are much closer to ASR than ISR - they have the same feature
>> set. - e.g. VASI interfaces etc.
>>
>> Juergen is right about the global VRF - that is where I keep the internet
>> (default route), when implementing similar designs
>>
>> -Original Message-
>> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
>> Eugen Serban
>> Sent: 16 March 2016 09:36
>> To: c...@marenda.net
>> Cc: cisco-nsp@puck.nether.net
>> Subject: Re: [c-nsp] NAT problem on ISR 4331
>>
>> Hello Juergen,
>>
>> Please find bellow the routing table for all VRFs.
>>
>> The idea with this router is that in the future it might be used for
>> "hybrid networks", "local internet breakout" (or however you'd like to call
>> it). So we plan to use the default VRF for internal (trusted) traffic.
>>
>> hostname#sh ip route
>> [...]
>>
>> Gateway of last resort is not set
>>
>>   192.168.0.0/16 is variably subnetted, 3 subnets, 3 masks
>> S192.168.0.0/16 [1/0] via 192.168.37.1
>> C192.168.37.0/26 is directly connected, GigabitEthernet0/0/1.1
>> L192.168.37.56/32 is directly connected, GigabitEthernet0/0/1.1
>>
>> hostname#sh ip route vrf internet
>>
>> Routing Table: internet
>> [...]
>>
>> Gateway of last resort is 1.2.3.89 to network 0.0.0.0
>>
>> S*0.0.0.0/0 [1/0] via 1.2.3.89, GigabitEthernet0/0/2
>>   1.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
>> C1.2.3.88/29 is directly connected, GigabitEthernet0/0/2
>> L1.2.3.90/32 is directly connected, GigabitEthernet0/0/2
>> L1.2.3.91/32 is directly connected, GigabitEthernet0/0/2
>> L1.2.3.92/32 is directly connected, GigabitEthernet0/0/2
>>   14.0.0.0/32 is subnetted, 1 subnets
>> S14.22.77.29 [1/0] via 1.2.3.89, GigabitEthernet0/0/2
>>   18.0.0.0/32 is subnetted, 1 subnets
>> S18.33.25.41 [1/0] via 1.2.3.89, GigabitEthernet0/0/2
>>
>> hostname#sh ip route vrf guest
>>
>> Routing Table: guest
>> [...]
>>
>> Gateway of last resort is 0.0.0.0 to network 0.0.0.0
>>
>> S*0.0.0.0/0 is directly connected, Tunnel400
>>   14.0.0.0/32 is subnetted, 1 subnets
>> B14.22.77.29
>>[20/0] via 1.2.3.89 (internet), 6d22h, GigabitEthernet0/0/2
>>   18.0.0.0/32 is subnetted, 1 subnets
>> B18.33.25.41
>>[20/0] via 1.2.3.89 (internet), 6d22h, GigabitEthernet0/0/2
>>   172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
>> C172.16.112.0/23 is directly connected, GigabitEthernet0/0/1.122
>> L172.16.112.1/32 is directly connected, GigabitEthernet0/0/1.122
>>
>>
>> hostname#sh ip route vrf hotspot
>>
>> Routing Table: hotspot
>> [...]
>>
>> Gateway of last resort is 0.0.0.0 to network 0.0.0.0
>>
>> S*0.0.0.0/0 is directly connected, Tunnel600
>>   14.0.0.0/32 

Re: [c-nsp] remove giles.cooc...@williamhill.com

[David Prall]

In the header is the following:
 
List-Unsubscribe: ,

List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,

 
Please send an email from the account with unsubscribe in the subject to
cisco-nsp-requ...@puck.nether.net
 
David
 
--
http://dcp.dcptech.com
 
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
giles.cooc...@williamhill.com
Sent: Wednesday, September 15, 2010 3:44 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] remove giles.cooc...@williamhill.com
 
 
Hi 
Giles left WilliamHill online can you please  remove is email form the
mailing list 
 


Description: logo
|
Ran Kapon
|
IT Operations Team Leader 
|
Tel:  +350 2000-2753
|
Mobile: +447889320108
|
 
www.williamhill.com   

This communication contains information which is privileged and confidential
and is exclusively intended only for the individual or entity named above
(recipient(s)). If you are not the intended recipient(s) or the person
responsible for delivering it to the intended recipient(s), you are hereby
notified that any review, disclosure, dissemination, distribution or
reproduction of this communication message in any way or act is prohibited.
If you receive this communication by mistake please notify the sender
immediately and then destroy any copies of it. Please note that the sender
monitors e-mails sent or received. Thank you.
 
P Please consider the environment before printing this email or any
attachments.  
 
 
 
 
 
 
  _  


Confidentiality: The contents of this e-mail and any attachments transmitted
with it are intended to be confidential to the intended recipient; and may
be privileged or otherwise protected from disclosure. If you are not an
intended recipient of this e-mail, do not duplicate or redistribute it by
any means. Please delete it and any attachments and notify the sender that
you have received it in error.

This message was sent from WHG Trading Limited (registered company number
101439) and/or WHG (International) Limited (registered company number
99191), both of which are registered in Gibraltar whose registered office
addresses are: 6/1 Waterport Place, Gibraltar. This e-mail may relate to, or
be sent on behalf of, a subsidiary or other affiliated company of WHG
Trading Limited and/or WHG (International) Limited.

Unless specifically indicated otherwise, the contents of this e-mail are
subject to contract; and are not an official statement, and do not
necessarily represent the views, of WHG Trading Limited and/or WHG
(International) Limited, any of their subsidiaries or affiliated companies.

Please note that neither WHG Trading Limited nor WHG (International)
Limited, nor their subsidiaries and affiliated companies can accept any
responsibility for any viruses contained within this e-mail and it is your
responsibility to scan any emails and their attachments. WHG Trading Limited
and WHG (International) Limited, and their subsidiaries and affiliated
companies may monitor e-mail traffic data and also the content of e-mails
for effective operation of the e-mail system, or for security, purposes.
 
  _  


Confidentiality: The contents of this e-mail and any attachments transmitted
with it are intended to be confidential to the intended recipient; and may
be privileged or otherwise protected from disclosure. If you are not an
intended recipient of this e-mail, do not duplicate or redistribute it by
any means. Please delete it and any attachments and notify the sender that
you have received it in error.

This message was sent from WHG Trading Limited (registered company number
101439) and/or WHG (International) Limited (registered company number
99191), both of which are registered in Gibraltar whose registered office
addresses are: 6/1 Waterport Place, Gibraltar. This e-mail may relate to, or
be sent on behalf of, a subsidiary or other affiliated company of WHG
Trading Limited and/or WHG (International) Limited.

Unless specifically indicated otherwise, the contents of this e-mail are
subject to contract; and are not an official statement, and do not
necessarily represent the views, of WHG Trading Limited and/or WHG
(International) Limited, any of their subsidiaries or affiliated companies.

Please note that neither WHG Trading Limited nor WHG (International)
Limited, nor their subsidiaries and affiliated companies can accept any
responsibility for any viruses contained within this e-mail and it is your
responsibility to scan any emails and their attachments. WHG Trading Limited
and WHG (International) Limited, and their subsidiaries and affiliated
companies may monitor e-mail traffic data an

Re: [c-nsp] QoS not working - VPN acl conflicting???

[David Prall]

So all your voice traffic is destined to a single address? 
> access-list 156 permit ip any host 66.x.x.x.x

Certain that isn't just the control, and that a different address isn't
being used for the gateway?

I'd configure load-interval 30 on the outside interface so everything gets
updated faster. Where does "show ip inspect sessions" tell you that things
are going.

David

--
http://dcp.dcptech.com

> -Original Message-
> From: false [mailto:jct...@yahoo.com]
> Sent: Friday, April 05, 2013 10:28 AM
> To: 'cisco mailing list'; David Prall
> Subject: RE: [c-nsp] QoS not working - VPN acl conflicting???
> 
> Our voice solution is outsourced. The voip traffic goes straight to the
> Internet to our provider's voip server using the same T-1 that is used for
our
> site to site VPNs. ???
> 
> --- On Fri, 4/5/13, David Prall  wrote:
> 
> > From: David Prall 
> > Subject: RE: [c-nsp] QoS not working - VPN acl conflicting???
> > To: "'false'" , "'cisco mailing list'"  n...@puck.nether.net>
> > Date: Friday, April 5, 2013, 9:18 AM
> > Only want the pre-classify configured
> > on the crypto map. Then you can match
> > on the original source/destination addresses and protocol.
> >
> > You are only encrypting GRE traffic per the crypto map. Is
> > the voice traffic
> > flowing through the tunnel or via the physical interface.
> > All the service
> > policy is seeing is GRE with pre-classify if the traffic is
> > through the
> > tunnel. Modify the service-policy to match on dscp ef. Then
> > place another
> > service policy to match on an acl ingress on the inside
> > interface and set
> > dscp ef. Then the gre header will be marked ef for voice
> > traffic, the ipsec
> > will be marked ef, and your egress policy will then
> > prioritize ef.
> >
> > David
> >
> > --
> > http://dcp.dcptech.com
> >
> >
> > > -Original Message-
> > > From: false [mailto:jct...@yahoo.com]
> > > Sent: Friday, April 05, 2013 10:05 AM
> > > To: 'cisco mailing list'; David Prall
> > > Subject: RE: [c-nsp] QoS not working - VPN acl
> > conflicting???
> > >
> > > Still stuck. Keep in mind that I am trying to make the
> > QoS policy work on
> > > traffic that is NOT going over the tunnel. This is voip
> > traffic going to
> > my
> > > provider. I tried using the qos-preclassify command at
> > the crypto map
> > level
> > > and the tunnel interface and then did huge transfers
> > from branch to branch
> > > just to saturate my T-1 and it did, but the policy
> > never
> > reserved/prioritized
> > > my voip traffic.
> > >
> > > Serial0/1/0 is up, line protocol is up
> > >   Hardware is GT96K with integrated T1
> > CSU/DSU
> > >   Internet address is x.x.x.x/30
> > >   MTU 1500 bytes, BW 1544 Kbit/sec, DLY
> > 2 usec,
> > >   reliability 255/255, txload 231/255,
> > rxload 16/255
> > >
> > >   Service-policy output: VOIPpm
> > >     queue stats for all priority
> > classes:
> > >       queue limit 64 packets
> > >       (queue depth/total
> > drops/no-buffer drops) 0/0/0
> > >       (pkts output/bytes
> > output) 0/0
> > >
> > >     Class-map: VOIPcm (match-all)
> > >       0 packets, 0 bytes
> > >       5 minute offered rate 0
> > bps, drop rate 0 bps
> > >       Match: access-group 156
> > >       Priority: 33% (509
> > kbps), burst bytes 12700, b/w exceed drops: 0
> > >
> > >     Class-map: class-default
> > (match-any)
> > >       1437759 packets,
> > 848687414 bytes
> > >
> > > >From my research,  it looks like the
> > qos-preclassify command only affects
> > > traffic going over the tunnel. Any help would be very
> > much appreciated.
> > >
> > >
> > > --- On Thu, 4/4/13, David Prall 
> > wrote:
> > >
> > > > From: David Prall 
> > > > Subject: RE: [c-nsp] QoS not working - VPN acl
> > conflicting???
> > > > To: "'false'" ,
> > "'cisco mailing list'"  > > n...@puck.nether.net>
> > > > Date: Thursday, April 4, 2013, 12:11 PM
> > > > Need to turn on Pre-Classify in the
> > > > ipsec crypto map. Otherwise all you are
> > > > seeing is the ipsec traffic.
> > > >
> > > > David

Re: [c-nsp] QoS not working - VPN acl conflicting???

[David Prall]

Only want the pre-classify configured on the crypto map. Then you can match
on the original source/destination addresses and protocol. 

You are only encrypting GRE traffic per the crypto map. Is the voice traffic
flowing through the tunnel or via the physical interface. All the service
policy is seeing is GRE with pre-classify if the traffic is through the
tunnel. Modify the service-policy to match on dscp ef. Then place another
service policy to match on an acl ingress on the inside interface and set
dscp ef. Then the gre header will be marked ef for voice traffic, the ipsec
will be marked ef, and your egress policy will then prioritize ef.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: false [mailto:jct...@yahoo.com]
> Sent: Friday, April 05, 2013 10:05 AM
> To: 'cisco mailing list'; David Prall
> Subject: RE: [c-nsp] QoS not working - VPN acl conflicting???
> 
> Still stuck. Keep in mind that I am trying to make the QoS policy work on
> traffic that is NOT going over the tunnel. This is voip traffic going to
my
> provider. I tried using the qos-preclassify command at the crypto map
level
> and the tunnel interface and then did huge transfers from branch to branch
> just to saturate my T-1 and it did, but the policy never
reserved/prioritized
> my voip traffic.
> 
> Serial0/1/0 is up, line protocol is up
>   Hardware is GT96K with integrated T1 CSU/DSU
>   Internet address is x.x.x.x/30
>   MTU 1500 bytes, BW 1544 Kbit/sec, DLY 2 usec,
>   reliability 255/255, txload 231/255, rxload 16/255
> 
>   Service-policy output: VOIPpm
> queue stats for all priority classes:
>   queue limit 64 packets
>   (queue depth/total drops/no-buffer drops) 0/0/0
>   (pkts output/bytes output) 0/0
> 
> Class-map: VOIPcm (match-all)
>   0 packets, 0 bytes
>   5 minute offered rate 0 bps, drop rate 0 bps
>   Match: access-group 156
>   Priority: 33% (509 kbps), burst bytes 12700, b/w exceed drops: 0
> 
> Class-map: class-default (match-any)
>   1437759 packets, 848687414 bytes
> 
> >From my research,  it looks like the qos-preclassify command only affects
> traffic going over the tunnel. Any help would be very much appreciated.
> 
> 
> --- On Thu, 4/4/13, David Prall  wrote:
> 
> > From: David Prall 
> > Subject: RE: [c-nsp] QoS not working - VPN acl conflicting???
> > To: "'false'" , "'cisco mailing list'"  n...@puck.nether.net>
> > Date: Thursday, April 4, 2013, 12:11 PM
> > Need to turn on Pre-Classify in the
> > ipsec crypto map. Otherwise all you are
> > seeing is the ipsec traffic.
> >
> > David
> >
> > --
> > http://dcp.dcptech.com
> >
> > > -Original Message-
> > > From: cisco-nsp-boun...@puck.nether.net
> > [mailto:cisco-nsp-
> > > boun...@puck.nether.net]
> > On Behalf Of false
> > > Sent: Thursday, April 04, 2013 12:49 PM
> > > To: cisco mailing list
> > > Subject: [c-nsp] QoS not working - VPN acl
> > conflicting???
> > >
> > >
> > > Hello,
> > > I have a QoS  policy in place that is set to
> > reserve/prioritize traffic
> > for my
> > > outgoing VoIP traffic. We outsource our voip solution.
> > >
> > > I am trying to test my QoS policy by performing
> > multiple file transfers
> > > outbound to our remote site over vpn which uses the
> > same interface. You
> > > can see by the txload stats below that it should have
> > been high enough to
> > > make the voip policy kick in bit it didn't. There were
> > about six phones
> > > connected but not being used. They are just doing
> > keepalives for
> > > regisration, etc to the main server, which is indicated
> > in the access list
> > > below. Any ideas? Thank you,
> > >
> > > Serial0/1/0 is up, line protocol is up
> > > Hardware is GT96K with integrated T1 CSU/DSU
> > > Internet address is x.x.x.x/30
> > > MTU 1500 bytes, BW 1544 Kbit/sec, DLY 2 usec,
> > > reliability 255/255, txload 218/255, rxload 19/255
> > >
> > > router#sh policy-map interface serial 0/1/0
> > > Serial0/1/0
> > >
> > > Service-policy output: VOIPpm
> > > queue stats for all priority classes:
> > > queue limit 64 packets
> > > (queue depth/total drops/no-buffer drops) 0/0/0
> > > (pkts output/bytes output) 0/0
> > >
> > > Class-map: VOIPcm (match-all)
> > > 0 packets, 0 bytes
> > > 5 minute offered rate 0 bps, drop rate 0 bps
> > > Match: access

Re: [c-nsp] QoS not working - VPN acl conflicting???

[David Prall]

Need to turn on Pre-Classify in the ipsec crypto map. Otherwise all you are
seeing is the ipsec traffic.

David

--
http://dcp.dcptech.com

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of false
> Sent: Thursday, April 04, 2013 12:49 PM
> To: cisco mailing list
> Subject: [c-nsp] QoS not working - VPN acl conflicting???
> 
> 
> Hello,
> I have a QoS  policy in place that is set to reserve/prioritize traffic
for my
> outgoing VoIP traffic. We outsource our voip solution.
> 
> I am trying to test my QoS policy by performing multiple file transfers
> outbound to our remote site over vpn which uses the same interface. You
> can see by the txload stats below that it should have been high enough to
> make the voip policy kick in bit it didn't. There were about six phones
> connected but not being used. They are just doing keepalives for
> regisration, etc to the main server, which is indicated in the access list
> below. Any ideas? Thank you,
> 
> Serial0/1/0 is up, line protocol is up
> Hardware is GT96K with integrated T1 CSU/DSU
> Internet address is x.x.x.x/30
> MTU 1500 bytes, BW 1544 Kbit/sec, DLY 2 usec,
> reliability 255/255, txload 218/255, rxload 19/255
> 
> router#sh policy-map interface serial 0/1/0
> Serial0/1/0
> 
> Service-policy output: VOIPpm
> queue stats for all priority classes:
> queue limit 64 packets
> (queue depth/total drops/no-buffer drops) 0/0/0
> (pkts output/bytes output) 0/0
> 
> Class-map: VOIPcm (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: access-group 156
> Priority: 33% (509 kbps), burst bytes 12700, b/w exceed drops: 0
> 
> 
> Class-map: class-default (match-any)
> 898811 packets, 199817314 bytes
> 5 minute offered rate 23000 bps, drop rate 3000 bps
> Match: any
> Queueing
> queue limit 64 packets
> (queue depth/total drops/no-buffer drops/flowdrops) 0/81175/0/81175
> (pkts output/bytes output) 824273/184794616
> Fair-queue: per-flow queue limit 16
> router#
> 
> 
> CONFIG:
> access-list 156 permit ip any host 66.x.x.x.x
> 
> class-map match-all VOIPcm
> match access-group 156
> 
> policy-map VOIPpm
> class VOIPcm
> priority percent 33
> class class-default
> fair-queue
> 
> interface Serial0/1/0
> ip address 150.150.150.150 255.255.255.252
> ip access-group 101 in
> ip flow ingress
> ip flow egress
> ip nat outside
> ip inspect ISP2-cbac out
> ip virtual-reassembly
> encapsulation ppp
> crypto map vpnmap
> service-policy output VOIPpm
> end
> 
> crypto map vpnmap 21 ipsec-isakmp
>  set peer x.x.x.x
>  set transform-set vpn_set
>  match address 121
> crypto map vpnmap 32 ipsec-isakmp
>  set peer x.x.x.x
>  set transform-set vpn_set
>  match address 132
> 
> access-list 121 permit gre host 150.150.150.150 host 67.x.x.x.
> access-list 132 permit gre host 150.150.150.150 host 57.x.x.x.x
> 
> ___
> 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] MPLS VPN over mGRE

[David Prall]

I asked Craig Hill about the feature pointing him to your support forum post. 
He said there is no special signaling. The route map does all the work. 

David
--
I'm currently all thumbs so I apologize for the short message.

On Jan 31, 2013, at 3:07 AM, "John Neiberger"  wrote:

> I bet you're right. I should keep digging for some Cisco Live presentation or 
> something. I was hoping someone from Cisco would respond and explain the 
> magic fairy dust in this configuration. As you said, it must be that the 
> inbound route-map  also causes the neighbors to use SAFI 64 in outbound 
> updates. The docs I've seen so far don't say how it happens, they just said, 
> "And in this step, magic happens" or something similar.  :)
> 
> John
> 
> 
> On Thu, Jan 31, 2013 at 1:02 AM, Adam Vitkovsky  
> wrote:
>> Aah I see, so it’s got to be the route-map than, mapping the particular 
>> neighbor with a profile –causing the neighbors to negotiate safi 64 support.
>> 
>> You could try issuing  “sh ip b vpnv4 a nei x.x.x.x” to see whether safi 64 
>> has indeed been negotiated between the peers.
>> 
>>  
>> 
>> I bet the insides are explained in some cisco presentation.
>> 
>>  
>> 
>> adam
>> 
>>  
>> 
>> From: John Neiberger [mailto:jneiber...@gmail.com] 
>> Sent: Wednesday, January 30, 2013 6:16 PM
>> To: David Prall
>> Cc: Adam Vitkovsky; cisco-nsp@puck.nether.net
>> 
>> 
>> Subject: Re: [c-nsp] MPLS VPN over mGRE
>>  
>> 
>> That's exactly right. The part I can't figure out is what triggers the 
>> proper signalling. The BGP config for outbound vpnv4 updates looks like 
>> standard L3VPN. I'm trying to understand what causes it to send the tunnel 
>> information in the NLRI. I believe it is using SAFI 64. What causes it to 
>> use SAFI 64 instead of 128, which is what would normally be used for MPLS 
>> VPNs?
>> 
>>  
>> 
>> That's the part that's baking my noodle. I'm just not sure how it's working 
>> under the hood.
>> 
>>  
>> 
>> John
>> 
>>  
>> 
>> On Wed, Jan 30, 2013 at 9:15 AM, David Prall  wrote:
>> 
>> Sounds like you are using BGP Signaled MPLS VPN over mGRE which uses a
>> Route-Map on the neighbor relationship to provide the tunnel information.
>> http://www.cisco.com/en/US/docs/ios-xml/ios/interface/configuration/xe-3s/ir
>> -mpls-vpnomgre-xe.html
>> 
>> David
>> 
>> --
>> http://dcp.dcptech.com
>> 
>> 
>> 
>> > -Original Message-
>> > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
>> > boun...@puck.nether.net] On Behalf Of John Neiberger
>> > Sent: Wednesday, January 30, 2013 10:55 AM
>> > To: Adam Vitkovsky
>> > Cc: cisco-nsp@puck.nether.net
>> > Subject: Re: [c-nsp] MPLS VPN over mGRE
>> >
>> 
>> > The type of MPLS VPN over mGRE that we're using doesn't use a
>> > preconfigured
>> > tunnel interface or NHRP. As I understand it, the peers share
>> > tunnel-related information in vpnv4 updates using a SAFI of 64. This tells
>> > the other peers that those prefixes are related to the mgre tunnel and
>> that
>> > signals the receiving router to set up an adjacency over the multipoint
>> > tunnel, but I'm not quite sure how it does this. I don't understand what
>> > element of the config tells the router to use SAFI 64 in the vpnv4 updates
>> > instead of just treating them like regular L3VPN vpnv4 updates. It's kind
>> > of confusing. There seems to be a lot of magic happening under the hood
>> > here that I'm missing.
>> >
>> > John
>> >
>> >
>> > On Wed, Jan 30, 2013 at 1:15 AM, Adam Vitkovsky
>> > wrote:
>> >
>> > > Wow they really shrunk it down to three commands plus the route-map,
>> > now
>> > > that's something.
>> > >
>> > > > or is there some other mechanism that triggers tunnel endpoint
>> > discovery?
>> > > I believe since it's called mGRE it has to be NHRP taking care of
>> > > everything
>> > > in the background.
>> > > Does the loopback IP has to be allocated from a common range that has to
>> > be
>> > > shared among the PEs?
>> > >
>> > > I thought it's done via standard mGRE tunnels:
>> > >
>> > > interface Tunnel0
>> > > ip address 192.168.1.1 255.255.255.0
>> > > ip mtu 1440
>> > > ip nhrp authentication cisco123
>> > > ip nhrp map multicast dynamic
>> > > ip nhrp network-id 1
>> > > tunnel source FastEthernet0/0
>> > > tunnel mode gre multipoint
>> > > tunnel key 0
>> > > ip router isis 1
>> > >
>> > > -maybe "mpls ip" cmd. wouldn't work with mGRE Tunnel Int.
>> > >
>> > >
>> > > adam
>> > >
>> > >
>> 
>> > ___
>> > 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] MPLS VPN over mGRE

[David Prall]

Sounds like you are using BGP Signaled MPLS VPN over mGRE which uses a
Route-Map on the neighbor relationship to provide the tunnel information.
http://www.cisco.com/en/US/docs/ios-xml/ios/interface/configuration/xe-3s/ir
-mpls-vpnomgre-xe.html

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of John Neiberger
> Sent: Wednesday, January 30, 2013 10:55 AM
> To: Adam Vitkovsky
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] MPLS VPN over mGRE
> 
> The type of MPLS VPN over mGRE that we're using doesn't use a
> preconfigured
> tunnel interface or NHRP. As I understand it, the peers share
> tunnel-related information in vpnv4 updates using a SAFI of 64. This tells
> the other peers that those prefixes are related to the mgre tunnel and
that
> signals the receiving router to set up an adjacency over the multipoint
> tunnel, but I'm not quite sure how it does this. I don't understand what
> element of the config tells the router to use SAFI 64 in the vpnv4 updates
> instead of just treating them like regular L3VPN vpnv4 updates. It's kind
> of confusing. There seems to be a lot of magic happening under the hood
> here that I'm missing.
> 
> John
> 
> 
> On Wed, Jan 30, 2013 at 1:15 AM, Adam Vitkovsky
> wrote:
> 
> > Wow they really shrunk it down to three commands plus the route-map,
> now
> > that's something.
> >
> > > or is there some other mechanism that triggers tunnel endpoint
> discovery?
> > I believe since it's called mGRE it has to be NHRP taking care of
> > everything
> > in the background.
> > Does the loopback IP has to be allocated from a common range that has to
> be
> > shared among the PEs?
> >
> > I thought it's done via standard mGRE tunnels:
> >
> > interface Tunnel0
> > ip address 192.168.1.1 255.255.255.0
> > ip mtu 1440
> > ip nhrp authentication cisco123
> > ip nhrp map multicast dynamic
> > ip nhrp network-id 1
> > tunnel source FastEthernet0/0
> > tunnel mode gre multipoint
> > tunnel key 0
> > ip router isis 1
> >
> > -maybe "mpls ip" cmd. wouldn't work with mGRE Tunnel Int.
> >
> >
> > adam
> >
> >
> ___
> 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] Cat6500 odd arp behavior

[David Prall]

I'd say you don't have "mls qos" configured, which is required for CoPP.
But, don't go turning it on without researching your entire config. Because
all of sudden Trust will be disabled and everything will be remarked to DSCP
0 by default. At least that is how it used to be, think that is still true.

Nothing should be rate limiting ARP's, unless of course CoPP is being done
in SW and the CPU just can't get it done. Which it is being done in SW
without mls qos configured. I will assume that "sh proc cpu sort" shows
nothing. What about "remote command switch show proc cpu sort"

David

--
http://dcp.dcptech.com


> -Original Message-
> From: vinny_abe...@dell.com [mailto:vinny_abe...@dell.com]
> Sent: Thursday, January 24, 2013 3:31 PM
> To: d...@dcptech.com; and...@2sheds.de
> Cc: cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] Cat6500 odd arp behavior
> 
> Hi Andrew,
> 
> Rate-limiting arp in hardware on this platform was confusing when I
> researched it years ago. I remember finding conflicting information on
this
> list that seemed to contradict Cisco. I'll check out that link and revisit
that.
> Thanks.
> 
> 
> This is from one of the switches, but they both show identical output:
> 
> Switch1#show mls rate-limit usage
>  Rate Limiter Type Packets/s   Burst
>-   -   -
> Layer3 Rate Limiters:
>  RL# 0: Used
>  MTU FAILURE 100  10
>  RL# 1: Used
>  TTL FAILURE 100  10
>  RL# 2: Used
>ICMP REDIRECT 100  10
>  RL# 3: Used
>  UCAST IP OPTION 100  10
>  RL# 4: Used
>  MCAST IP OPTION 100  10
>  RL# 5: Used
>   IP RPF FAILURE 100  10
>ICMP UNREAC. NO-ROUTE 100  10
>ICMP UNREAC. ACL-DROP 100  10
>IP ERRORS 100  10
>  RL# 6: Used
> ACL VACL LOG2000   1
>  RL# 7: Used
>   MCAST DFLT ADJ  10 100
>  RL# 8: Rsvd for capture   -   -   -
> 
> Layer2 Rate Limiters:
>  RL# 9: Reserved
>  RL#10: Reserved
> MCAST PARTIAL SC  10 100
>  RL#11: Free   -   -   -
>  RL#12: Free   -   -   -
> 
> Switch1#show mls qos protocol
>  Modes: P - police, M - marking, * - passthrough
>  Module: All - all EARL slots;Dir: I&O - In & Out;   F - Fail
> 
>  Proto Mode Mod Dir AgId Prec CirBurst   AgForward-By
AgPoliced-By
>


> 
> 
> -Original Message-
> From: David Prall [mailto:d...@dcptech.com]
> Sent: Thursday, January 24, 2013 3:14 PM
> To: 'Andrew Miehs'; Abello, Vinny
> Cc: cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] Cat6500 odd arp behavior
> 
> What does "show mls rate-limit usage" show for GLEAN
> 
> What does "show mls qos protocol" show for ARP
> 
> "mls qos protocol police arp" is what you want to be using to rate limit
ARP
> requests at L2.
> 
> This white paper goes into the hardware rate-limiters, as well as CoPP on
> the 6500:
> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/whit
> e_paper
> _c11_553261.html
> 
> There could still be a bug, all the above testing was done with the latest
> SXH release.
> 
> David
> 
> --
> http://dcp.dcptech.com
> 
> 
> > -Original Message-
> > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> > boun...@puck.nether.net] On Behalf Of Andrew Miehs
> > Sent: Thursday, January 24, 2013 2:43 PM
> > To: 
> > Cc: 
> > Subject: Re: [c-nsp] Cat6500 odd arp behavior
> >
> > There is a problem with some dell machines and 4500s - this may be the
> > same issue. Try turning off PoE on the port of use the latest firmware
on
> the
> > dell.
> >
> >
> > Sent from a mobile device
> >
> > On 25/01/2013, at 5:01,  wrote:
> >
> > > Hi all,
> > >
> > > I've been having a reproducible problem across mul

Re: [c-nsp] Cat6500 odd arp behavior

[David Prall]

What does "show mls rate-limit usage" show for GLEAN

What does "show mls qos protocol" show for ARP

"mls qos protocol police arp" is what you want to be using to rate limit ARP
requests at L2.

This white paper goes into the hardware rate-limiters, as well as CoPP on
the 6500:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper
_c11_553261.html 

There could still be a bug, all the above testing was done with the latest
SXH release.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Andrew Miehs
> Sent: Thursday, January 24, 2013 2:43 PM
> To: 
> Cc: 
> Subject: Re: [c-nsp] Cat6500 odd arp behavior
> 
> There is a problem with some dell machines and 4500s - this may be the
> same issue. Try turning off PoE on the port of use the latest firmware on
the
> dell.
> 
> 
> Sent from a mobile device
> 
> On 25/01/2013, at 5:01,  wrote:
> 
> > Hi all,
> >
> > I've been having a reproducible problem across multiple Catalyst 6509
> switches running the same IOS 12.2(33)SXI4a for a while now that I just
can't
> nail down.
> >
> > In many situations where the switch is configured with an SVI on VLAN to
> function as a gateway, very often I find that I am unable to communicate
> with a newly added device or assigned IP on an existing device on that
> VLAN. No amount of probing it will appear to get it to respond. However,
if I
> am on the device itself where the IP is bound and just do a simple ping
out
> to something which has to traverse the SVI IP as a gateway, as long as the
> origin of the packet is the same IP, the switch then seems to learn the
MAC
> address properly and all is happy and continues to work from that point
> forward.
> >
> > Is there something that would prevent ARP from discovering these newly
> added devices when the switch would be soliciting the network segment
> for the MAC address for a certain IP? I was leaning towards bug... or I
have
> some unintended consequence due to the CoPP policy or rate-limiters on
> these switches which are also the same.
> >
> > I have the following mls rate limiters defined:
> >
> > mls rate-limit multicast ipv4 ip-options 100 10
> > mls rate-limit unicast ip options 100 10
> > mls rate-limit unicast ip icmp redirect 100 10
> > mls rate-limit all ttl-failure 100 10
> > mls rate-limit all mtu-failure 100 10
> >
> > I have policing on arp packets in CoPP (which I think if I remember is
done
> in software anyway), but I recall completely removing this and still
having
> the same issue.
> >
> > For reference, I'm doing in CoPP:
> >
> > class-map match-all CoPP_ARP
> >  match protocol arp
> >
> > policy-map CoPP
> > ...
> >  class CoPP_ARP
> >   police 800
> >  ...
> >
> > Thanks for any assistance or advice!
> >
> > -Vinny
> > ___
> > 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] ASR9k: BGP state = Idle (No route to multi-hop neighbor)

[David Prall]

What happens if you install a static /32. I believe that multi-hop requires
a /32 for the neighbor.

David

--
http://dcp.dcptech.com

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Jason Lixfeld
> Sent: Friday, December 28, 2012 4:58 PM
> To:  NSP
> Subject: [c-nsp] ASR9k: BGP state = Idle (No route to multi-hop neighbor)
> 
> Hi there,
> 
> 
> Unless I'm doing something really silly, I can't seem to get a multi-hop
ebgp
> session up on an ASR9k.  I'm wondering if anyone can spot something I
> might have overlooked or am just not aware of :
> 
> The neighbor reports:
> 
> BGP state = Idle (No route to multi-hop neighbor)
> 
> Which is odd because there is a route for this in the BGP table already.
It's
> pingable, etc.
> 
> RP/0/RSP0/CPU0:asr9k#show route vrf Inetv4 1.1.1.254
> Fri Dec 28 16:49:58.718 EST
> 
> Routing entry for 1.1.1.252/30
>   Known via "bgp 1", distance 200, metric 1, type internal
>   Installed Dec 21 16:54:49.859 for 6d23h
>   Routing Descriptor Blocks
> 2.2.2.2, from 3.3.3.3
>   Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id:
> 0xe000
>   Route metric is 1
>   No advertising protos.
> RP/0/RSP0/CPU0:asr9k#
> 
> !
> router bgp 1
>  vrf Inetv4
>   neighbor 1.1.1.254
>remote-as 65535
>ebgp-multihop 255
>update-source Loopback1
>ignore-connected-check
>address-family ipv4 unicast
> remove-private-AS
>!
>   !
>  !
> !
> 
> RP/0/RSP0/CPU0:asr9k#sh bgp vrf Inetv4 neighbors 1.1.1.254
> Fri Dec 28 16:47:11.630 EST
> 
> BGP neighbor is 1.1.1.254, vrf Inetv4
>  Remote AS 65535, local AS 1, external link
>  Remote router ID 0.0.0.0
>   BGP state = Idle (No route to multi-hop neighbor)
>   Last read 00:00:00, Last read before reset 00:00:00
>   Hold time is 180, keepalive interval is 60 seconds
>   Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
>   Last write 00:00:00, attempted 0, written 0
>   Second last write 00:00:00, attempted 0, written 0
>   Last write before reset 00:00:00, attempted 0, written 0
>   Second last write before reset 00:00:00, attempted 0, written 0
>   Last write pulse rcvd  not set last full not set pulse count 0
>   Last write pulse rcvd before reset 00:00:00
>   Socket not armed for io, not armed for read, not armed for write
>   Last write thread event before reset 00:00:00, second last 00:00:00
>   Last KA expiry before reset 00:00:00, second last 00:00:00
>   Last KA error before reset 00:00:00, KA not sent 00:00:00
>   Last KA start before reset 00:00:00, second last 00:00:00
>   Precedence: internet
>   Graceful restart is enabled
>   Restart time is 120 seconds
>   Stale path timeout time is 360 seconds
>   Enforcing first AS is enabled
>   Multi-protocol capability not received
>   Received 0 messages, 0 notifications, 0 in queue
>   Sent 0 messages, 0 notifications, 0 in queue
>   Minimum time between advertisement runs is 0 secs
> 
>  For Address Family: IPv4 Unicast
>   BGP neighbor version 0
>   Update group: 0.6 Filter-group: 0.0  No Refresh request being processed
>   eBGP neighbor with no inbound or outbound policy; defaults to 'drop'
>   Private AS number removed from updates to this neighbor
>   AF-dependent capabilities:
> Graceful Restart capability advertised
>   Local restart time is 120, RIB purge time is 600 seconds
>   Maximum stalepath time is 360 seconds
>   Route refresh request: received 0, sent 0
>   0 accepted prefixes, 0 are bestpaths
>   Cumulative no. of prefixes denied: 0.
>   Prefix advertised 0, suppressed 0, withdrawn 0
>   Maximum prefixes allowed 1048576
>   Threshold for warning message 75%, restart interval 0 min
>   An EoR was not received during read-only mode
>   Last ack version 0, Last synced ack version 0
>   Outstanding version objects: current 0, max 0
>   Additional-paths operation: None
> 
>   Connections established 0; dropped 0
>   Local host: 0.0.0.0, Local port: 0
>   Foreign host: 1.1.1.254, Foreign port: 0
>   Last reset 00:00:00
>   External BGP neighbor may be up to 255 hops away.
> RP/0/RSP0/CPU0:asr9k#
> 
> Thanks in advance.
> ___
> 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] Same multicast flow with multiple source

[David Prall]

Could the other 3 be keepalives. Don't know what the application is. Is your 
receiver sending to the group as well? Could be the primary address is 
advertising everything via an election process. The others are sending 
keepalives, if the primary goes away, then the next is elected based on some 
factor.

David

--
http://dcp.dcptech.com

-Original Message-
From: Riccardo S [mailto:dim0...@hotmail.com] 
Sent: Monday, December 17, 2012 12:52 PM
To: David Prall; cisco-nsp@puck.nether.net
Subject: R: RE: [c-nsp] Same multicast flow with multiple source

But as you see it seems that the application is the same (same group and same 
number of pkts received)... 
At least for three sources...

Tks

sent with android

David Prall  ha scritto:

>This is why it is called Any Source Multicast (ASM). A number of
>applications use the same group for discussions. Cisco's old IP/TV
>distributed over one group, then had a second group for feedback. So as you
>typed in a question it was sent to everyone.
>
>David
>
>--
>http://dcp.dcptech.com
>
>
>-Original Message-
>From: cisco-nsp-boun...@puck.nether.net
>[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Riccardo S
>Sent: Monday, December 17, 2012 12:03 PM
>To: cisco-nsp@puck.nether.net
>Subject: [c-nsp] Same multicast flow with multiple source
>
>
>
>
>I built up a PIM connection to a new multicast
>provider and I see this provider is sending the same mcast flow with some
>different sources:
>
> --
>
>xx#sh ip mroute 224.0.1.114 count 
>
>IP Multicast Statistics
>
>858 routes using 542426 bytes of
>memory
>
>705 groups, 0.21 average sources per
>group
>
>Forwarding Counts: Pkt
>Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second
>
>Other counts: Total/RPF failed/Other
>drops(OIF-null, rate-limit etc)
>
> 
>
>Group: 224.0.1.114, Source count: 4,
>Packets forwarded: 9106926, Packets received: 9106926
>
> 
>RP-tree: Forwarding: 31/0/37/0, Other: 31/0/0
>
> 
>Source: 172.16.89.2/32, Forwarding: 10994/0/30/0, Other: 10994/0/0
>
> 
>Source: 172.16.89.6/32, Forwarding: 10994/0/30/0, Other: 10994/0/0
>
> 
>Source: 172.16.89.3/32, Forwarding: 9073913/27/299/63, Other: 9073913/0/0
>
> 
>Source: 172.16.89.5/32, Forwarding: 10994/0/30/0, Other: 10994/0/0
>
>---
>
> 
>
>Questions:
>
>1)  From a conceptual point of view is it
>correct they send same feed with a lot of different sources ? Usually I
>always
>saw one A feed (with sourceA,GroupA) and one B feed (with sourceB,GroupB)...
>
>2)  Which can be the reason whether they
>send one flow with different pkt size (299Byte) and all the other with
>30byte
>pkt size ?
>
>3)  Since on my CPE I have static
>join towards the group in this way I'll get the flow four times with
>bandwidth
>exceeded ? Is there a method to us only one flow if identical to the others
>?
>
> 
>
>Tks
>
> 
>___
>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] Same multicast flow with multiple source

[David Prall]

This is why it is called Any Source Multicast (ASM). A number of
applications use the same group for discussions. Cisco's old IP/TV
distributed over one group, then had a second group for feedback. So as you
typed in a question it was sent to everyone.

David

--
http://dcp.dcptech.com


-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Riccardo S
Sent: Monday, December 17, 2012 12:03 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Same multicast flow with multiple source




I built up a PIM connection to a new multicast
provider and I see this provider is sending the same mcast flow with some
different sources:

 --

xx#sh ip mroute 224.0.1.114 count 

IP Multicast Statistics

858 routes using 542426 bytes of
memory

705 groups, 0.21 average sources per
group

Forwarding Counts: Pkt
Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second

Other counts: Total/RPF failed/Other
drops(OIF-null, rate-limit etc)

 

Group: 224.0.1.114, Source count: 4,
Packets forwarded: 9106926, Packets received: 9106926

 
RP-tree: Forwarding: 31/0/37/0, Other: 31/0/0

 
Source: 172.16.89.2/32, Forwarding: 10994/0/30/0, Other: 10994/0/0

 
Source: 172.16.89.6/32, Forwarding: 10994/0/30/0, Other: 10994/0/0

 
Source: 172.16.89.3/32, Forwarding: 9073913/27/299/63, Other: 9073913/0/0

 
Source: 172.16.89.5/32, Forwarding: 10994/0/30/0, Other: 10994/0/0

---

 

Questions:

1)  From a conceptual point of view is it
correct they send same feed with a lot of different sources ? Usually I
always
saw one A feed (with sourceA,GroupA) and one B feed (with sourceB,GroupB)...

2)  Which can be the reason whether they
send one flow with different pkt size (299Byte) and all the other with
30byte
pkt size ?

3)  Since on my CPE I have static
join towards the group in this way I'll get the flow four times with
bandwidth
exceeded ? Is there a method to us only one flow if identical to the others
?

 

Tks

  
___
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] Cisco command to see active session on "cisco WS-C6503-E (R7000)"

[David Prall]

Show tcp brief

--
http://dcp.dcptech.com


-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Samol
Sent: Wednesday, December 12, 2012 9:47 PM
To: Andrew Jones
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Cisco command to see active session on "cisco
WS-C6503-E (R7000)"

Hi Aj,

that command can do without having to enable this. its like the command
uses on windows "netstat?" so that see can see the active sessions which
are goung thru router.

Regards,
Sam
 On Dec 13, 2012 9:40 AM, "Andrew Jones" 
wrote:

> Ok, so you mean sessions going through the router?
>
> ** **
>
> You need netflow enabled on the switch, then enable "ip flow ingress"  and
> "ip flow egress" on the interface you are interested in, then perform a
> "show ip cache flow"
>
> ** **
>
> It will give you this info, but alot of it uses HEX codes you need to
> translate... (google is your friend)
>
> ** **
>
> Andrew Jones
>
> Alphawest | Optus Business
>
> ** **
>
> *From:* Samol [mailto:molas...@gmail.com]
> *Sent:* Thursday, 13 December 2012 1:25 PM
> *To:* Andrew Jones
> *Cc:* cisco-nsp@puck.nether.net
> *Subject:* Re: [c-nsp] Cisco command to see active session on "cisco
> WS-C6503-E (R7000)"
>
> ** **
>
> Hi AJ,
>
> ** **
>
> No, the output of this command shows us the source/Destinaion IP address
> using UDP or TCP etc. 
>
> ** **
>
> Regards,
>
> Sam
>
> ** **
>
> 2012/12/13 Andrew Jones 
>
> Do you mean to see who is logged into the cli?
>
> Try  "who"
>
> Andrew Jones
>
>
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:
> cisco-nsp-boun...@puck.nether.net] On Behalf Of Samol
> Sent: Thursday, 13 December 2012 12:57 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Cisco command to see active session on "cisco WS-C6503-E
> (R7000)"
>
> Hi All,
>
> I believe there is a command that we can use to see the active sessions
> on cisco WS-C6503-E (R7000), but somehow I can't remember what the command
> is. Pls let me know if you know this command.
>
> Regards,
> Sam
>
> ___
> 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] Change BGP default-originate to IGP?

[David Prall]

-Original Message-
From: Tom Lanyon [mailto:tom+c-...@oneshoeco.com] 

I'm glad a iBGP session between the ASRs over a GRE tunnel was mentioned, as
that's exactly what we have running and I was questioning whether this was a
bad practice or not...

Thanks,
Tom

[dprall] It's the Duct Tape of Networking

David

--
http://dcp.dcptech.com





___
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] Change BGP default-originate to IGP?

[David Prall]

As well could put a GRE Tunnel or VLAN between the two ASR's and run iBGP
between the two. You control the path between the two routers, so the tunnel
can be over a jumbo frame capable path. I would still do a selective
advertisement for the default, so that traffic doesn't need to traverse the
both routers, but this would stop the blackholes for routes unlearned.
Especially if it is the upstream that is having issues, instead of the
direct connection.

David

--
http://dcp.dcptech.com


-Original Message-
From: Adam Vitkovsky [mailto:adam.vitkov...@swan.sk] 
Sent: Thursday, September 27, 2012 4:41 AM
To: 'Tom Lanyon'; 'David Prall'; 'cisco-nsp'
Subject: RE: [c-nsp] Change BGP default-originate to IGP?

So if I understood it correctly you are concerned that the router will start
to originate the default prior to receiving full BGP table from its upstream
right?
The simplest solution would be to place a static default route pointing to
the upstream -so in case of the above happens the router wouldn't blackhole
till it gets the full feed. 
Or you can base the condition of default advertisement on several prefixes
from all around the place instead of just one -but trying to match e.g. 10
prefixes from 400k well...
The problem with this though is that on IOS you can't AND the "match ip
address" statements under the route-map only OR -applies to all the match
statements of the same kind. 
So you could use static routes for the list of desired prefixes each with a
high AD -redistribute them into bgp with specific community and match for
the prefixes+community in "non-exist map". 
So once you'll get all the prefixes from BGP -only after all cease to exist
in the bgp table with the specific community of yours -the router will start
to advertise the default route. 

adam
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tom Lanyon
Sent: Thursday, September 27, 2012 4:58 AM
To: David Prall; cisco-nsp
Subject: Re: [c-nsp] Change BGP default-originate to IGP?

Is there a specific order in which BGP updates are sent/exchanged/processed?

The concern I have with tracking upstream routes is that the route tracked
would need to be one of the last routes received (if not the last) to ensure
that the router has full visibility.  This seems quite non-deterministic and
so potentially fraught with 'weirdness'.

Thanks,
Tom

On 27/09/2012, at 12:19 PM, David Prall wrote:
> Why not use selective advertisement of the default based on receiving 
> a specific route from your carrier or an upstream you know to be stable.
> 
> http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2
> _n1g.h
> tml#wp1037042
> 
> 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] Change BGP default-originate to IGP?

[David Prall]

Why not use selective advertisement of the default based on receiving a
specific route from your carrier or an upstream you know to be stable. 

http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2_n1g.h
tml#wp1037042

David

--
http://dcp.dcptech.com

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tom Lanyon
Sent: Wednesday, September 26, 2012 10:04 PM
To: cisco-nsp
Subject: [c-nsp] Change BGP default-originate to IGP?

Hi list,

In an enterprise network I have a core of 4900Ms with a few ASR1ks hanging
off to handle upstream connectivity.  As an example:

Upstream1 - [ASR1k]--[4900M]--[4900M]--[ASR1k] - Upstream2
||
||
ServersWorkstations, etc


The ASRs and 4900Ms are running BGP and ISIS with full tables on the ASRs
and mostly just defaults on the 4900Ms.  The ASRs are originating defaults
via BGP but on reload they are blackholing traffic whilst BGP converges.

I've seen that OSPF and ISIS have 'wait-for-bgp' overload bits available and
have been questioning whether switching to an IGP-generated default with
wait-for-bpg is the correct solution here.  Any thoughts?

Thanks,
Tom


___
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] MSDP and my limited knowledge question

[David Prall]

PIM is running between the two systems or you have a static mroute
configured. What does "sh ip rpf 10.10.10.1"

David

--
http://dcp.dcptech.com


-Original Message-
From: Mihai Tanasescu [mailto:mi...@duras.ro] 
Sent: Monday, September 03, 2012 3:32 PM
To: David Prall
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] MSDP and my limited knowledge question

On 9/3/12 9:02 PM, David Prall wrote:
> You're using a GLOP group, so you are AS number 57370?
>
> You do have "ip pim rp-address 192.168.1.2" configured? I am assuming the
> 192.168.1.2 is the MSDP source-address and the BGP source-address.
Yes, that's configured.
This issue only happens when that subnet is not directly connected on 
the interface toward the source and when I have a static route toward it.
I can also see that my source is sending the stream (it is a Linux that 
I use for testing and as such I can easily do a tcpdump).

>
> David
>
> --
> http://dcp.dcptech.com
>
>
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mihai Tanasescu
> Sent: Monday, September 03, 2012 2:13 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] MSDP and my limited knowledge question
>
> Hi all,
>
> I have a simple test setup where I'm most likely failing to do something
> right.
>
> It basically looks like this:
>
> My PC --- CPE --- L3 transport network not under my control  -- their
> router (MSDP + BGP + RP here)  ( MSDP+ BGP + RP here) C4900
> (192.168.1.1) -- (192.168.1.2) - multicast source (S)
>
> I announce (and originate on the C4900) through BGP the multicast
> sources subnet let's call it: 10.10.10.0/29 which I send to my provider
> (along with the RP/MSDP IP).
> MSDP peers are up, everything seems ok.
>
> a) if I put the 10.10.10.0/29 class as directly connected (between C4900
> and S) instead of the 192.168.1.1 and 192.168.1.2 from above -> all
> works ok and I can view the stream on my PC with VLC.
>
> I also see:
>
> (10.10.10.1, 233.224.26.1), 00:00:09/00:02:58, flags: PTA
> Incoming interface: GigabitEthernet1/48, RPF nbr 0.0.0.0
> Outgoing interface list: Null
>
> b) if I put:
> 10.10.10.1/29 or /32 configured on S on a Loopback interface
> and on C4900:
> ip route 10.10.10.0 255.255.255.240 192.168.1.2
>
> then I only have:
>
> (10.10.10.1, 233.224.26.1), 00:00:05/00:02:57, flags: PT
> Incoming interface: GigabitEthernet1/48, RPF nbr 192.168.1.2
> Outgoing interface list: Null
>
> the A flag - MSDP Adv candidate is missing
> and if I do a: show ip msdp peer  advertise-sa, then I see
nothing.
>
> What am I missing ?
> Am I running into any check that I am failing ?
>
> Can you help me out ?
> This subject is quite new to me.
>
> Thanks,
> Mihai
>
> ___
> 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] MSDP and my limited knowledge question

[David Prall]

You're using a GLOP group, so you are AS number 57370?

You do have "ip pim rp-address 192.168.1.2" configured? I am assuming the
192.168.1.2 is the MSDP source-address and the BGP source-address.

David

--
http://dcp.dcptech.com


-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mihai Tanasescu
Sent: Monday, September 03, 2012 2:13 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] MSDP and my limited knowledge question

Hi all,

I have a simple test setup where I'm most likely failing to do something 
right.

It basically looks like this:

My PC --- CPE --- L3 transport network not under my control  -- their 
router (MSDP + BGP + RP here)  ( MSDP+ BGP + RP here) C4900 
(192.168.1.1) -- (192.168.1.2) - multicast source (S)

I announce (and originate on the C4900) through BGP the multicast 
sources subnet let's call it: 10.10.10.0/29 which I send to my provider 
(along with the RP/MSDP IP).
MSDP peers are up, everything seems ok.

a) if I put the 10.10.10.0/29 class as directly connected (between C4900 
and S) instead of the 192.168.1.1 and 192.168.1.2 from above -> all 
works ok and I can view the stream on my PC with VLC.

I also see:

(10.10.10.1, 233.224.26.1), 00:00:09/00:02:58, flags: PTA
   Incoming interface: GigabitEthernet1/48, RPF nbr 0.0.0.0
   Outgoing interface list: Null

b) if I put:
10.10.10.1/29 or /32 configured on S on a Loopback interface
and on C4900:
ip route 10.10.10.0 255.255.255.240 192.168.1.2

then I only have:

(10.10.10.1, 233.224.26.1), 00:00:05/00:02:57, flags: PT
   Incoming interface: GigabitEthernet1/48, RPF nbr 192.168.1.2
   Outgoing interface list: Null

the A flag - MSDP Adv candidate is missing
and if I do a: show ip msdp peer  advertise-sa, then I see nothing.

What am I missing ?
Am I running into any check that I am failing ?

Can you help me out ?
This subject is quite new to me.

Thanks,
Mihai

___
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] HSRPv1 and HSRPv2

[David Prall]

Just turn on v2, v4 and v6 will require distinct id's. When you first turn
on v2 on a single router, the two will stop talking so be prepared for the
outage on v4.

David

--
http://dcp.dcptech.com


-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gmail
Sent: Friday, August 17, 2012 8:33 PM
To: Nsp
Subject: [c-nsp] HSRPv1 and HSRPv2

Hi Experts,

Understood that such question need to real test in the lab, but don't have
same series equipment so far, so...
Does anybody have any experience to configure the HSRPv1 and HSRPv2 in 7609,
the thing is the current network just deploy IPv4 service, running some
sub-interface with HSRPv1, now we want to load the IPv6 service with
dual-stack for such interfaces. 
My question is can we just use the same sub-interface which combine HSRPv1
and HSRPv2 service? Or we must use new different sub-interface? Or new
physical interface?

Thanks and regards,
HuXu

Sent from my iPad
___
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] HSRPv1 and HSRPv2

[David Prall]

Of course, how else would you run HSRP for dual-stacked servers.

--
http://dcp.dcptech.com


-Original Message-
From: Gmail [mailto:jstuxuhu0...@gmail.com] 
Sent: Friday, August 17, 2012 9:20 PM
To: David Prall
Cc: Nsp
Subject: Re: [c-nsp] HSRPv1 and HSRPv2

Thanks for your replay. 

So you mean the configuration can be done in the same interface?
V4 and V6 require distinct Id means the group number is in different range?
Sent from my iPad

On 2012-8-18, at 9:13, "David Prall"  wrote:

> Just turn on v2, v4 and v6 will require distinct id's. When you first turn
> on v2 on a single router, the two will stop talking so be prepared for the
> outage on v4.
> 
> David
> 
> --
> http://dcp.dcptech.com
> 
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gmail
> Sent: Friday, August 17, 2012 8:33 PM
> To: Nsp
> Subject: [c-nsp] HSRPv1 and HSRPv2
> 
> Hi Experts,
> 
> Understood that such question need to real test in the lab, but don't have
> same series equipment so far, so...
> Does anybody have any experience to configure the HSRPv1 and HSRPv2 in
7609,
> the thing is the current network just deploy IPv4 service, running some
> sub-interface with HSRPv1, now we want to load the IPv6 service with
> dual-stack for such interfaces. 
> My question is can we just use the same sub-interface which combine HSRPv1
> and HSRPv2 service? Or we must use new different sub-interface? Or new
> physical interface?
> 
> Thanks and regards,
> HuXu
> 
> Sent from my iPad
> ___
> 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] Network Security.

[David Prall]

DHCP servers could care less about who you are. They will give out an
address to just about anyone. Now MBA or  802.1x authentication can be used
to block this. With MBA or 802.1x you could place the authenticated users in
to a different vlan, where all of your domain related information resides.
Then you could use a web based auth mechanism on the router, that is linked
to credentials, in order to require for external access they have a user id
and password.

David

--
http://dcp.dcptech.com



-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rich Trinkle
Sent: Tuesday, March 06, 2012 10:22 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Network Security.

I apologize if this seems like a "rookie" question.  A colleague and I have
a stance that neither want to budge on. We have a cisco 861w core router for
our internal network and a typical domain server/client access. All of our
internal pc's are part of this domain and our client pc's obtain a dynamic
ip from an internal dhcp server. The question is this. Should I be able to
take a personal laptop that is not setup on our domain, plug into our
network, obtain an ip address dynamically through our cisco router and
browse the internet?


-Original message-
From: Zach Williams 
To: "cisco-nsp@puck.nether.net" 
Sent: Wed, Mar 7, 2012 03:02:08 GMT+00:00
Subject: [c-nsp] Question on the Use of Policy Based Routing

Hello.  I have a question regarding the use of policy based routing.  I've
always thought of it as a way to selectively change routing in exceptional
circumstances.

I've come across an implementation where it is being used to explicitly set
a next-hop ip for 99% of all traffic headed from an application behind a
pair of of stacked 3750s.  The default route on these layer 3 switches is
set to a 192.168.x.x IP which is part of a management network.  The PBR is
in place to send the outbound application traffic towards a firewall and
out to the internet.

Part of the reasoning for doing this was because the application will
require only a few separate class C's and the management network has many
more routes.  A route-map matching an access-list or prefix-list for the
basis of PBR on the outbound application traffic would contain fewer lines
of configuration and thus it was deemed more elegant to set up PBR for the
application traffic rather than the management traffic.

I'm having a tough time finding best-practices information on the use of
PBR and was wondering what cisco-nsp thought of this setup.
___
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] Question on the Use of Policy Based Routing

[David Prall]

The PBR performance on the 3K is wonderful if you only need it for a few
Mbps. I would always recommend routing over PBR, unless there is just no
other way. My house I use PBR so that certain servers return to the correct
Internet Connection Symmetrically and are NAT'd and Firewalled correctly. I
would review the management traffic requirements, and use ip local policy
route-map for that instead. Perhaps all management traffic is sourced from
the loopback, therefore the policy will only be a single /32.

David

--
http://dcp.dcptech.com


-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Zach Williams
Sent: Tuesday, March 06, 2012 9:55 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Question on the Use of Policy Based Routing

 Hello.  I have a question regarding the use of policy based routing.  I've
always thought of it as a way to selectively change routing in exceptional
circumstances.

I've come across an implementation where it is being used to explicitly set
a next-hop ip for 99% of all traffic headed from an application behind a
pair of of stacked 3750s.  The default route on these layer 3 switches is
set to a 192.168.x.x IP which is part of a management network.  The PBR is
in place to send the outbound application traffic towards a firewall and
out to the internet.

Part of the reasoning for doing this was because the application will
require only a few separate class C's and the management network has many
more routes.  A route-map matching an access-list or prefix-list for the
basis of PBR on the outbound application traffic would contain fewer lines
of configuration and thus it was deemed more elegant to set up PBR for the
application traffic rather than the management traffic.

I'm having a tough time finding best-practices information on the use of
PBR and was wondering what cisco-nsp thought of this setup.
___
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] mVPN with 2811PE

[David Prall]

MDT didn't come around till later. Upgrade the code to a 124T release for
MDT support. Need MDT support for SSM support of the Data groups, otherwise
you don't need MDT. But, then you are stuck with ASM or the default group
only.

David

--
http://dcp.dcptech.com



-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Henry Huaman
Sent: Thursday, February 23, 2012 12:48 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] mVPN with 2811PE
Importance: High

Hi,

Currently we are testing mVPN with 2811 (ios 124-25b)  like PE.

And we see these issues:

-  The configuration don´t have “address-family ipv4 mdt” command.

-  The 2811 don´t response to ping (group multicast)  ( 2811 with
igmp join)

-  We don´t see the “interface Tunnel” associate with the VRF
(2811#show ip vrf interface VRF)

 

Is valid this behavior? Or maybe we could to change this version?

 

Thx

 

Henry

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


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

Re: [c-nsp] www.ipv6.cisco.com down for 5+ days

[David Prall]

Frank,
Might try http://www-v6.cisco.com as well. 

David

--
http://dcp.dcptech.com



-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Frank Bulk
Sent: Saturday, January 07, 2012 4:00 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] www.ipv6.cisco.com down for 5+ days

I sent an email to the only NOC email address I could find for Cisco, but it
hasn't made a difference.

www.ipv6.cisco.com has been down since Sunday:
nagios:/usr/lib/nagios/plugins# wget www.ipv6.cisco.com
--2012-01-07 14:58:55--  http://www.ipv6.cisco.com/
Resolving www.ipv6.cisco.com... 2001:420:80:1::5
Connecting to www.ipv6.cisco.com|2001:420:80:1::5|:80... connected.
HTTP request sent, awaiting response... 503 Service Unavailable
2012-01-07 14:58:55 ERROR 503: Service Unavailable.

nagios:/usr/lib/nagios/plugins#

It pings just fine.

If anyone from Cisco is lurking could they reach out to the NOC or IT staff?

Regards,

Frank Bulk

___
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] channel fails when using sup 10g port ?

[David Prall]

Is QoS configured? Have to configure qos inconsistency, "no mls qos
channel-consistency"

David

--
http://dcp.dcptech.com



-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Chuck Church
Sent: Thursday, January 05, 2012 1:13 PM
To: 'Jeffrey G. Fitzwater'
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] channel fails when using sup 10g port ?

Show int capability might shed some light on what the interface differences
are.

Chuck


-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeffrey G. Fitzwater
Sent: Thursday, January 05, 2012 11:55 AM
To: Andrew Miehs
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] channel fails when using sup 10g port ?

I really have to understand why the 16A channel gets built.

All the trunking and port configs are correct. If they were wrong the logs
"should" show me what was broke.  Santa checked his list twice, I did it 10
times.


I do have the same config working, using a sup 10g port on another router as
a channel member, but it connects to nexus 7018.
In the broken case, both ends use a sup10g port and another X6708 port, but
they are not paired to same type at other end (sup-10g to sup-10g) vs
(sup-10g to X6708-10g ) not that it should matter.

So the only unique thing, is both ends are sup-720-10g in the broken case.
Its not the LACP proto since I tried  MODE ON with same problem.
What is also odd is when I disable one port of the channel, and do the "show
ether channel 16 summ", only the 16 is present with both port (one DOWN).
the 16A is gone.
As soon was I enable the other port the 16A shows up.

Whats odd is there is nothing in the log telling why the channel did not
come up correctly instead of this 16 and 16A .

Could it have something to do with using both 10G ports on the same sup, but
for different functions? One is for this channel the other is just an access
port.

Jeff

On Jan 5, 2012, at 10:48 , Andrew Miehs wrote:

Hi Jeff,

On Thu, Jan 5, 2012 at 1:12 PM, Jeffrey G. Fitzwater
mailto:jf...@princeton.edu>> wrote:
I am trying to use the sup720-10G  10g port and another 10g port on a
6708-10G module as an ether-channel pair.

...
Group  Port-channel  ProtocolPorts
--+-+---+---

16 Po16(SU)LACP  Te13/1(P)
16 Po16A(SU)   LACP  Te7/4(P)

---

I do not see this issue on a SXI5 box - see below.

You may want to try:

default interface Te13/1
default interface Te7/4

no inter port16
no inter port16a

interface Te13/1
channel-group 16 mode passive
interface Te7/4
channel-group 16 mode passive

- and then see what "show etherchannel summary" outputs...


 example config

gv(config-if)#do show etherch summary
Flags:  D - downP - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3  S - Layer2
U - in use  N - not in use, no aggregation
f - failed to allocate aggregator

M - not in use, no aggregation due to minimum links not met
m - not in use, port not aggregated due to minimum links not met
u - unsuitable for bundling
d - default port

w - waiting to be aggregated
Number of channel-groups in use: 1
Number of aggregators:   1

Group  Port-channel  ProtocolPorts
--+-+---+---

16 Po16(RD)LACP  Te4/16(D)  Te6/5(D)

gv(config-if)#

interface TenGigabitEthernet4/16
 shutdown
 channel-group 16 mode passive
end

interface TenGigabitEthernet6/5
 shutdown
 channel-group 16 mode passive
end

gv#show version | i SX
Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-M),
Version 12.2(33)SXI5, RELEASE SOFTWARE (fc2)
ROM: System Bootstrap, Version 12.2(17r)SX7, RELEASE SOFTWARE (fc1)
System image file is
"sup-bootdisk:s72033-advipservicesk9_wan-mz.122-33.SXI5.bin"
gv#



___
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] 1G (SFP) single-mode aggregation

[David Prall]

Peter,
The 6513E can't support Fabric Enabled Modules in the secondary Supervisor
slot, so you only get 11 6748/6848's.

The 4640-CSFP-E is not supported in the 4510. So you would get 5 per 4506/7,
using the CSFP optics 80 ports per slot.

David

--
http://dcp.dcptech.com



-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Peter Rathlev
Sent: Thursday, December 15, 2011 8:45 AM
To: cisco-nsp
Subject: [c-nsp] 1G (SFP) single-mode aggregation

We've been asked to look at how one could best cram a fair amount of SFP
links into not too much space. They are downlinks to FTTO switches. When
going full scale we're talking about maybe 2500 FTTO switches.

So the question is: How many (1G) SFP switchports can one hope to
terminate in a standard rack? And what is the smartest/cheapest/easiet
way to do it?

We've been looking at the things described further down. Any better
ideas than those? If anybody has good experience with non-Cisco
equipment I'd also love to hear about it. And if the idea of aggregating
as much as possible in a single rack is stupid, please tell me. :-)

- One rack holds two 6513E (20RU), each with 12 WS-X6748-SFP cards and
one supervisor, probably Sup2T. That's 1152 ports per standard 42RU
rack. The supervisor uplinks ports would be configured as 2*10G
port-channel, resulting in 20G uplink bandwidth per unit and thus about
120:1 total oversubscription, since each FTTO switch has 4 downlink
ports. Power budget would seem to be around 8 kW per rack if the numbers
from "show power" are used. (Anyone know what the real consumption is?)

- One rack holds 8 6504E (5RU), each with 3 WS-X6748-SFP cards and one
supervisor. That's also 1152 ports per rack. Using just one uplink would
result in about 60:1 oversubscription. This is more expensive, both
capex and power consumption, and somewhat more complicated. And we don't
really think that 60:1 is needed. A similar power budget of 8 kW seems
like a reasonable guess.

- One rack holds 40 WS-C3750X-24S (1RU). That's 960 ports per rack. We
would use them as 5 stacks of 8 members, each with one 2*10G MC
etherchannel as uplink, resulting in a total 80:1 oversubscription. The
power budget would also be around 8 kW, though for the 3750X Cisco
supplies the actual expected consumption with 100% load as around 110 W,
resulting in an expected consumption of 4.4 kW.

- We've also tried looking at the 4500E series, which we don't know much
about. I cannot seem to find any E-model 48 port SFP cards, only the
WS-X4448-GB-SFP which must have just a 6 GB/s fabric connection. There's
the WS-X4640-CSFP-E, which combined with the BX SFPs could deliver 80
"ports" per slot. One might shoehorn three 4710R+E (14RU each) into a
42RU rack, resulting in 1920 ports per rack. Total oversubscription
would be around 128:1.

Thank you.

-- 
Peter


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

___
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] OER Question

[David Prall]

Which CCIE Lab book is this?

Have you looked at the PfR doc-wiki page?

--
http://dcp.dcptech.com



-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of M K
Sent: Tuesday, December 06, 2011 7:00 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] OER Question


Hi all,

i have the below OER question
i have been trying since a while but i am not sure about the solution
can anyone please help ?
Configure R4 to be the master controller and R1 and R2 to be the Border
routers.
The OER implementation should be optimized such that when the
packets with a DSCP of 41 is passing through the network, it is routed out
to
R1 exit interface and also, when a DSCP of 31 is passing through, it is
routed
out to R2 exit interface.
You are allowed to create extended ACL with one entry to accomplish this
task.
Set active probes only
For traffic going from Vlan 44 to YY.YY.55.5, set jitter as 40, delay as 20,
probe frequency as 2.
Enable constant probe via all exit interfaces.

R5 -- SW2 -- SW1 -- R1 F0/0 
R1 S0/0 -- R4 S0/0 , R4 S0/1 -- R2 S0/0
R2 F0/0 -- SW4 -- SW3
all the switches are trunk interconnected

Thanks in advance


  
___
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] Multicast question

[David Prall]

Found this via a quick search:
http://www.cisco.com/en/US/docs/ios/12_4t/ip_mcast/configuration/guide/mctls
plt.html

I was thinking about 2 distinct RP addresses, using spt-threshold infinity
so it stays on the shared tree, and having the route to the RP preferred
over one link. Hopefully the above is better than my quick thoughts.

David

--
http://dcp.dcptech.com



-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of henrry huaman
Sent: Monday, December 05, 2011 9:13 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Multicast question

Hi Guys,
We have the next scenary:

R1- e0/0---e0/0- R2
     \ e0/1---e0/1--/

And, we want to have differents groups multicast passing by its own path.

Is possible to configure any feature "PBR" with multicast?

R1  e0/0 --- only group 239.32.32.32 e0/0  R2
R1 e0/1 --- only group 239.33.33.33e0/1 R2

Thanks.



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


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

Re: [c-nsp] Conditionnal routing based on OSPF / IP SLA

[David Prall]

Your static route is the same as a connected interface. Connected always
beats static. You don't have any redistribution or network statements
defined under router bgp, so how is this network getting installed, so it
can be advertised to the neighbor? R2 has the same interface connected, you
are using the same subnet on both R1 and R2. R2 has a network statement
defined, so R2 advertises it to R1 and R3. R1 has the same interface
connected. I'd write an EEM script that tracks this particular route, if the
route goes away no shut the serial interface. Don't know why you would want
to do this on a serial interface and have both up at the same time. If it is
switching gear outside the routers that will flip it over, then the serial
interface should be down until that happens.

David

--
http://dcp.dcptech.com



-Original Message-
From: Henry-Nicolas Tourneur [mailto:hntourn...@autempspourmoi.be] 
Sent: Wednesday, November 30, 2011 4:11 AM
To: 'David Prall'; cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] Conditionnal routing based on OSPF / IP SLA

Hi David,

Actually I do not want to track the interface status but ensure that a ping
is working.
This is because the router will not be directly connected to the router to
monitor.

Here's a quick overview of the lab setup:

Se0/1:0Se0/1:0
\  |
 \ |
  R1 --1000--- R2
   \  /  
\/
 101000 
  \/
   \  /
  R3

3 routers connected using OSPF with the specified costs and a full mesh BGP
network.
I want R1 to stop announcing route to se0/1:0 IP range when the IP address
of R2 (10.0.1.2) can't be pinged anymore.
At that time, the traffic destinated to that range should go to R2.

You can find the results of show track when the IP address is reachable or
not in attachment (R1_commands).
Also the config of each router is in attachment.

Thanks for your help,

-----Original Message-
From: David Prall [mailto:d...@dcptech.com]
Sent: mardi 29 novembre 2011 15:02
To: 'Henry-Nicolas Tourneur'; cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] Conditionnal routing based on OSPF / IP SLA

So why not just track the interface status? The static should go away if the
interface goes down? What does "sh track" show you? On your track object, I
always use state instead of reachability.

The following should accomplish what you are trying to do. If se0/1:0 is
down then it won't be advertised.
ip route 17.4.240.40 255.255.255.240 Se0/1:0 10.0.1.2 tag 1755

David

--
http://dcp.dcptech.com



-Original Message-
From: Henry-Nicolas Tourneur [mailto:hntourn...@autempspourmoi.be]
Sent: Tuesday, November 29, 2011 3:30 AM
To: 'David Prall'; cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] Conditionnal routing based on OSPF / IP SLA

Hello David,

I tried the following, pretty straightforward setup.
I'v a full mesh iBGP running on 3 lab routers and OSPF between them (simple
triangle).

The IP to be checked is on a /30 in between R1 & R2, when this go down, I
want R1 to stop announcing the ip route (should disappear on R3).
The tag 1755 is to force the route to be advertised through iBGP and not
OSPF.

If the IP to be checked goes down, I can see that the SLA Monitor status
goes to down but yet, R1 keep advertising the route.

Any idea why? 

ip sla monitor 1
 type echo protocol ipIcmpEcho 10.0.1.2
 timeout 800
 frequency 2
!

ip sla monitor schedule 1 life forever start-time now track 100 rtr 1
reachability

ip route 17.4.240.40 255.255.255.240 Se0/1:0 tag 1755 track 100

Thanks in advance :)

Henry-Nicolas Tourneur.


-Original Message-
From: David Prall [mailto:d...@dcptech.com]
Sent: jeudi 24 novembre 2011 19:20
To: 'Henry-Nicolas Tourneur'; cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] Conditionnal routing based on OSPF / IP SLA

You can do this with track objects and static routing, then redistribute the
static into ospf. You could use a conditional route-map like they do in the
example for default as well. But I think putting a static in and
redistributing it will be much easier.

David

--
http://dcp.dcptech.com



-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Henry-Nicolas
Tourneur
Sent: Thursday, November 24, 2011 10:28 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Conditionnal routing based on OSPF / IP SLA

Hi all,

 

I'm currently trying to make a Cisco router to announce one network
statement based on the result of an IP Sla probe.

Currently, I found this tutorial:

 

http://hackingcisco.blogspot.com/2011/03/lab-33-ospf-conditional-default-rou
ting.html

 

But it's only for "default-information", I would need this for a particular
route.

 

Does anybody have an idea how to do this?

 

Thanks and regards,

Re: [c-nsp] Conditionnal routing based on OSPF / IP SLA

[David Prall]

So why not just track the interface status? The static should go away if the
interface goes down? What does "sh track" show you? On your track object, I
always use state instead of reachability.

The following should accomplish what you are trying to do. If se0/1:0 is
down then it won't be advertised.
ip route 17.4.240.40 255.255.255.240 Se0/1:0 10.0.1.2 tag 1755

David

--
http://dcp.dcptech.com



-Original Message-
From: Henry-Nicolas Tourneur [mailto:hntourn...@autempspourmoi.be] 
Sent: Tuesday, November 29, 2011 3:30 AM
To: 'David Prall'; cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] Conditionnal routing based on OSPF / IP SLA

Hello David,

I tried the following, pretty straightforward setup.
I'v a full mesh iBGP running on 3 lab routers and OSPF between them (simple
triangle).

The IP to be checked is on a /30 in between R1 & R2, when this go down, I
want R1 to stop announcing the ip route (should disappear on R3).
The tag 1755 is to force the route to be advertised through iBGP and not
OSPF.

If the IP to be checked goes down, I can see that the SLA Monitor status
goes to down but yet, R1 keep advertising the route.

Any idea why? 

ip sla monitor 1
 type echo protocol ipIcmpEcho 10.0.1.2
 timeout 800
 frequency 2
!

ip sla monitor schedule 1 life forever start-time now
track 100 rtr 1 reachability

ip route 17.4.240.40 255.255.255.240 Se0/1:0 tag 1755 track 100

Thanks in advance :)

Henry-Nicolas Tourneur.


-Original Message-
From: David Prall [mailto:d...@dcptech.com] 
Sent: jeudi 24 novembre 2011 19:20
To: 'Henry-Nicolas Tourneur'; cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] Conditionnal routing based on OSPF / IP SLA

You can do this with track objects and static routing, then redistribute the
static into ospf. You could use a conditional route-map like they do in the
example for default as well. But I think putting a static in and
redistributing it will be much easier.

David

--
http://dcp.dcptech.com



-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Henry-Nicolas
Tourneur
Sent: Thursday, November 24, 2011 10:28 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Conditionnal routing based on OSPF / IP SLA

Hi all,

 

I'm currently trying to make a Cisco router to announce one network
statement based on the result of an IP Sla probe.

Currently, I found this tutorial:

 

http://hackingcisco.blogspot.com/2011/03/lab-33-ospf-conditional-default-rou
ting.html

 

But it's only for "default-information", I would need this for a particular
route.

 

Does anybody have an idea how to do this?

 

Thanks and regards,

 

Henry-Nicolas Tourneur.

___
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] Conditionnal routing based on OSPF / IP SLA

[David Prall]

You can do this with track objects and static routing, then redistribute the
static into ospf. You could use a conditional route-map like they do in the
example for default as well. But I think putting a static in and
redistributing it will be much easier.

David

--
http://dcp.dcptech.com



-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Henry-Nicolas
Tourneur
Sent: Thursday, November 24, 2011 10:28 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Conditionnal routing based on OSPF / IP SLA

Hi all,

 

I'm currently trying to make a Cisco router to announce one network
statement based on the result of an IP Sla probe.

Currently, I found this tutorial:

 

http://hackingcisco.blogspot.com/2011/03/lab-33-ospf-conditional-default-rou
ting.html

 

But it's only for "default-information", I would need this for a particular
route.

 

Does anybody have an idea how to do this?

 

Thanks and regards,

 

Henry-Nicolas Tourneur.

___
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] MPLS - MP-BPG with multiple OSPF areas

[David Prall]

Livio,
As Adam stated, I was thinking of prefix-suppression in the context of using
a single Area. Or perhaps minimizing the number of ABR's.

If you still want to break your network up into multiple areas. You might
want to deploy P's that are the ABR, while all PE's are in areas other than
0. Therefore all traffic between PE's will be inter-area via area 0 or
intra-area. So no traffic is directly destined to Area 0.

David

--
http://dcp.dcptech.com


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

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

[David Prall]

Livio,
Where are you getting out of order packets? You do have asymmetric hop
counts, which most likely means asymmetric latency. But all the packets
should be in order. Could use DWDM so that each router isn't directly
connected and everything looks the same number of hops away, of course more
ports are required at the Area 10 edge.

You can use prefix-suppression to only advertise the loopback using OSPF, to
minimize the number of LSA's. Then use MPLS and BGP for all packet
forwarding, including the global table.

David

--
http://dcp.dcptech.com


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


___
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] Advertising connected subnet in BGP (more specific) - design advise needed

[David Prall]

Frank,
I just played with this and it appears to be working for me:
ip route vrf C1 172.16.1.0 255.255.255.128 GigabitEthernet 0/0 0.0.0.0

I do not have a default route in the table with my configuration.

David

--
http://dcp.dcptech.com

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Frank Volf
> Sent: Tuesday, October 18, 2011 8:36 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Advertising connected subnet in BGP (more specific) -
> design advise needed
> 
> 
> Hi All,
> 
> I need some suggestions for solving this problem I'm having.
> 
> I have a subnet 172.16.1.0/24 (that is stretched over two datacenters)
> and that is directly connected to two CE routers A and B.
> 
> The CE routers advertise the subnet in BGP towards the WAN, but for
> load-balancing reasons they do not only advertise 127.16.1.0/24, but
> also 172.16.1.0/25 (router A) and 172.16.1.128/25 (router B).
> 
> So, from the WAN traffic is load-balanced (assuming proper distribution
> of the server IP's in the subnet half of the servers are reached via CE
> A and half of the servers are reached via CE B) and if the primary path
> fails the /25 is removed from BGP and the /24 takes over the routing
> over the other CE.
>  From the LAN point of view, there are two VRRP groups, one being the
> master on router A and one master on router B (with some tracking on
> the
> uplink).
> 
> Summarizing, the (simplified) config looks like:
> 
> interface GigabitEthernet0/0
>ip address 172.16.1.2 255.255.255.0
>vrrp 10 ip 172.16.1.1
>vrrp 10 prio 110
>vrrp 10 track 10 decrement 30
>vrrp 20 ip 172.16.1.254
>vrrp 20 prio 90
>vrrp 20 track 10 decrement 30
> 
> ip route 172.16.1.0 255.255.255.128  GigabitEthernet0/0
> 
> router bgp 65001
> neighbor 192.168.1.1 remote-as 65000
> network 172.16.1.0 mask 255.255.255.0
> network 172.16.1.0 mask 255.255.255.128
> 
> And this works fine.
> 
> Now comes the issue. Another network needs to be connected to the CE
> router with a separate routing table, hence VRF's.
> 
> So, I was thinking this must be easy:  make a VRF C1, move interface
> g0/0 into a vrf C1, move the BGP configuration to the C1 address-family
> and move the ip route to the VRF as well.
> 
> The last is however a problem:
> 
> TESTCE(config)# ip route vrf C1 172.16.1.0 255.255.255.128
> GigabitEthernet 0/0
> % For VPN or topology routes, must specify a next hop IP address if not
> a point-to-point interface
> 
> I just can't get it to work and reading Cisco documentation this is not
> going to be fixed either. The only alternative that I can think of is
> using BGP inject maps, but apparently they are not working in VRF's
> either.
> 
> I could split the subnet in two /25's and use a secondary on the
> interface, but I consider that quiet ugly because I want to keep /24 on
> the servers (so server-server communication on the subnet is not going
> through the router).
> 
> Does anybody have a suggestion how to solve this problem?
> 
> Kind regards,
> 
> Frank
> 
> ___
> 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] Input errors, overrun & unknown protocols drops on LAN interface

[David Prall]

I'd say you have a lot of traffic with TTL 1 or a link-local multicast
address on the interface, if everything else is working correctly. Otherwise
you are process switching a lot of traffic.

Here are some pointers:
http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186
a0080094791.shtml

But, I would say that you have something like "no ip route-cache" configured
on the interface. You say it is a LAN interface, you talk about MPLS, are
there multiple LDP relationships on this interface, are you running RSVP for
TE on a LAN Segment?

David

--
http://dcp.dcptech.com


> -Original Message-
> From: Farooq Razzaque [mailto:farooq_...@hotmail.com]
> Sent: Tuesday, September 13, 2011 11:18 AM
> To: d...@dcptech.com; david.roth...@gmail.com
> Cc: cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] Input errors, overrun & unknown protocols drops on
> LAN interface
> 
> Dear David
> 
> Please find the resule of show buffer. can u pls analyse and help
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From: farooq_...@hotmail.com
> To: d...@dcptech.com; david.roth...@gmail.com
> CC: cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] Input errors, overrun & unknown protocols drops on
> LAN interface
> Date: Tue, 13 Sep 2011 20:49:14 +0600
> 
> 
> Dear David
> 
> I increased the hold on Queue to size 3500 but the input error and
> input queue drops are there . May be the frequency of increasing is
> reduced but it is still there.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > From: d...@dcptech.com
> > To: farooq_...@hotmail.com; david.roth...@gmail.com
> > CC: cisco-nsp@puck.nether.net
> > Subject: RE: [c-nsp] Input errors, overrun & unknown protocols drops
> on LAN interface
> > Date: Tue, 13 Sep 2011 09:40:49 -0400
> >
> > To minimize the input drops you can increase the hold-queue. Another
> issue
> > to look at is the buffers as well, most likely have misses and
> failures
> > there. The flushes are caused by SPD, which are control plane packets
> that
> > need to make it to the processor so they are put ahead of everything
> else in
> > the input queue.
> >
> > David, a different one.
> >
> > --
> > http://dcp.dcptech.com
> >
> >
> > > -Original Message-
> > > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> > > boun...@puck.nether.net] On Behalf Of Farooq Razzaque
> > > Sent: Tuesday, September 13, 2011 9:18 AM
> > > To: david.roth...@gmail.com
> > > Cc: cisco-nsp@puck.nether.net
> > > Subject: Re: [c-nsp] Input errors, overrun & unknown protocols
> drops on
> > > LAN interface
> > >
> > >
> > > Dear David
> > >
> > > How can we resolve this then
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > Subject: Re: [c-nsp] Input errors, overrun & unknown protocols
> drops
> > > on LAN interface
> > > > From: david.roth...@gmail.com
> > > > Date: Tue, 13 Sep 2011 14:04:57 +0100
> > > > CC: n...@foobar.org; cisco-nsp@puck.nether.net
> > > > To: farooq_...@hotmail.com
> > > >
> > > > Input drops are usually caused by the input queue filling up and
> then
> > > tail drops occurring because there is no more space for new packets
> in
> > > the queue.
> > > >
> > > > I've seen this happen where you have an upstream device trying to
> > > send packets faster than the downstream device can process them.
> > > >
> > > >
> > > > On 13 Sep 2011, at 13:54, Farooq Razzaque wrote:
> > > >
> > > > >
> > > > > Dear Nick
> > > > >
> > > > > Thanks for your reply.
> > > > >
> > > > > What does input error means ?
> > > > >
> > > > > I am also having the drops in Input queue
> > > > >
> > > > >
> > > > >
> > > > > Input queue: 0/75/3267688/769 (size/max/drops/flushes); Total
> > > output drops: 0
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >> Date: Tue, 13 Sep 2011 12:18:05 +0100
> > > > >> From: n...@foobar.org
> > > > >> To: farooq_...@hotmail.com
> > > > >> CC: cisco-nsp@puck.nether.net
> > > > >> Subject: Re: [c-nsp] Input errors, overrun & unknown protocols
> > > drops on LAN interface
> > > > >>
> > > > >> On 13/09/2011 10:13, Farooq Razzaque wrote:
> > > > >>> I am facing the input errors, overrun & unknown protocols
> drops
> > > on LAN
> > > > >>> interface-Gi0/0 (having sub-interface) on MPLS router.
> > > > >>
> > > > >> port overruns mean that your router is receiving data faster
> than
> > > it can
> > > > >> handle. You either need a faster router than a 3800 series or
> else
> > > larger
> > > > >> input buffers.
> > > > >>
> > > > >> Unknown protocols means that your switch is sending data that
> the
> > > router
> > > > >> doesn't understand. Maybe LLDP or something? Or some other odd
> LAN
> > > protocol?
> > > > >>
> > > > >> Nick
> > > > >
> > > > > ___
> > > > > cisco-nsp mailing list cisco-nsp@puck.nether.net
> > > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > > archive at http://puck.nether

Re: [c-nsp] Input errors, overrun & unknown protocols drops on LAN interface

[David Prall]

To minimize the input drops you can increase the hold-queue. Another issue
to look at is the buffers as well, most likely have misses and failures
there. The flushes are caused by SPD, which are control plane packets that
need to make it to the processor so they are put ahead of everything else in
the input queue.

David, a different one.

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Farooq Razzaque
> Sent: Tuesday, September 13, 2011 9:18 AM
> To: david.roth...@gmail.com
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Input errors, overrun & unknown protocols drops on
> LAN interface
> 
> 
> Dear David
> 
> How can we resolve this then
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > Subject: Re: [c-nsp] Input errors, overrun & unknown protocols drops
> on LAN interface
> > From: david.roth...@gmail.com
> > Date: Tue, 13 Sep 2011 14:04:57 +0100
> > CC: n...@foobar.org; cisco-nsp@puck.nether.net
> > To: farooq_...@hotmail.com
> >
> > Input drops are usually caused by the input queue filling up and then
> tail drops occurring because there is no more space for new packets in
> the queue.
> >
> > I've seen this happen where you have an upstream device trying to
> send packets faster than the downstream device can process them.
> >
> >
> > On 13 Sep 2011, at 13:54, Farooq Razzaque wrote:
> >
> > >
> > > Dear Nick
> > >
> > > Thanks for your reply.
> > >
> > > What does input error means ?
> > >
> > > I am also having the drops in Input queue
> > >
> > >
> > >
> > > Input queue: 0/75/3267688/769 (size/max/drops/flushes); Total
> output drops: 0
> > >
> > >
> > >
> > >
> > >
> > >
> > >> Date: Tue, 13 Sep 2011 12:18:05 +0100
> > >> From: n...@foobar.org
> > >> To: farooq_...@hotmail.com
> > >> CC: cisco-nsp@puck.nether.net
> > >> Subject: Re: [c-nsp] Input errors, overrun & unknown protocols
> drops on LAN interface
> > >>
> > >> On 13/09/2011 10:13, Farooq Razzaque wrote:
> > >>> I am facing the input errors, overrun & unknown protocols drops
> on LAN
> > >>> interface-Gi0/0 (having sub-interface) on MPLS router.
> > >>
> > >> port overruns mean that your router is receiving data faster than
> it can
> > >> handle. You either need a faster router than a 3800 series or else
> larger
> > >> input buffers.
> > >>
> > >> Unknown protocols means that your switch is sending data that the
> router
> > >> doesn't understand. Maybe LLDP or something? Or some other odd LAN
> protocol?
> > >>
> > >> 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/
> >
> 
> ___
> 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] Regain CLI access with snmp sets?

[David Prall]

You can write to it with tftp config location.

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_examp
le09186a0080094aa6.shtml#copying_startup

It appears you can only do this to the startup, so it will still need to be
reloaded at some point.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Mike
> Sent: Thursday, September 08, 2011 5:40 PM
> To: 'Cisco-nsp'
> Subject: [c-nsp] Regain CLI access with snmp sets?
> 
> Hello,
> 
>   I am sure this can be done and am calling on my fellows to help
> light
> the way!
> 
>   I have a cisco 2970 switch newly installed in a remote,
> inaccessible
> location that presently lacks OOB serial access. Due to a config error,
> I cannot telnet into the unit due to missing config elements:
> 
> Escape character is '^]'.
> 
> 
> Password required, but none set
> Connection closed by foreign host.
> 
> 
>   I do have, however, a writable snmp community string. So I am
> wondering
> if it would be possible to update the running config using snmp in
> order
> to give me telnet access to this unit? It would beat a trip back out
> there and would serve my cisco education well too. So how about it, any
> takers?
> 
> Mike-
> ___
> 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] ARP oddness

[David Prall]

Are you just getting Unicast flooding because the switch doesn't know where
the destination is?

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note0918
6a00801d0808.shtml

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Chuck Church
> Sent: Friday, August 19, 2011 4:24 PM
> To: NSP - Cisco
> Subject: [c-nsp] ARP oddness
> 
> Anyone,
> 
>Researching some issues at a remote site, seeing something I
> don't
> think should happen.  A packet capture on this remote server using
> wireshark
> and focusing in on ARP is seeing all the requests (as I'd expect), but
> I'm
> also seeing unicast replies that I shouldn't.  The MAC address table on
> the
> switch I'm attached to shows only the MAC of this remote server on that
> port.  There are no SPAN sessions on the switch either.  The
> destination
> addresses aren't multicast, they're true unicast.  Yet I'm seeing all
> these
> unicasts that aren't my mac address.  Is there some function built into
> a
> Cisco switch that broadcasts these to make them act like gratuitous
> ARPs, or
> am I really seeing something that shouldn't happen?  It's on a Sup2+
> 4500,
> running 12.2(25)EWA10 (I know it's ancient, vendor owns it...)
> 
> Thanks,
> 
> Chuck
> ___
> 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] ARP oddness

[David Prall]

Sorry missed that it was a ARP reply. Are you getting any mac move messages
on the switch, showing that spanning tree topology changes could possibly be
happening on a downstream switch.

--
http://dcp.dcptech.com


> -Original Message-
> From: Chuck Church [mailto:chuckchu...@gmail.com]
> Sent: Friday, August 19, 2011 6:16 PM
> To: David Prall
> Cc: NSP - Cisco
> Subject: Re: RE: [c-nsp] ARP oddness
> 
> The ARP request would have had to have been spoofed then.  I'll have to
> check Monday.  I've got no reason to believe its malicious.  It's
> factory gear, I would believe anything with that stuff.
> 
> Chuck
> 
> On Aug 19, 2011 5:44 PM, "David Prall"  wrote:
> > Are you just getting Unicast flooding because the switch doesn't know
> where
> > the destination is?
> >
> >
> http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_not
> e0918
> > 6a00801d0808.shtml
> >
> > --
> > http://dcp.dcptech.com
> >
> >
> >> -Original Message-
> >> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> >> boun...@puck.nether.net] On Behalf Of Chuck Church
> >> Sent: Friday, August 19, 2011 4:24 PM
> >> To: NSP - Cisco
> >> Subject: [c-nsp] ARP oddness
> >>
> >> Anyone,
> >>
> >> Researching some issues at a remote site, seeing something I
> >> don't
> >> think should happen. A packet capture on this remote server using
> >> wireshark
> >> and focusing in on ARP is seeing all the requests (as I'd expect),
> but
> >> I'm
> >> also seeing unicast replies that I shouldn't. The MAC address table
> on
> >> the
> >> switch I'm attached to shows only the MAC of this remote server on
> that
> >> port. There are no SPAN sessions on the switch either. The
> >> destination
> >> addresses aren't multicast, they're true unicast. Yet I'm seeing all
> >> these
> >> unicasts that aren't my mac address. Is there some function built
> into
> >> a
> >> Cisco switch that broadcasts these to make them act like gratuitous
> >> ARPs, or
> >> am I really seeing something that shouldn't happen? It's on a Sup2+
> >> 4500,
> >> running 12.2(25)EWA10 (I know it's ancient, vendor owns it...)
> >>
> >> Thanks,
> >>
> >> Chuck
> >> ___
> >> 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] Common uRPF setting on all interfaces

[David Prall]

Correct. All uRPF has to be configured the same.

http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SXF/configuration/guide
/secure.pdf
Page 4 - Note - The most recently configured mode is automatically applied
to all ports configured for Unicast RPF check.

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Ross Halliday
> Sent: Monday, July 25, 2011 3:05 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Common uRPF setting on all interfaces
> 
> Hello list,
> 
> We recently did a forklift upgrade of a 6509 from a SUP2 unit to a
> SUP720-3B box. At the same time I also plunked over a few VRFs which
> had been living on an external router due to lack of VRF support on the
> SUP2s. To my surprise one of the moved customers reported lack of
> Internet connectivity (VPN was fine - they collocate a firewall) at
> sites hanging off of the upgraded box. I determined that, though I
> thought I copied everything properly, an SVI's uRPF got messed up and
> was dropping packets from the Internet. In troubleshooting I added
> "allow-default" to the "ip verify ..." line on the SVI and it worked.
> Being connected to an internal VLAN that peers with other switches in
> that VPN (we're not MPLS yet) where all other ingress traffic is
> filtered I figured it was a redundant step so removed the line
> completely.
> 
> Well, this afternoon I saw RANCID email me a list of changes from that
> box. Every single SVI that used to have some incantation of uRPF now
> have "ip verify unicast source reachable-via rx allow-default allow-
> self-ping" on them. Explains how the "allow-default" got removed in the
> first place; the next SVI I pasted in doesn't have that bit.
> 
> Has anyone seen this before? I did a couple of quick searches but my
> Google-fu is letting me down. Is there some secret that only one
> possible stanza for uRPF is allowed on this box, unless the line isn't
> present?
> 
> Running 12.2(33)SXI4a on SUP720-3B in a 6509.
> 
> Thanks
> Ross
> 
> 
> 
> ___
> 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] Problem with IP Inspect

[David Prall]

What versions of code? There is a place, much older code 12.3(4)T, where ip
inspect would add entries to the top of the defined interface acl, you would
use "show access-list" to see the entries. Then there is more recent code
where the entries are dynamically created, you use "show ip inspect
sessions" to see the entries. IP inspect is sort of dependent on the ACL to
define the policy, what happens if you add an acl with a single permit ip
any any. What does "show ip inspect sessions" give you.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Joseph Mays
> Sent: Friday, July 22, 2011 4:24 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Problem with IP Inspect
> 
> Okay, we had a router that had the internal LAN on fastethernet0/0, and
> the
> external WAN on Serial1. The internal lan had the follwoing entries...
> 
> interface FastEthernet0/0
>  ip access-group OfficeACL out
>  ip inspect WinnetOffice in
> 
> Which were associated with
> 
> ip inspect max-incomplete high 1000
> ip inspect max-incomplete low 800
> ip inspect one-minute high 1000
> ip inspect one-minute low 800
> ip inspect dns-timeout 60
> ip inspect tcp idle-time 10800
> ip inspect name WinnetOffice icmp
> ip inspect name WinnetOffice fragment maximum 500 timeout 15
> ip inspect name WinnetOffice netshow
> ip inspect name WinnetOffice realaudio
> ip inspect name WinnetOffice tcp
> ip inspect name WinnetOffice udp
> ip inspect name WinnetOffice tftp
> ip inspect name WinnetOffice ftp audit-trail off
> 
> ...and a long OfficeACL list that I won't go into at the moment.
> 
> We moved to a router that has the WAN connecion on a pair bonded
> ethernet
> ports connected to a bridged ADSL modem, and the LAN port on
> Fastethernet0/0
> 
> I tried added the ip inspect line and the acl line to Fastethernet0,
> but I
> found with nothing else changing, including the LAN IP's not changing,
> connections to the outside world broke. In trying various thing, I
> found
> adding the "ip inspect WinnetOffice in" line broke communications to
> the
> outside world *by itself*, even if the ACL list was not being activated
> by
> the ip access-group line. This shouldn't happen, should it? There is no
> way
> turning on ip inspection should break communications anywhere in the
> absence
> of an ACL list, is there?
> 
> 
> ___
> 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] BGP "keep alives throttled do to tcp", MTU mismatch?

[David Prall]

BGP Hellos are not sent with pak-priority, while they are marked IP Precedence 
6. Thus they need to be prioritized if you have a congested link. That GE Port 
on the NPE-400 is subrate to begin with, so you could be dropping them before 
they even make it out or can be processed inbound.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Scott Granados
> Sent: Thursday, July 21, 2011 4:01 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] BGP "keep alives throttled do to tcp", MTU mismatch?
> 
> Hi, I have a puzzler.
> 
> I have two Cisco 7206VXr routers one with a G1 and the other with a 400
> processor.
> Between them terminated on a gig interface on each side is an ILEC
> provided metro E connection that’s pretty vanilla using VLANs to
> address different connections.
> 
> I have a /30 set up on a common VLAN between the two with the BGP peer
> set up on that /30.
> After 3 minutes, my session will reset I’m assuming do to lack of
> keepalives / problems with MTU.  Lots of googling as pointed me at
> various MTU mismatch situations but I’m not sure what I’m doing wrong
> possibly assuming something is set “in an interesting way” between the
> sites on the ILEC network.
> 
> On each interface I have the following
> 
> int gig x/x
> mtu 1522
> 
> Assuming 1500 for standard Ethernet and 22 for the VLAN tags.
> I also have the following set in global mode
> ip tcp path-mtu-discovery
> 
> On both VXR devices code 12.4-25C is being run.
> 
> I would appreciate any pointers to investigate.  What have I
> missed?
> 
> 
> Thanks
> Scott
> 
> 
> 
> ___
> 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] etherchannel load-balancing and unpredictability

[David Prall]

Typically the first port on one will return via the first port on the other.
The hash is based on src and dst, so they hash to the same link. Test
etherchannel will show you what the actual hash is for a given source and
destination, run it for some randomly chosen traffic. If you are only
looking for redundancy, and don't want spanning-tree, you can run LACP with
max-bundle configured. Then you will only use 1 of the interfaces in the
port-channel even though you have 2. 

David

--
http://dcp.dcptech.com


> -Original Message-
> From: Steven Pfister [mailto:spfis...@dps.k12.oh.us]
> Sent: Wednesday, July 20, 2011 9:11 AM
> To: David Prall; 'Keegan Holley'
> Cc: cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] etherchannel load-balancing and unpredictability
> 
> Yes, that's correct. Either content filter should be able to handle all
> of the load if it needed to.  The goal was mainly redundancy.
> 
> If we swap the links so interface 1 on one switch goes to interface 2
> on the other and vice versa, would that help?
> 
> Steve Pfister
> Network Engineer
> Office of Information Technology
> Dayton Public Schools
> 115 S Ludlow St
> Dayton, OH 45402-1812
> Phone: 937-542-3149
> Cell: 937-673-6779
> spfis...@dps.k12.oh.us <mailto:spfis...@dps.k12.oh.us>
> 
> 
> >>> "David Prall"  7/19/2011 8:48 PM >>>
> Keegan,
> I think he isn't worried about it being unpredictable load wise. He's
> more
> interested in it being predictable that a source .1 to .2 on the inside
> switch goes over link 1, and that the .2 to .1 on the outside switch
> returns
> over link 1.
> 


___
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] etherchannel load-balancing and unpredictability

[David Prall]

Keegan,
I think he isn't worried about it being unpredictable load wise. He's more
interested in it being predictable that a source .1 to .2 on the inside
switch goes over link 1, and that the .2 to .1 on the outside switch returns
over link 1. 

This link has a discussion of this:
http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080
094714.shtml#cat4k

You can use test etherchannel to determine the exact interface the packets
will be hashed across. This is on the SP of 6500, I checked on a 3560E and
it is available, the link doesn't show a 4500 with IOS and I don't have one
to test on currently. I've used etherchannel load balancing for IPS and as a
span destination for IDS.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Keegan Holley
> Sent: Tuesday, July 19, 2011 8:22 PM
> To: Steven Pfister
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] etherchannel load-balancing and unpredictability
> 
> 2011/7/19 Steven Pfister 
> 
> > I have a question regarding etherchannel load balancing. I've got a
> > 4507R switch connected to a 3560 switch by means of two content
> filters
> > which are acting as transparent bridges. The two ports on each side
> that
> > the content filters are connected to are set up as access ports and
> are
> > in an etherchannel. The load balancing method on each switch is set
> to
> > src-dst-ip. I was under the impression that each pair of source and
> > destination ip address would select exactly one content filter no
> matter
> > which direction.
> >
> > this is exactly what is unpredictable about it.  The operation is a
> hash so
> different src/dst pairs aren't always going to chose different links.
> For
> example (a very simple one)  if you have a subnet 192.168.100.0/24 and
> station .1 talks to station .3 and .5 there's nothing to prevent both
> of
> those conversations from using the same link.  It's based on a
> mathematical
> formula that does not vary.  If for example you add .2 and it talks to
> .4
> and .6 they may use the second link.  However, what if the "odd"
> numbered
> conversations are just above 1G say 1.2G or so.  They will drop packets
> and
> there will be no way to hash them to a different link other than
> changing
> load-balancing algorithms.  The being said the other algorithms are
> just as
> unpredictable for just the same reasons.  It depends completely on your
> traffic patterns.  Adding TCP/UDP port may even this out a bit but I
> don't
> believe it is supported on the 3560.
> ___
> 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] GRE tunnel to do span vlan across two datacenters?

[David Prall]

Since GRE isn't supported on the 3750, it seems like a non-starter. While
you can configure GRE, it is all done in software thus impacting all control
plane traffic. As well bridging isn't supported over GRE. 

If you have Dark Fiber, I would recommend using it. 

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Jason Gurtz
> Sent: Wednesday, July 06, 2011 12:09 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] GRE tunnel to do span vlan across two datacenters?
> 
> A firm has proposed creating a GRE tunnel between two datacenters
> (using a
> 3750X stack at each) to create the spanned vlans needed for VMWare
> failover application.
> 
> Clearly there is tunnel overhead but I sense there are other failure
> modes
> here that aren't so clear to me--I am familiar in concept with GRE
> tunnels
> but don't have a heck of a lot of opex. Can anyone share more insight
> on
> the merit (or lack of) with this proposed design? I am aware (via this
> list, thanks!) of several shortcomings surrounding 3750 based stacks,
> but
> cisco alternatives seem pricier still or too big. There is dark fiber
> available, what about VPLS w/ LDP or L2TP solution?
> 
> Current network is L3 at the access layer w/ OSPF (4507-sup6 access,
> 4900M
> cores):
> 
>  A1
>  /\
>/\
>  C1--C2
>\/
>  \/
>  A2
> 
> Maybe it is better to just overlay stp back on to the network w/root
> and
> alt-root at C1/C2 (V1 and V2 are the proposed 3750X stacks)? Scary to
> me,
> but an an argument can be made for less complexity -vs.- tunnling/vpn
> based approach.
> 
>  A1 .V1
>  /\ . ' /
>/. ' \ /
>  C1--C2
>\` . / \
>  \/ ' . \
>  A2 'V2
> 
> OTOH, by the time this actually gets done maybe TRILL will be out ;)
> Hopefully this enterprisy topic is not too OT!
> 
> ~JasonG
> 
> 
> 
> ___
> 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] Fwd: GBIC_SECURITY_CRYPT-4-ID_MISMATCH: Identification check failed for GBIC in port [dec]

[David Prall]

It is "service unsupported-transceiver" it is hidden so tab completion won't
help you.

cat3560-1(config)#service unsupported-transceiver
 Warning: When Cisco determines that a fault or defect can be traced to
the use of third-party transceivers installed by a customer or reseller,
then, at Cisco's discretion, Cisco may withhold support under warranty or
a Cisco support program. In the course of providing support for a Cisco
networking product Cisco may require that the end user install Cisco
transceivers if Cisco determines that removing third-party parts will
assist Cisco in diagnosing the cause of a support issue.

cat3560-1(config)#no service unsupported-transceiver

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Dennis
> Sent: Monday, May 23, 2011 4:15 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Fwd: GBIC_SECURITY_CRYPT-4-ID_MISMATCH: Identification
> check failed for GBIC in port [dec]
> 
> I'm out of my element at this point - does anyone else have any
> suggestions?
> 
> 
> -- Forwarded message --
> From: Farooq Razzaque 
> Date: Mon, May 23, 2011 at 1:05 PM
> Subject: RE: [c-nsp] GBIC_SECURITY_CRYPT-4-ID_MISMATCH: Identification
> check failed for GBIC in port [dec]
> To: daoden...@gmail.com
> 
> 
> Dear Dennis
> 
> I tried the following command but this command is not support. can u
> please check again and let me know
> 
> service-unsupported transceiver
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > Date: Mon, 23 May 2011 09:31:58 -0700
> > Subject: Re: [c-nsp] GBIC_SECURITY_CRYPT-4-ID_MISMATCH:
> Identification check failed for GBIC in port [dec]
> > From: daoden...@gmail.com
> > To: farooq_...@hotmail.com
> >
> > On Mon, May 23, 2011 at 9:30 AM, Farooq Razzaque
>  wrote:
> > > Dear Dennis
> > >
> > > Is there need to upgrade the IOS ?
> >
> > I don't know for sure. Are you using Cisco SFPs? What IOS is it?
> >
> >
> > >
> > > service-unsupported transceiver
> > >
> > > Do i need to put the following commands as well or only the above
> command
> > > will be sufficient.
> >
> > Just try the above if that doesn't work put in the below commands as
> well.
> >
> > >
> > > no errdisable detect cause gbic-invalid
> > >  errdisable recovery cause all
> > >  errdisable recovery interval 30
> > >
> >
> > Thanks,
> >
> > Dennis O.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >> Date: Mon, 23 May 2011 09:27:51 -0700
> > >> Subject: Re: [c-nsp] GBIC_SECURITY_CRYPT-4-ID_MISMATCH:
> Identification
> > >> check failed for GBIC in port [dec]
> > >> From: daoden...@gmail.com
> > >> To: farooq_...@hotmail.com
> > >>
> > >> On Mon, May 23, 2011 at 9:26 AM, Farooq Razzaque
> 
> > >> wrote:
> > >> > Dear Dannis
> > >> >
> > >> > Thanks for your reply
> > >> >
> > >> > Is there any need to upgrade the IOS ?
> > >> >
> > >> > Are the following commands will be put on the GBIC interface
> > >>
> > >> Just do it in global config mode.
> > >
> 
> ___
> 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] Cant Ping Tunnel Originating from VRF Instance

[David Prall]

Looks like Router A is an ASR1000. The gi0 Mgmt-intf isn't in the
data-plane. It is only there for out of band management. No connection
between it and the ESP.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Righa Shake
> Sent: Wednesday, March 02, 2011 7:23 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Cant Ping Tunnel Originating from VRF Instance
> 
> Lee I am using the vrf command.I have changed ny config to as below but
> still unable to ping across
> 
> ROUTER A CONFIGURATIONS
> 
> interface Tunnel10
>   ip vrf forwarding SHAKE_MNGT
>  ip address 172.16.2.1 255.255.255.252
>  keepalive 30 3
>  tunnel source GigabitEthernet0
>  tunnel destination D.D.D.D
>  tunnel path-mtu-discovery
>  tunnel vrf Mgmt-intf
> 
> 
> 
> ROUTER B CONFIG
> interface Tunnel10
>   ip address 172.16.2.2 255.255.255.252
>  keepalive 30 3
>  tunnel source D.D.D.D
>  tunnel destination X.X.X.X
>  tunnel path-mtu-discovery
> !
> 
> I cant seem to be able to ping the point to point IP's
> 
> Regards,
> Righa Shake
> 
> On Tue, Mar 1, 2011 at 5:49 PM, Lee Riemer 
> wrote:
> 
> > Are you specifying the vrf interface in your ping command?
> >
> >
> >
> > On 3/1/2011 8:02 AM, Righa Shake wrote:
> >
> >> I have created a tunnel whose tunnel source is a public IP on a VRF
> >> instance.However i cant seems t ping on the point to point from my
> router.
> >> Am trying to have two different routes to the same router via
> different
> >> paths
> >>
> >> My settings are as follows:
> >>
> >>
> >> interface Tunnel10
> >>   ip address 172.16.2.1 255.255.255.252
> >>  keepalive 30 3
> >>  tunnel source Z.Z.Z.Z
> >>  tunnel destination Y.Y.Y.Y
> >>  tunnel vrf Mgmt-intf
> >> end
> >>
> >> ROUTERA#
> >>
> >>
> >> interface Tunnel10
> >>   ip address 172.16.2.2 255.255.255.252
> >>  keepalive 30 3
> >>  tunnel source Y.Y.Y.Y
> >>  tunnel destination Z.Z.Z.Z
> >> end
> >>
> >> ROUTERB#
> >>
> >>  From router to router i cant seem to ping across.
> >> An traffic doesnt seem to pass through this link.
> >>
> >> Any assistance is highly appreciated.
> >>
> >> Regards,
> >> Righa Shake
> >> ___
> >> 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] CDP Query

[David Prall]

In LMS you'll need to configure it to use another form of discovery then
CDP.

I found this: https://supportforums.cisco.com/message/671976

David

--
http://dcp.dcptech.com


> -Original Message-
> From: Muhammad Jawwad Paracha [mailto:jawwa...@gmail.com]
> Sent: Wednesday, February 16, 2011 8:26 AM
> To: David Prall
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] CDP Query
> 
> Hi David
> 
> GET VPN neighbor are via service provider. Any work around to it?. We
> have a customer whose devices are not visible in LMS due to this issue.
> 
> Regards
> 
> Jawwad Paracha
> IBM
> 
> 
> On Tue, Feb 15, 2011 at 7:39 PM, David Prall  wrote:
> 
> 
>   Your neighbor in GET VPN is the Service Provider / MPLS Carrier.
> You won't
>   find the remote spokes via CDP.
> 
>   --
>   http://dcp.dcptech.com
> 
> 
> 
>   > -Original Message-
>   > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> 
>   > boun...@puck.nether.net] On Behalf Of Aaron Riemer
>   > Sent: Tuesday, February 15, 2011 7:40 AM
>   > To: 'Muhammad Jawwad Paracha'; cisco-nsp@puck.nether.net
>   > Subject: Re: [c-nsp] CDP Query
>   >
>   > Is layer 2 forwarded over GET VPN?
>   >
>   > Interested to know.
>   >
>   > -Aaron
>   >
>   > -Original Message-
>   > From: cisco-nsp-boun...@puck.nether.net
>   > [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Muhammad Jawwad
>   > Paracha
>   > Sent: Tuesday, 15 February 2011 7:56 PM
>   > To: cisco-nsp@puck.nether.net
>   > Subject: [c-nsp] CDP Query
>   >
>   > Hi
>   >
>   > CDP is not discovering neighbors in GET VPN design, any idea
> why not?
>   >
>   > Regards
>   >
>   > Jawwad Paracha
>   > ___
>   > 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] CDP Query

[David Prall]

Your neighbor in GET VPN is the Service Provider / MPLS Carrier. You won't
find the remote spokes via CDP. 

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Aaron Riemer
> Sent: Tuesday, February 15, 2011 7:40 AM
> To: 'Muhammad Jawwad Paracha'; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] CDP Query
> 
> Is layer 2 forwarded over GET VPN?
> 
> Interested to know.
> 
> -Aaron
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Muhammad Jawwad
> Paracha
> Sent: Tuesday, 15 February 2011 7:56 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] CDP Query
> 
> Hi
> 
> CDP is not discovering neighbors in GET VPN design, any idea why not?
> 
> Regards
> 
> Jawwad Paracha
> ___
> 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] L2 Ethernet bridging over GRE issues

[David Prall]

This goes over the majority of L2TPv3 configuration
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gtl2tpv3.html

--
http://dcp.dcptech.com


> -Original Message-
> From: roger.wikl...@gmail.com [mailto:roger.wikl...@gmail.com] On
> Behalf Of Roger Wiklund
> Sent: Friday, January 28, 2011 3:15 AM
> To: Cisco-nsp
> Cc: i...@ianh.net.au; d...@dcptech.com
> Subject: Re: [c-nsp] L2 Ethernet bridging over GRE issues
> 
> > And L2TPv3 is supported. Recent code doesn't allow a  bridge-group to
> be
> > defined on a tunnel.
> 
> >> While this is possible, its ten times easier and more reliable to
> use
> >> L2TPv3.
> 
> Thanks, I've never tested L2TP, but I'm familiar with GRE.
> Is L2TP server-client or can it be used as always up back-to-back
> between two routers?
> Do you have any nice sample config of back-to-back L2TP on Ethernet
> with and without VLANs.
> 
> Thanks!


___
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] L2 Ethernet bridging over GRE issues

[David Prall]

And L2TPv3 is supported. Recent code doesn't allow a  bridge-group to be
defined on a tunnel.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Ian Henderson
> Sent: Thursday, January 27, 2011 8:37 PM
> To: Roger Wiklund
> Cc: Cisco-nsp
> Subject: Re: [c-nsp] L2 Ethernet bridging over GRE issues
> 
> On 28/01/2011, at 5:17 AM, Roger Wiklund wrote:
> 
> > I've setup a GRE tunnel from Router A to Router B.
> > I've configured bridging between Tunnel0 and LAN interface on Router
> A
> > and Router B
> 
> While this is possible, its ten times easier and more reliable to use
> L2TPv3.
> 
> 
> ___
> 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] 6500/Sup720 won't run a WS-X6516-GBIC?

[David Prall]

http://www9.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/releas
e/notes/hardware.pdf

Looks like you might need to upgrade the ROMMON.
On page 45:
Note 
. Use with Release 12.2(33)SXH or later and a DFC requires DFC ROMMON
version 12.2(18r)S1 or
later. To display the switching module ROMMON version, enter the remote
command module
module_slot_number show version | include ROM command. To upgrade the
switching module
ROMMON, see this document:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/rommon/OL_6010.htm
l
. Supervisor Engine 720 supports a DFC3 on these WS-X6516-GBIC hardware
revisions:
- Lower than 5.0
- 5.5 and higher
. Supervisor Engine 720 does not support a DFC3 on WS-X6516-GBIC hardware
revisions 5.0
through 5.4. With a Supervisor Engine 720 and with a DFC3 installed,
WS-X6516-GBIC hardware
revisions 5.0 through 5.4 do not power up.
. With a Supervisor Engine 720 but without a DFC3, WS-X6516-GBIC hardware
revisions 5.0
through 5.4 operate in bus mode.
. See external field notice 24494 for more information:
http://www.cisco.com/en/US/ts/fn/200/fn24494.html
 
David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of GP Wooden
> Sent: Sunday, January 23, 2011 5:53 PM
> To: GP Wooden; Jeff Kell; cisco-nsp
> Subject: Re: [c-nsp] 6500/Sup720 won't run a WS-X6516-GBIC?
> 
> Converted, as into vss...
> 
> - Reply message -
> From: "GP Wooden" 
> Date: Sun, Jan 23, 2011 3:22 pm
> Subject: [c-nsp] 6500/Sup720 won't run a WS-X6516-GBIC?
> To: "Jeff Kell" , "cisco-nsp"  n...@puck.nether.net>
> 
> Ran into the same issue with that card when I converted a bunch of our
> distro's with that same sup. Luckily, I was able to move the connects
> to a 6748 card and just changed fiber jumpers.
> 
> - Reply message -
> From: "Jeff Kell" 
> Date: Sun, Jan 23, 2011 2:22 pm
> Subject: [c-nsp] 6500/Sup720 won't run a WS-X6516-GBIC?
> To: "cisco-nsp" 
> 
> Is this module not supported on this Supervisor?  Have a 6509 running
> s72033-ipservicesk9_wan-mz.122-33.SXI3.bin.
> 
> Getting this at startup:
> 
> *Aug  6 20:00:06.931: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in
> slot 3, power not allowed: The image for the card is not bundled in
> image.
> 
> Jeff
> 
> >show module
> Mod Ports Card Type  Model
> Serial No.
> --- - -- --
> ---
>   3   16  SFM-capable 16 port 1000mb GBICWS-X6516-GBIC
> SAD061902L2
>   55  Supervisor Engine 720 10GE (Active)VS-S720-10G
> SAL1426LK11
>   65  Supervisor Engine 720 10GE (Hot)   VS-S720-10G
> SAL1424KDCP
> 
> Mod MAC addresses   HwFw   Sw
> Status
> --- -- --  
> ---
>   3  0003.fea8.f7d6 to 0003.fea8.f7e5   4.1   Unknown  12.2(33)SXI3
> PwrDown
>   5  0025.84bf.dcf0 to 0025.84bf.dcf7   3.2   8.5(4)   12.2(33)SXI3
> Ok
>   6  0025.84bf.c918 to 0025.84bf.c91f   3.2   8.5(4)   12.2(33)SXI3
> Ok
> 
> ___
> 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] SFP-GE-T

[David Prall]

The second port on the RSP720 is user selectable. Media-type rj45

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of jack daniels
> Sent: Thursday, January 13, 2011 3:39 PM
> To: Nick Hilliard
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] SFP-GE-T
> 
> is there any RJ45 port on SUP. I thnk its not , only thig u can do is
> use SFP electrical or optical.
> 
> On Fri, Jan 14, 2011 at 1:55 AM, Nick Hilliard  wrote:
> > On 13/01/2011 19:42, jack daniels wrote:
> >>
> >> Does  the port on SUP - Cisco 7606S Chassis,6-slot,Redundant
> >> System,2RSP720-3C,2PS
> >>
> >> Support 100Mbps configurable port
> >
> > almost certainly not.  Why not use the RJ45 port on the SUP if it's
> free?
> >
> > 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/


___
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] ASR 9000 Newbie question

[David Prall]

John,
Which cards and which version of IOS-XR is running on the RP's. Typical are
the cards supported by the IOS. Show diag is always a good place to start. 

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of John Neiberger
> Sent: Thursday, January 06, 2011 5:22 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] ASR 9000 Newbie question
> 
> We have a couple of new ASR 9k routers in our test lab. None of us
> have had training on them yet and none of us know IOS-XR yet. One of
> our engineers is installing the new blades and two of them are coming
> up with red lights and are staying inactive. We can't figure out how
> to troubleshoot this in XR. There doesn't seem to be anything in the
> logs, which is weird. I suggested that he verify that logging is
> configured. It could be that there are errors, but they're just not
> being logged.
> 
> I've got the IOS XR Fundamentals book, but I don't see any commands
> related to this yet.
> 
> Any thoughts?
> 
> Thanks!
> ___
> 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] What is the fpd package used for in newer IOS releases?

[David Prall]

FPD Field Programmable Device. Typically WAN Interface firmware updates.
Typically you'll have "upgrade fpd auto" in the configuration. 

A quick search:
http://www.cisco.com/en/US/docs/interfaces_modules/shared_port_adapters/conf
iguration/7600series/76fpd.html

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of John Neiberger
> Sent: Wednesday, January 05, 2011 3:09 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] What is the fpd package used for in newer IOS
> releases?
> 
> I've done some recent upgrades from 12.2(18) up to 12.2(33) and we've
> been having to put an fdp package on flash along with the actual IOS.
> I've yet to find out exactly what those are for. I was told by another
> more senior engineer that they need to be there, but that's the extent
> of my knowledge of them. Can any of you shed some light on these
> mysterious packages?
> ___
> 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] Simple src/dst IP QoS

[David Prall]

You'll need to use HQoS on the FE interface in order to apply a shaper to
ingress SHDSL traffic. So a 4.6Mbps shaper along the lines of what you have
below. Currently your policy isn't doing anything since it sits on a 100Mbps
link, so traffic other then the voice can use 50Mbps.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: Ray Davis [mailto:ray-li...@carpe.net]
> Sent: Friday, December 17, 2010 9:40 AM
> To: David Prall
> Cc: 'Cisco-nsp'
> Subject: Re: [c-nsp] Simple src/dst IP QoS
> 
> The DSL side is the Dialer interface which has "bandwidth 4608" in it's
> config.  I don't know if service-policy pays any attention to that or
> not.  The LAN side has no bandwidth statement.
> 
> Would I be better off doing something like this?
> 
>  class-map match-all voice-sig
>   match protocol sip
>  class-map match-all voice-rtp
>   match protocol rtp
> 
>  policy-map PrioritizeVoice
>   class voice-rtp
>  priority percent 33
>   class voice-sig
>  priority percent 20
>   class class-default
>  policy-map Shaper6.4M
>   class class-default
>  shape average 640
>service-policy PrioritizeVoice
> 
>  interface FastEthernet0/0
>   description Inside Customer LAN-1 (linknet to ASA firewall)
>   load-interval 30
>   service-policy output Shaper6.4M
> 
>  interface Dialer1
>   description pppoe multilink Dialer (SHDSL line)
>   load-interval 30
>   service-policy output Shaper6.4M
> 
> And should I be shaping on both the LAN & WAN side?
> 
> Thanks,
> Ray
> 
> PS: FYI, I copied the above from http://inetpro.org/wiki/HQoS
> 
> On 17. Dec 2010, at 15:15 Uhr, David Prall wrote:
> 
> > You'll need to do an HQoS shaper on the inside fastethernet interface
> in
> > order to shape remote traffic so that they fall back. You're giving
> 50
> > percent priority to a 4.6Mbps link, on a 100Mbps interface or have
> you
> > configured the correct bandwidth statement on it. I've found using
> HQoS
> > tends to fix things to a point.
> >
> > David
> >
> > --
> > http://dcp.dcptech.com
> >
> >
> >> -Original Message-
> >> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> >> boun...@puck.nether.net] On Behalf Of Ray Davis
> >> Sent: Friday, December 17, 2010 8:18 AM
> >> To: Cisco-nsp
> >> Subject: [c-nsp] Simple src/dst IP QoS
> >>
> >> Hi,
> >>
> >> A customer with a 4.6 Mbit SHDSL line has a remote voip proxy - and
> >> gets drops & jitter when putting load on the line.  Instead of
> trying
> >> to identify voip traffic by protocol and/or ef bits, I tried via the
> >> voip proxy IP address.  Is there any reason why this wouldn't work
> in
> >> IOS (1841, 12.4)?
> >>
> >>class-map match-any VoipTraffic
> >> match access-group name VoipHost
> >>
> >>ip access-list extended VoipHost
> >> permit ip any host 123.456.123.456
> >> permit ip host 123.456.123.456 any
> >>
> >>policy-map VoipPolicy
> >> class VoipTraffic
> >>priority percent 50
> >> class class-default
> >>fair-queue
> >>
> >>interface FastEthernet0/0
> >> description Inside Customer LAN-1 (linknet to ASA firewall)
> >> service-policy output VoipPolicy
> >>
> >>interface Dialer1
> >> description pppoe multilink Dialer (SHDSL line)
> >> bandwidth 4608
> >> service-policy output VoipPolicy
> >>
> >>
> >> The LAC on the other end has something similar ...
> >>
> >>class-map match-any VoipServersTraffic
> >> match access-group name VoipServers
> >>
> >>ip access-list extended VoipServers
> >> permit ip any host 123.456.123.456
> >> permit ip host 123.456.123.456 any
> >> permit ip any host 100.200.300.400
> >> permit ip host 100.200.300.400 any
> >> permit ip any host 321.1.2.3
> >> permit ip host 321.1.2.3 any
> >>
> >>policy-map VoipServersPolicy
> >> class VoipServersTraffic
> >>  priority percent 50
> >> class class-default
> >>  fair-queue
> >>
> >>interface Virtual-Template2
> >> service-policy output VoipServersPolicy
> >>
> >>interface FastEthernet0/0
> >> description NAP local ethernet
> >> service-policy output VoipServersPolicy
> >>
> >> If so, then any suggestions?  The customer still get drops when the
> >> line is saturated with other traffic.  Perhaps a different
> "priority"
> >> type?  or something totally different?
> >>
> >> Thanks,
> >> Ray
> >> ___
> >> 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] Simple src/dst IP QoS

[David Prall]

You'll need to do an HQoS shaper on the inside fastethernet interface in
order to shape remote traffic so that they fall back. You're giving 50
percent priority to a 4.6Mbps link, on a 100Mbps interface or have you
configured the correct bandwidth statement on it. I've found using HQoS
tends to fix things to a point.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Ray Davis
> Sent: Friday, December 17, 2010 8:18 AM
> To: Cisco-nsp
> Subject: [c-nsp] Simple src/dst IP QoS
> 
> Hi,
> 
> A customer with a 4.6 Mbit SHDSL line has a remote voip proxy - and
> gets drops & jitter when putting load on the line.  Instead of trying
> to identify voip traffic by protocol and/or ef bits, I tried via the
> voip proxy IP address.  Is there any reason why this wouldn't work in
> IOS (1841, 12.4)?
> 
> class-map match-any VoipTraffic
>  match access-group name VoipHost
> 
> ip access-list extended VoipHost
>  permit ip any host 123.456.123.456
>  permit ip host 123.456.123.456 any
> 
> policy-map VoipPolicy
>  class VoipTraffic
> priority percent 50
>  class class-default
> fair-queue
> 
> interface FastEthernet0/0
>  description Inside Customer LAN-1 (linknet to ASA firewall)
>  service-policy output VoipPolicy
> 
> interface Dialer1
>  description pppoe multilink Dialer (SHDSL line)
>  bandwidth 4608
>  service-policy output VoipPolicy
> 
> 
> The LAC on the other end has something similar ...
> 
> class-map match-any VoipServersTraffic
>  match access-group name VoipServers
> 
> ip access-list extended VoipServers
>  permit ip any host 123.456.123.456
>  permit ip host 123.456.123.456 any
>  permit ip any host 100.200.300.400
>  permit ip host 100.200.300.400 any
>  permit ip any host 321.1.2.3
>  permit ip host 321.1.2.3 any
> 
> policy-map VoipServersPolicy
>  class VoipServersTraffic
>   priority percent 50
>  class class-default
>   fair-queue
> 
> interface Virtual-Template2
>  service-policy output VoipServersPolicy
> 
> interface FastEthernet0/0
>  description NAP local ethernet
>  service-policy output VoipServersPolicy
> 
> If so, then any suggestions?  The customer still get drops when the
> line is saturated with other traffic.  Perhaps a different "priority"
> type?  or something totally different?
> 
> Thanks,
> Ray
> ___
> 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] memory problem with sr modules not with zr

[David Prall]

What exact Adva gear are you using. Typically CWDM is passive and requires
CWDM optics. SR are Short Reach Multimode. You say that CDP is up and happy
over the link, what does DOM say? It works as L3 but not as L2? What traffic
was traversing it at L3? At L2 you mention that OSPF seems to be working
like crazy, what do the interface counters look like, any CRC errors or
anything on the link. I think you have so many errors in the packets that
the CRC is calculating correctly, and OSPF is having to deal with the
corrupt data.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Hooft van Huysduynen, Dirk
> Sent: Tuesday, November 30, 2010 4:16 PM
> To: 'cisco-nsp@puck.nether.net'
> Subject: [c-nsp] memory problem with sr modules not with zr
> 
> Hello,
> 
> I've got an issue which I can't seem to analyse.
> 
> I've got 4 6509's setup in a square. Divided over two sites.
> 
> --- ---
> | SW1 | L2-2 other site with 10Gbase-ZR-| SW1 |
> --- ---
>| <10Gbase-SR| <10Gbase-SR
> 
> --- ---
> | SW2 | -L2-2 other site with 10Gbase-ZR-| SW 2
> --- ---
>   |---L310GbaseSR over Adva CWDM-|
> 
> I tried to replace the secondary link between the SW2's with another
> provider connectet with an Adva CWDM device.
> I tested tested the modules on layer three as drwan above.
> All worked well incl cdp etc etc
> 
> --- ---
> | SW1 | L2-2 other site with 10Gbase-ZR-| SW1 |
> --- ---
>| <10Gbase-SR| <10Gbase-SR
> 
> --- ---
> | SW2 | --L210GbaseSR over Adva CWDM ---| SW 2
> --- ---
> 
> 
> After doing this I got the following problem:
> Links comes up
> HSRP and STP do their job.
> And after 1 minute orso everything stops.. OSPF seems to be working
> like crazy.
> And I get the following error from the switch on the left site:
> 
> 1134: Nov 30 19:49:04.862: %SYS-2-MALLOCFAIL: Memory allocation of 120
> bytes failed from 0x0, alignment 32
> 1135: Pool: I/O  Free: 0  Cause: Not enough free memory
> 1136: Alternate Pool: none  Free: 0  Cause: No Alternate pool
> 1137:  : raw_ip.proc : (PID=16426, TID=6) : -Traceback=(s72033_rp-
> ipservicesk9_wan-1-dso-p.so+0x274C4) ([37:0]+0x2A9A8) ([27:-4]0-dso-
> n+0x18D40) ([27:-4]57-dso-+0x13900) ([28:-9]6+0x3EC8) ([28:-9]7+0x84FC)
> ([38:0]+0x998C) ([38:0]+0x975C) ([28:-9]6+0x4114) ([38:0]+0x43C4)
> ([27:-4]6-dso-bn+0x4449C) ([27:-4]1-dso-+0x319B4) ([37:0]+0x2E558)
> ([37:0]+0x5133C) ([0:-3]libc+0x2401C)
> 
> When after this I replace the SR modules back to the zr modules
> averything works perfectly.
> 
> Replaces it again with sr> it goes wrong
> Replace it back with ZR it works.
> 
> Fyi I run the modules directly from the supervisor.
> 
> On the left I run ios (s72033_rp-IPSERVICESK9_WAN-VM), Version
> 12.2(33)SXH2a,
> on the right I run ios (s72033_rp-IPSERVICESK9_WAN-M), Version
> 12.2(33)SXI3,
> 
> 
> Why does it work with ZR and not with SR?
> Any tips are welcome
> 
> Gr Dirk
> 
> ___
> 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] SNMP-Check of DMVPN Tunnels?

[David Prall]

I would monitor nhrp registrations and routing protocol neighbors on the
hubs. If you need to go to the spokes then the same thing from there, they
at least will have a smaller count so it will be easier to determine what is
happening from their perspective.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Garry
> Sent: Wednesday, November 03, 2010 4:32 PM
> To: Jonathan Herbert
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] SNMP-Check of DMVPN Tunnels?
> 
> On 03.11.2010 20:22, Jonathan Herbert wrote:
> > We just run an IGP and query throughput on the Tu interfaces. If the
> > crypto
> > socket is down, you'll end up with rxbps = 0. Seems to work well.
> 
> The problem is that both Spoke->Hub connections run through the same
> DMVPN tunnel interface ... and I would prefer not to complicate the
> configuration by adding additional tunnels ... :)
> ___
> 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] SNMP-Check of DMVPN Tunnels?

[David Prall]

Tunnel Health Monitoring:
http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/gu
ide/sec_dmvpn_tun_mon.html

NHRP MIB
http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/gu
ide/sec_dmvpn_nhrp_mib.html

I just know they exist, haven't dug deep into them as of yet.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Garry
> Sent: Wednesday, November 03, 2010 2:09 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] SNMP-Check of DMVPN Tunnels?
> 
> Hi,
> 
> we've set up a customer with a DMVPN with multiple sites, including
> redundant routers and links. Now, using regular Layer3 methods, it's
> not
> possible to check whether a DMVPN link is up or not, e.g.: Site A has
> two Hub routers, Site B has two spoke routers. Both Spoke routers
> connect to both hub routers. EIGRP takes care of the routing,
> preferring
> the link between the two primary routers. Using ICMP, all I can see is
> that I can reach both spoke router's DMVPN IPs. I can't tell though,
> whether B2 has an active tunnel to A2, as the routing via A1-B1 link.
> 
> Are there any SNMP fields I can query to see whether the links are up?
> 
> Tnx, Garry
> ___
> 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] ASIC to switch port mapping

[David Prall]

On a 48 port 3560E, 24 ports per ASIC

cat3560-2#sh platform pm if-numbers
interface gid  gpn  lpn  port slot unit slun port-type lpn-idb gpn-idb
--
Gi0/1 1111/1  111local Yes Yes
Gi0/2 2221/0  122local Yes Yes
Gi0/3 3331/3  133local Yes Yes
Gi0/4 4441/2  144local Yes Yes
Gi0/5 5551/5  155local Yes Yes
Gi0/6 6661/4  166local Yes Yes
Gi0/7 7771/7  177local Yes Yes
Gi0/8 8881/6  188local Yes Yes
Gi0/9 9991/9  199local Yes Yes
Gi0/1010   10   10   1/8  110   10   local Yes Yes
Gi0/1111   11   11   1/11 111   11   local Yes Yes
Gi0/1212   12   12   1/10 112   12   local Yes Yes
Gi0/1313   13   13   1/25 113   13   local Yes Yes
Gi0/1414   14   14   1/24 114   14   local Yes Yes
Gi0/1515   15   15   1/15 115   15   local Yes Yes
Gi0/1616   16   16   1/14 116   16   local Yes Yes
Gi0/1717   17   17   1/17 117   17   local Yes Yes
Gi0/1818   18   18   1/16 118   18   local Yes Yes
Gi0/1919   19   19   1/19 119   19   local Yes Yes
Gi0/2020   20   20   1/18 120   20   local Yes Yes
Gi0/2121   21   21   1/21 121   21   local Yes Yes
Gi0/2222   22   22   1/20 122   22   local Yes Yes
Gi0/2323   23   23   1/23 123   23   local Yes Yes
Gi0/2424   24   24   1/22 124   24   local Yes Yes
Gi0/2525   25   25   2/1  125   25   local Yes Yes
Gi0/2626   26   26   2/0  126   26   local Yes Yes
Gi0/2727   27   27   2/3  127   27   local Yes Yes
Gi0/2828   28   28   2/2  128   28   local Yes Yes
Gi0/2929   29   29   2/5  129   29   local Yes Yes
Gi0/3030   30   30   2/4  130   30   local Yes Yes
Gi0/3131   31   31   2/7  131   31   local Yes Yes
Gi0/3232   32   32   2/6  132   32   local Yes Yes
Gi0/3333   33   33   2/9  133   33   local Yes Yes
Gi0/3434   34   34   2/8  134   34   local Yes Yes
Gi0/3535   35   35   2/11 135   35   local Yes Yes
Gi0/3636   36   36   2/10 136   36   local Yes Yes
Gi0/3737   37   37   2/25 137   37   local Yes Yes
Gi0/3838   38   38   2/24 138   38   local Yes Yes
Gi0/3939   39   39   2/15 139   39   local Yes Yes
Gi0/4040   40   40   2/14 140   40   local Yes Yes
Gi0/4141   41   41   2/17 141   41   local Yes Yes
Gi0/4242   42   42   2/16 142   42   local Yes Yes
Gi0/4343   43   43   2/19 143   43   local Yes Yes
Gi0/4444   44   44   2/18 144   44   local Yes Yes
Gi0/4545   45   45   2/21 145   45   local Yes Yes
Gi0/4646   46   46   2/20 146   46   local Yes Yes
Gi0/4747   47   47   2/23 147   47   local Yes Yes
Gi0/4848   48   48   2/22 148   48   local Yes Yes
Gi0/4949   49   49   0/27 149   49   local Yes Yes
Gi0/5050   50   50   0/19 150   50   local Yes Yes
Gi0/5151   51   51   0/9  151   51   local Yes Yes
Gi0/5252   52   52   0/1  152   52   local Yes Yes
Te0/1 53   53   53   0/14 1153   local Yes Yes
Te0/2 54   54   54   0/0  1254   local Yes Yes
St1   440  440  016/0  100internal  Yes Yes

--
http://dcp.dcptech.com

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Vincent Aniello
> Sent: Friday, September 10, 2010 1:41 PM
> To: Håvard Staub Nyhus
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] ASIC to switch port mapping
> 
> Unless there is only a single ASIC in a 3560E switch I do not believe
> this command returns the ASICs associated with each port.  Here is the
> output on my switch:
> 
> switch1#show platform pm if-numbers
> 
> interface gid  gpn  lpn  port slot unit slun port-type lpn-idb gpn-idb
> --
> Gi0/1 1111/1  111local Yes Yes
> Gi0/2 2221/0  122local Yes Yes
> Gi0/3 3331/3  133local Yes Yes
> Gi0/4 4441/2  144local Yes Yes
> Gi0/5 5551/5  155local Yes Yes
> Gi0/6 6661/4  166local Yes 

Re: [c-nsp] Enhanced PAgP for VSS

[David Prall]

Has to be configured as trusted, which it isn't.

dual-active detection pagp trust channel-group 114

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configu
ration/guide/vss.html#wp1063913

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Church, Charles
> Sent: Thursday, August 26, 2010 10:41 PM
> To: nsp-cisco
> Subject: [c-nsp] Enhanced PAgP for VSS
> 
> Anyone,
> 
>   I've got a 6500 VSS pair running 12.2(33)SXI4, with an attached
> 4500
> running 12.2(54)SG.  From what I can tell, they should both support
> enhanced
> PAgP.  However, they don't seem to realize it, this is what they both
> tell
> me:
> 
> SCUCER02-05CRT01#sh pag 114 du (this is the 6500 VSS pair)
> PAgP dual-active detection enabled: Yes
> PAgP dual-active version: 1.1
> 
> Channel group 114 dual-active detect capability w/nbrs
> Dual-Active trusted group: No
>   Dual-Active Partner  Partner   Partner
> Port  Detect Capable  Name Port  Version
> Te1/3/5   No  SCUHQB02308UAS01.hq. Te5/1 N/A
> Te2/3/5   No  SCUHQB02308UAS01.hq. Te6/1 N/A
> SCUCER02-05CRT01#
> 
> SCUHQB02308UAS01#sh pag 10 du(this is the 4510)
> PAgP dual-active detection enabled: Yes
> PAgP dual-active version: 1.1
> 
> Channel group 10
>   Dual-Active Partner  Partner   Partner
> Port  Detect Capable  Name Port  Version
> Te5/1 No  SCUCER02-05CRT01 Te1/3/5   N/A
> Te6/1 No  SCUCER02-05CRT01 Te2/3/5   N/A
> SCUHQB02308UAS01#
> 
> It would appear that they both support it, there is a PAgP channel up
> (all 4
> links are desirable).  From what I've read, there isn't any
> configuration
> needed to enable this.  Any idea what might be wrong?
> 
> Thanks,
> 
> Chuck


___
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] Jumbo Frames Support on Datacenter Switches

[David Prall]

Carlos,
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6021/product_da
ta_sheet0900aecd8017a72e.html

Layer 2 Features
Jumbo frames on all ports (up to 9216 bytes)

Layer 3 Features
Jumbo frames on all ports (up to 9216 bytes)

David

--
http://dcp.dcptech.com

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Bulleri, Carlos
> Sent: Tuesday, August 24, 2010 10:21 AM
> To: 'cisco-nsp@puck.nether.net'
> Subject: [c-nsp] Jumbo Frames Support on Datacenter Switches
> 
> 
> We currently have a 4500 switch with a SupII+ on our Datacenter and all
> our server farm is ran through it. I'm trying to redesign our
> Architecture to add multiple path to  gain some redundancy so I'm
> trying to replace the one switch with 2 switches directly mounted on
> the server rack.
> 
> I'm looking at the 4900 series as a possibility, I like the capacity
> and throughput as well as the power redundancy options available, but I
> have a question in regards to Jumbo Frame support. The 4500 series will
> only support Jumbo frames on non-blocking ports. This limits the amount
> of ports available and I need to enable this feature on a larger amount
> of ports to increase performance on  our iSCSI storage device. I've
> found no documentation on the 4900 series in regards to jumbo frame
> support and I've even found some references indicating that they have
> the same limitation as their 4500 series predecessors.
> 
> Has anyone successfully implemented Jumbo Frames on a 4900 series?
> Should I be looking on a different line of switches all together??
> 
> 
> 
> Thanks!!
> 
> Carlos.
> 
> 
> 
> ___
> 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] Cisco 2960 Switch !!! WARNING: The switch is not usable !!!

[David Prall]

TCAM Memory would appear to be corrupt from the POST. Time for an RMA.

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Bayasgalan Bayantur
> Sent: Sunday, August 22, 2010 8:56 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Cisco 2960 Switch !!! WARNING: The switch is not
> usable !!!
> 
> Hello
> 
> can anybody plz advice me what is the problem with my 2960G switch
> 
> 
> switch:  reset
> Are you sure you want to reset the system (y/n)?y
> System resetting...
> 
> Base ethernet MAC Address: 00:22:91:a1:be:80
> Xmodem file system is available.
> The password-recovery mechanism is enabled.
> Initializing Flash...
> flashfs[0]: 604 files, 19 directories
> flashfs[0]: 0 orphaned files, 0 orphaned directories
> flashfs[0]: Total bytes: 32514048
> flashfs[0]: Bytes used: 8339968
> flashfs[0]: Bytes available: 24174080
> flashfs[0]: flashfs fsck took 10 seconds.
> ...done Initializing Flash.
> Boot Sector Filesystem (bs) installed, fsid: 3
> done.
> Loading
> "flash:c2960-lanbase-mz.122-35.SE5/c2960-lanbase-mz.122-
> 35.SE5.bin"...@@@
> 
> File "flash:c2960-lanbase-mz.122-35.SE5/c2960-lanbase-mz.122-
> 35.SE5.bin"
> uncompressed and installed, entry point: 0x3000
> executing...
> 
>   Restricted Rights Legend
> 
> Use, duplication, or disclosure by the Government is
> subject to restrictions as set forth in subparagraph
> (c) of the Commercial Computer Software - Restricted
> Rights clause at FAR sec. 52.227-19 and subparagraph
> (c) (1) (ii) of the Rights in Technical Data and Computer
> Software clause at DFARS sec. 252.227-7013.
> 
>cisco Systems, Inc.
>170 West Tasman Drive
>San Jose, California 95134-1706
> 
> 
> 
> Cisco IOS Software, C2960 Software (C2960-LANBASE-M), Version
> 12.2(35)SE5,
> RELEASE SOFTWARE (fc1)
> Copyright (c) 1986-2007 by Cisco Systems, Inc.
> Compiled Thu 19-Jul-07 20:06 by nachen
> Image text-base: 0x3000, data-base: 0x00D4
> 
> Initializing flashfs...
> 
> flashfs[1]: 604 files, 19 directories
> flashfs[1]: 0 orphaned files, 0 orphaned directories
> flashfs[1]: Total bytes: 32514048
> flashfs[1]: Bytes used: 8339968
> flashfs[1]: Bytes available: 24174080
> flashfs[1]: flashfs fsck took 1 seconds.
> flashfs[1]: Initialization completedone Initializing flashfs.
> 
> POST: CPU MIC register Tests : Begin
> POST: CPU MIC register Tests : End, Status Passed
> 
> POST: PortASIC Memory Tests : Begin
> POST: PortASIC Memory Tests : End, Status Passed
> 
> POST: CPU MIC interface Loopback Tests : Begin
> POST: CPU MIC interface Loopback Tests : End, Status Passed
> 
> POST: PortASIC RingLoopback Tests : Begin
> POST: PortASIC RingLoopback Tests : End, Status Passed
> 
> POST: PortASIC CAM Subsystem Tests : Begin
> TCAM (asic:3, bit: 5) address bus test failed
>   Write: 5A__-55__
>   Read:  5A__-51__
> HTD POST: Address Bus Test Failed
> POST: POST Failed
> POST: PortASIC CAM Subsystem Tests : End, Status Failed
> 
> POST: CAM test failed
> POST Failed: disabling stack links and shutting down SDP
> 
> driver class subsystem initialization failed
> 
> cisco WS-C2960G-24TC-L (PowerPC405) processor (revision E0) with
> 61440K/4088K bytes of memory.
> Processor board ID FOC1229V3PQ
> Last reset from power-on
> The password-recovery mechanism is enabled.
> 
> 64K bytes of flash-simulated non-volatile configuration memory.
> Base ethernet MAC Address   : 00:22:91:A1:BE:80
> Motherboard assembly number : 73-10015-06
> Power supply part number: 341-0098-02
> Motherboard serial number   : FOC12292LAY
> Power supply serial number  : DCA1227943W
> Model revision number   : E0
> Motherboard revision number : A0
> Model number: WS-C2960G-24TC-L
> System serial number: FOC1229V3PQ
> Top Assembly Part Number: 800-26673-03
> Top Assembly Revision Number: B0
> Version ID  : V03
> CLEI Code Number: COM3G00BRB
> Hardware Board Revision Number  : 0x01
> 
> 
> !!! WARNING: The switch is not usable !!!
> Unable to create l2trace server process, socket_open() failed
> 
> 
> Press RETURN to get started!
> 
> 
> 00:00:33: %SPANTREE-5-EXTENDED_SYSID: Extended SysId enabled for type
> vlanCannot Get the number of ports in MAC notification
> 
> 00:00:33: hl2mcm_core_process: hl2mcm_install_hl2mcm_ctrl_entries()
> failed.
> 
> 00:00:33: %SYS-3-HARIKARI: Process HL2MCM top-level routine exited
> 00:00:33: %SW_VLAN-4-IFS_FAILURE: VLAN manager encountered file
> operation
> error: call = ifs_read_until (header) / file =  / code = 21 (Is a
> directory)
> / bytes transfered = -1
> -Traceback= 1695B4 165664 BDD138 BD470C
> 00:00:34: %SYS-5-RESTART: System restarted --
> Cisco IOS Software, C2960 Software (C2960-LANBASE-M), Version
> 12.2(35)SE5,

Re: [c-nsp] Hiding MPLS L3VPN hops from the CE

[David Prall]

http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swi_m2.htm
l#wp1058956

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Jason Lixfeld
> Sent: Saturday, August 21, 2010 8:20 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Hiding MPLS L3VPN hops from the CE
> 
> Suppose a CE is connected to an MPLS network that has 6 hops between
> the PE this said CE connects to and the edge of the MPLS network.  If a
> user traces from behind the CE through the MPLS network, is it possible
> to hide all the hops in between?
> ___
> 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] Cisco Console access server

[David Prall]

NAT

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of venkat
> Sent: Thursday, July 29, 2010 9:28 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Cisco Console access server
> 
> Hi,
> 
>  Not sure, if i am posting on the right thread.
>  Is there any way to change the default (reverse) telnet port number
> on Cisco console access server (2500 series)? Checked some Cisco doc
> and
> it doesn't help.
> 
> For eg;
> 
> "telnet  2001" connects to the console of the device
> connected to port 1. For some reason, the device has to assume the base
> port# starts from 1 say, " telnet  10001"
> should
> connect to console connected to the 1st port. is there any way to make
> this
> change?
> 
> Thanks,
> Venkat
> ___
> 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] using the first and last ip address of a range > /24 in a local pool

[David Prall]

> > I even attempted to reproduce the problem with an XP (SP2)
> workstation
> > on a .255 myself, no success. Initiating and receiving connections
> > from other XP workstations worked just fine, on- and off-net.
> 
> Try connecting from a XP workstation to a .255 target address that is
> on a
> class "C" address. It will fail every time - doesn't even attempt to
> send
> the packet. That is the buggy behaviour in question. XP assumes that
> the
> remote endpoint has a classful subnet mask whereas it shouldn't
> actually
> care.
> 
> B.
>


Wrong, running XP SP2

D:\Tracking>tracert 192.0.2.255

Tracing route to 192.0.2.255 over a maximum of 30 hops

  1 1 ms 1 ms 1 ms  stealth-10-32-254-25.cisco.com
[10.32.254.25]
  2 *** Request timed out.
  3 *** Request timed out.
  4 *** Request timed out.
 
Next hop has uRPF and BOGON Filtering

D:\Tracking>tracert 220.1.1.255

Tracing route to softbank220001001255.bbtec.net [220.1.1.255]
over a maximum of 30 hops:

  1 1 ms 1 ms 1 ms  stealth-10-32-254-25.cisco.com
[10.32.254.25]
  2 2 ms 2 ms 2 ms  192.168.66.1
  3 3 ms 4 ms20 ms  192.168.255.25
  4 2 ms 2 ms 2 ms  192.168.255.9
  515 ms14 ms13 ms  dsl092-168-001.wdc2.dsl.speakeasy.net
[66.92.168.1]
  620 ms13 ms12 ms  220.ge-0-1-0.cr2.wdc1.speakeasy.net
[69.17.83.45]
  716 ms12 ms12 ms  10gigabitethernet2-2.core1.ash1.he.net
[206.223.115.37]
  896 ms98 ms99 ms  10gigabitethernet1-4.core1.pao1.he.net
[72.52.92.29]
  9   210 ms   193 ms   206 ms
SoftbankTelecom.10gigabitethernet2-2.core1.pao1.he.net [216.218.244.234]
 10   193 ms   193 ms   193 ms  sto-gw2-pos2-0.gw.odn.ad.jp
[210.142.163.169]
 11   197 ms   197 ms   197 ms  STOrw-51T2-1.nw.odn.ad.jp [143.90.33.90]
 12   193 ms   194 ms   193 ms  STOrz-02So0-0-0.nw.odn.ad.jp
[143.90.144.126]
 13   201 ms   201 ms   200 ms  238.143090232.odn.ne.jp [143.90.232.238]
 14

David

--
http://dcp.dcptech.com



___
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] Centos upload speed slower on 1000m than 100m over WAN links

[David Prall]

4948E

--
http://dcp.dcptech.com

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Benny Amorsen
> Sent: Sunday, June 27, 2010 12:13 PM
> To: Gert Doering
> Cc: cisco-nsp@puck.nether.net; Paul
> Subject: Re: [c-nsp] Centos upload speed slower on 1000m than 100m over
> WAN links
> 
> Gert Doering  writes:
> 
> > (Unfortunately, design goals for the 2960S/3750X were different than
> "get
> > this fixed", so the buffer size is the same)
> 
> If you want to stick with Cisco, do they have any similar products with
> larger buffers? I.e 24 or 48 1000base-T and some SFP/SFP+ uplink ports?
> 
> 
> /Benny
> 
> ___
> 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] VTY PROBLEM

[David Prall]

Do a "who" and see who has a hold of it. Then put an acl on the ingress
interface so deny it in and out. Your exec-timeout should eventually kick it
off. If not, at least they won't be able to connect again. I'd also do
"clear line 3" and confirm a couple of times.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: bha Qaqish [mailto:bha.qaq...@nitc.gov.jo]
> Sent: Tuesday, June 22, 2010 3:17 PM
> To: David Prall; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] VTY PROBLEM
> 
> It's the same , not cleared
> 
> Eng. Bha Qaqish
> 
> 
> 
> 
> -Original Message-
> From: David Prall [mailto:d...@dcptech.com]
> Sent: Tuesday, June 22, 2010 10:14 PM
> To: bha Qaqish; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] VTY PROBLEM
> 
> Should be "clear line 3"
> 
> David
> 
> --
> http://dcp.dcptech.com
> 
> 
> > -Original Message-
> > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> > boun...@puck.nether.net] On Behalf Of bha Qaqish
> > Sent: Tuesday, June 22, 2010 2:48 PM
> > To: Jeff Wojciechowski; cisco-nsp@puck.nether.net
> > Subject: Re: [c-nsp] VTY PROBLEM
> >
> > Yes
> > I can see the session in this command , and when I make the clear
> line
> > vty 3 for example , its not cleared. It still exist in the show
> > command
> >
> > Eng. Bha Qaqish
> >
> >
> > -Original Message-
> > From: Jeff Wojciechowski [mailto:jeff.wojciechow...@midlandpaper.com]
> > Sent: Tuesday, June 22, 2010 9:44 PM
> > To: bha Qaqish; cisco-nsp@puck.nether.net
> > Subject: RE: VTY PROBLEM
> >
> > Can you see the session using show line and then clear line X (where
> X=
> > line number of stuck VTY session)?
> >
> > -Jeff
> >
> > -Original Message-
> > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> > boun...@puck.nether.net] On Behalf Of bha Qaqish
> > Sent: Tuesday, June 22, 2010 1:27 PM
> > To: cisco-nsp@puck.nether.net
> > Subject: [c-nsp] VTY PROBLEM
> >
> >
> >
> >
> >
> > Dear
> > I have a 7206 VXR WITH npeg2, there is a problem, there is a telnet
> vty
> > sessions that stuck , I can not clear it , its stuck for 70 weeks , I
> > can not restart the router cause we are an ISP, so how could I clear
> > the sessions , I have a --- exec-timeout 60 0 --- on the vty.
> > Please help ASAP
> >
> >
> > BR
> >
> >
> > Eng. Bha Qaqish
> >
> >
> >
> >
> >
> >
> >
> > *
> >
> > ___
> > 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] VTY PROBLEM

[David Prall]

Should be "clear line 3"

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of bha Qaqish
> Sent: Tuesday, June 22, 2010 2:48 PM
> To: Jeff Wojciechowski; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] VTY PROBLEM
> 
> Yes
> I can see the session in this command , and when I make the clear line
> vty 3 for example , its not cleared. It still exist in the show
> command
> 
> Eng. Bha Qaqish
> 
> 
> -Original Message-
> From: Jeff Wojciechowski [mailto:jeff.wojciechow...@midlandpaper.com]
> Sent: Tuesday, June 22, 2010 9:44 PM
> To: bha Qaqish; cisco-nsp@puck.nether.net
> Subject: RE: VTY PROBLEM
> 
> Can you see the session using show line and then clear line X (where X=
> line number of stuck VTY session)?
> 
> -Jeff
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of bha Qaqish
> Sent: Tuesday, June 22, 2010 1:27 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] VTY PROBLEM
> 
> 
> 
> 
> 
> Dear
> I have a 7206 VXR WITH npeg2, there is a problem, there is a telnet vty
> sessions that stuck , I can not clear it , its stuck for 70 weeks , I
> can not restart the router cause we are an ISP, so how could I clear
> the sessions , I have a --- exec-timeout 60 0 --- on the vty.
> Please help ASAP
> 
> 
> BR
> 
> 
> Eng. Bha Qaqish
> 
> 
> 
> 
> 
> 
> 
> *
> 
> ___
> 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] VTY PROBLEM

[David Prall]

Exec-timeout is actively sending information on the vty so the 60 minute
timer is not kicking in it would appear. Do you have "service
tcp-keepalives-in" and "service tcp-keepalives-out" configured. This will
disconnect a session that isn't doing keepalives anymore. Of course it would
have to have been configured prior to the current session.

Sh line, then clear X where it is the VTY number, should clear it.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Jeff Wojciechowski
> Sent: Tuesday, June 22, 2010 2:44 PM
> To: bha Qaqish; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] VTY PROBLEM
> 
> Can you see the session using show line and then clear line X (where X=
> line number of stuck VTY session)?
> 
> -Jeff
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of bha Qaqish
> Sent: Tuesday, June 22, 2010 1:27 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] VTY PROBLEM
> 
> 
> 
> 
> 
> Dear
> I have a 7206 VXR WITH npeg2, there is a problem, there is a telnet vty
> sessions that stuck , I can not clear it , its stuck for 70 weeks , I
> can not restart the router cause we are an ISP, so how could I clear
> the sessions , I have a --- exec-timeout 60 0 --- on the vty.
> Please help ASAP
> 
> 
> BR
> 
> 
> Eng. Bha Qaqish
> 
> 
> 
> 
> 
> 
> 
> *
> 
> ___
> 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] Why doesn't this IPv6 ACL work?

[David Prall]

Very little difference between the two:
#sh sdm prefer dual-ipv4-and-ipv6 default

 "desktop IPv4 and IPv6 default" template:
 The selected template optimizes the resources in
 the switch to support this level of features for
 8 routed interfaces and 1024 VLANs.

  number of unicast mac addresses:  2K
  number of IPv4 IGMP groups + multicast routes:1K
  number of IPv4 unicast routes:3K
number of directly-connected IPv4 hosts:2K
number of indirect IPv4 routes: 1K
  number of IPv6 multicast groups:  1.125k
  number of directly-connected IPv6 addresses:  2K
  number of indirect IPv6 unicast routes:   1K
  number of IPv4 policy based routing aces: 0
  number of IPv4/MAC qos aces:  0.5K
  number of IPv4/MAC security aces: 1K
  number of IPv6 policy based routing aces: 0
  number of IPv6 qos aces:  0.5K
  number of IPv6 security aces: 0.5K

#sh sdm prefer dual-ipv4-and-ipv6 routing

 "desktop IPv4 and IPv6 routing" template:
 The selected template optimizes the resources in
 the switch to support this level of features for
 8 routed interfaces and 1024 VLANs.

  number of unicast mac addresses:  1.5K
  number of IPv4 IGMP groups + multicast routes:1K
  number of IPv4 unicast routes:2.75K
number of directly-connected IPv4 hosts:1.5K
number of indirect IPv4 routes: 1.25K
  number of IPv6 multicast groups:  1.125k
  number of directly-connected IPv6 addresses:  1.5K
  number of indirect IPv6 unicast routes:   1.25K
  number of IPv4 policy based routing aces: 0.25K
  number of IPv4/MAC qos aces:  0.5K
  number of IPv4/MAC security aces: 0.5K
  number of IPv6 policy based routing aces: 0.25K
  number of IPv6 qos aces:  0.5K
  number of IPv6 security aces: 0.5K

Security ACES are exactly the same. I'm doing this on a 3560G as compared to
a 3750, but close enough.

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Seth Mattinen
> Sent: Monday, June 21, 2010 10:01 PM
> To: 'Cisco-nsp'
> Subject: Re: [c-nsp] Why doesn't this IPv6 ACL work?
> 
> On 6/21/2010 18:48, David Prall wrote:
> > What is the SDM Template that you are using? What version of code?
> >
> > Just tried this on 12.2(46)SE
> >
> 
> I'm 12.2(53)SE2 on this switch.
> 
> 
> > The current template is "desktop IPv4 and IPv6 routing" template.
> >
> 
> Mine is set to "desktop IPv4 and IPv6 default"
> 
> > Without any issue.
> >
> 
> 
> I tried changing the prefix to be out of my old /48 instead as a shot
> in
> the dark, and it didn't throw an error at me with this entry:
> 
> permit tcp any host 2620:0:950:1:2c0:f0ff:fe5a:abe8 eq 25
> 
> However, this continues to not work:
> 
> permit tcp any host 2607:fe70:0:1:2c0:f0ff:fe5a:abe8 eq 25
> 
> I can try switching to "routing" instead of "default" template.
> Otherwise I guess it's iptables/ip6tables time for me if this thing
> won't accept host addresses under my /32.
> 
> ~Seth
> ___
> 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] Why doesn't this IPv6 ACL work?

[David Prall]

What is the SDM Template that you are using? What version of code?

Just tried this on 12.2(46)SE

The current template is "desktop IPv4 and IPv6 routing" template.

Without any issue.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Seth Mattinen
> Sent: Monday, June 21, 2010 8:59 PM
> To: 'Cisco-nsp'
> Subject: [c-nsp] Why doesn't this IPv6 ACL work?
> 
> I just got this confusing error message with an IPv6 ACL:
> 
> % This ACL contains following unsupported entries.
> % Remove those entries and try again.
> permit tcp any host 2607:FE70:0:1:2C0:F0FF:FE5A:ABE8 sequence 30
> % This ACL can not be attached to the interface.
> 
> This platform is a 3750 switch, but I thought EUI-64 formatted hosts
> were supported (they were in the past anyway), so now I'm confused.
> Anyone know why this was rejected by the switch?
> 
> ~Seth
> ___
> 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] 6500 latency

[David Prall]

Jeff,
This is an old document. But it gives the numbers.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_
paper0900aecd800c9589.pdf

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Jeff Bacon
> Sent: Tuesday, April 27, 2010 8:56 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] 6500 latency
> 
> OK, I know that a 6500 is not a super low latency box. I've seen around
> 17usec, card to card to another switch CFC mode, but due to time
> constraints have done little formal analysis.
> 
> 
> I'm guessing its better in DFC mode, and on 6700 cards, and if your
> traffic is local to a card or to a fabric port such that it doesn't
> have to traverse the fabric.
> 
> I'm also guessing that sup32s and anything on classic bus (including
> the two interfaces on the sup720) aren't super-high latency either.
> 
> Has anyone done any work on what the overall parameters are on a 6500's
> switching latency? Or got a pliable cisco rep who can get me to someone
> who can unlock those documents?
> 
> Clearly Cisco has, to the extent that a cisco exec told me yesterday
> that they see no role for the 6500 in low-latency financial market apps
> except in edge cases where NAT is needed and even then I should
> consider an ASR (of course they need to sell more nexii I imagine - but
> what, am I made of money???). Strangely, though, I find them highly
> reticent to share anything about the actual facts of the matter. Maybe
> they're annoyed that I buy mostly refurb gear. :)
> 
> (Then again, I tend to find that most micro-level-latency talk to be
> half marketing fluff and mantra, and/or an excuse to spend a ton more
> money on product X.)
> 
> It's a shame that most exchanges force me to NAT to talk to them unless
> I want to do Really Stupid Things with my network, or talk ARIN out of
> a /22. Which is why I have 6500s everywhere (and sometimes wonder about
> the wisdom thereof, given the costs).
> 
> OK, I admit I am ranting.
> ___
> 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] WiMAX Download

[David Prall]

I'd say long fat pipe issues.

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Mohammad Khalil
> Sent: Tuesday, April 27, 2010 9:31 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] WiMAX Download
> 
> 
> Dears
> 
> many of the customers who uses our WiMAX service claims that they
> cannot get their full speed using one session , when they open more
> than 1 session they can almost get all the speed , is that reasonable ?
> is it related to network infrastructure or WiMAX infrastructure (ASN GW
> and CPEs)
> 
> Thanks in advance
> 
> 
> 
> _
> Hotmail: Free, trusted and rich email service.
> https://signup.live.com/signup.aspx?id=60969
> ___
> 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] Cisco 3750 High CPU

[David Prall]

I'd guess a spanning tree loop. The HULC process is what updates the pretty
lights on the switch. So much is happening that it is having to change all
the colors constantly.

What other messages are you seeing. 

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Chris Lane
> Sent: Wednesday, April 07, 2010 3:17 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Cisco 3750 High CPU
> 
> Hello,
> 
> I have all the sudden taken extremely high CPU:
> sh proc cpu sorted | e 0.0
> CPU utilization for five seconds: 99%/27%; one minute: 95%; five
> minutes:
> 92%
>  PID Runtime(ms)   Invoked  uSecs   5Sec   1Min   5Min TTY Process
>  251 2985921 15274 195490 39.29% 11.05%  6.01%   0 hulc
> running
> con
>  171   630974187 249381380   2530 10.38%  9.27%  9.45%   0 Spanning
> Tree
> 
>  117   133871232 301668428443  4.63%  8.34%  9.47%   0 Hulc LED
> Process
>   68 3766455 374577924 10  4.15%  3.66%  3.20%   0 HLFM
> address
> lea
>  137   221859624  12599002  17609  2.39%  2.02%  2.05%   0 PI MATM
> Aging
> Pr
>  168   175580828 496683600353  1.91%  3.89%  2.90%   0 IP Input
> 
>   52 8324282 665636083 12  0.79%  0.43%  0.35%   0 Fifo
> Error
> Detec
> 
> I know this isn't much but could anyone offer assistance?
> 
> Thanks
> Chris
> 
> 
> 
> --
> //CL
> ___
> 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] Using NAT with servers and dual ISP

[David Prall]

> > My consfusin is handling inbound connections to the customer servers.
> > I can define inbound static mappings but how do the packets that the
> > server sends in response make it way through the router and avoid
> > going out the wrong interface.
> 
> Although it is a bit of a hack, one way of doing this is to put a
> second IP
> address on the server in question and NAT to that address on the second
> inbound service instead. That way you can identify the packets.
> 
> B.
> 


And use PBR to return based on source address. You can also use DNS to load
balance the requests to each address based on site, and if you want to get
fancy use views to respond to requests via the interface they were received
on with addresses on that interface.

--
http://dcp.dcptech.com



___
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] PFR Question

[David Prall]

Jack,
PfR gives the customer control. Basically makes it so the CE can monitor and 
make decisions about reachability for high value destinations. Doesn't matter 
what the provider is doing, although the customer should be paying for 
appropriate SLA's if they are required. The core should do what is necessary to 
meet the customer requirements. The customer can then purchase service from 2 
providers and use PfR to reroute over the other in the instance of a brownout, 
or high jitter, latency, or whatever your concerned about.

David
> 
> --0050450163334520ec0482d5c8b4
> Content-Type: text/plain; charset=ISO-8859-1
> 
> I found on internet
> 
> MPLS VPN LOCAL LABEL - with BGP
> 
> basically this is via advertising same label on primary PE for prefix for
> both primary and secondary paths.So that if primary path fails then same
> label can be used to Primary PE ( primary PE CE link down) ,,, then Primary
> PE route traffic to secondary CE .
> 
> 
> Regards
> 
> 
> 
> On 3/28/10, David Prall  wrote:
> >
> > PfR takes care of the rerouting on a site basis. The site is monitoring
> > reachability to a particular prefix. The key issue with a single cloud, is
> > that you don't control the end to end path. If it is two clouds then you
> > can
> > monitor end to end via each cloud, and choose which one is better to use
> > for
> > a particular prefix or traffic type.
> >
> > --
> > http://dcp.dcptech.com
> >
> >
> > > -Original Message-
> > > From: jack daniels [mailto:jckdaniel...@gmail.com]
> > > Sent: Friday, March 26, 2010 10:20 PM
> > > To: David Prall
> > > Cc: cisco-nsp@puck.nether.net
> > > Subject: Re: [c-nsp] PFR Question
> > >
> > > IN SCENARIO BOTH LINKS FROM SAME SERVICE PROVIDER -But how will this
> > > avoid drops when PE1and CE1 link goes down as MPBGP bring secondary
> > > path as best in BGP table ( MPLS domain )and then to routing table will
> > > take atleast 3 min.
> > > Till secondry path not in routing table there will be pcket drops.So
> > > PE3 will converge so fast.
> > >
> > >
> > >
> > > On 3/26/10, David Prall  wrote:
> > >
> > >   This is where PfR is involved to route around the primary carrier
> > > to the
> > >   secondary.
> > >
> > >   --
> > >   http://dcp.dcptech.com
> > >
> > >   > -Original Message-
> > >   > From: jack daniels [mailto:jckdaniel...@gmail.com]
> > >   > Sent: Thursday, March 25, 2010 8:50 PM
> > >   > To: David Prall
> > >   > Cc: cisco-nsp@puck.nether.net
> > >   > Subject: Re: [c-nsp] PFR Question
> > >   >
> > >   > Hi David,
> > >   >
> > >   > In a multipath instance PE1 will install the Equal Cost route
> > > with rd
> > >   > 1:1
> > >   > first, using 1:2 as a secondary path only. Opposite on PE2.???
> > >   > whne both paths have equal cost the why route with rd1:1 will
> > > be
> > >   > primary always
> > >   > and rd 1:2 will be secondary on PE1.
> > >   >
> > >   > EVEN IF WE advertise X.X.X.X from PE1 and PE2 still PE3 will
> > > have two
> > >   > routes in BGP table . But one in routing table.
> > >   > But how will this avoid drops when PE1and CE1 link goes down as
> > > BGP
> > >   > bring secondary path to Primary and then to routing table will
> > > take
> > >   > atleast 3 min.
> > >   >
> > >   > Regards
> > >   >
> > >   >
> > >   >
> > >   > On Fri, Mar 26, 2010 at 12:29 AM, David Prall 
> > > wrote:
> > >   >
> > >   >
> > >   >   1)
> > >   >   On PE1
> > >   >vrf description customer
> > >   >rd 1:1
> > >   >route-target both 1:1
> > >   >route-target import 1:2
> > >   >   On PE2
> > >   >vrf description customer
> > >   >rd 1:2
> > >   >route-target both 1:2
> > >   >route-target import 1:1
> > >   >
> > >   >   In a multipath instance PE1 will install the Equal Cost
> > > route
> > >   > with rd 1:1
> > &

Re: [c-nsp] PFR Question

[David Prall]

PfR takes care of the rerouting on a site basis. The site is monitoring
reachability to a particular prefix. The key issue with a single cloud, is
that you don't control the end to end path. If it is two clouds then you can
monitor end to end via each cloud, and choose which one is better to use for
a particular prefix or traffic type. 

--
http://dcp.dcptech.com


> -Original Message-
> From: jack daniels [mailto:jckdaniel...@gmail.com]
> Sent: Friday, March 26, 2010 10:20 PM
> To: David Prall
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] PFR Question
> 
> IN SCENARIO BOTH LINKS FROM SAME SERVICE PROVIDER -But how will this
> avoid drops when PE1and CE1 link goes down as MPBGP bring secondary
> path as best in BGP table ( MPLS domain )and then to routing table will
> take atleast 3 min.
> Till secondry path not in routing table there will be pcket drops.So
> PE3 will converge so fast.
> 
> 
> 
> On 3/26/10, David Prall  wrote:
> 
>   This is where PfR is involved to route around the primary carrier
> to the
>   secondary.
> 
>   --
>   http://dcp.dcptech.com
> 
>   > -Original Message-
>   > From: jack daniels [mailto:jckdaniel...@gmail.com]
>   > Sent: Thursday, March 25, 2010 8:50 PM
>   > To: David Prall
>   > Cc: cisco-nsp@puck.nether.net
>   > Subject: Re: [c-nsp] PFR Question
>   >
>   > Hi David,
>   >
>   > In a multipath instance PE1 will install the Equal Cost route
> with rd
>   > 1:1
>   > first, using 1:2 as a secondary path only. Opposite on PE2.???
>   > whne both paths have equal cost the why route with rd1:1 will
> be
>   > primary always
>   > and rd 1:2 will be secondary on PE1.
>   >
>   > EVEN IF WE advertise X.X.X.X from PE1 and PE2 still PE3 will
> have two
>   > routes in BGP table . But one in routing table.
>   > But how will this avoid drops when PE1and CE1 link goes down as
> BGP
>   > bring secondary path to Primary and then to routing table will
> take
>   > atleast 3 min.
>   >
>   > Regards
>   >
>   >
>   >
>   > On Fri, Mar 26, 2010 at 12:29 AM, David Prall 
> wrote:
>   >
>   >
>   >   1)
>   >   On PE1
>   >vrf description customer
>   >rd 1:1
>   >route-target both 1:1
>   >route-target import 1:2
>   >   On PE2
>   >vrf description customer
>   >rd 1:2
>   >route-target both 1:2
>   >route-target import 1:1
>   >
>   >   In a multipath instance PE1 will install the Equal Cost
> route
>   > with rd 1:1
>   >   first, using 1:2 as a secondary path only. Opposite on
> PE2.
>   >
>   >   2)
>   >   Could use different VRF's. Just like dual carriers. A key
> concern
>   > is a dual
>   >   failure, site 1 on network 1 and site 2 on network 2. The
>   > customer will need
>   >   to provide a path between the two networks via one of
> their
>   > sites.
>   >
>   >
>   >   David
>   >
>   >   --
>   >   http://dcp.dcptech.com <http://dcp.dcptech.com/>
>   >
>   >
>   >   > -Original Message-
>   >   > From: jack daniels [mailto:jckdaniel...@gmail.com]
>   >
>   >   > Sent: Thursday, March 25, 2010 2:41 PM
>   >   > To: David Prall
>   >   > Cc: cisco-nsp@puck.nether.net
>   >   > Subject: Re: [c-nsp] PFR Question
>   >   >
>   >
>   >   > Hi David ,
>   >   >
>   >   > thanks man I got the basic idea :)
>   >   >
>   >   > 1) but please explain in more detail this
>   >   >
>   >   > Single VRF, 2 distinct RD's. The VRF imports both,
> exports one.
>   > The
>   >   > RD's are
>   >   > different so that multipath can be used within the core
>   > typically. But
>   >   > in
>   >   > this case they wouldn't use multipath and the local RD
> would be
>   > used as
>   >   > the
>   >   > determining factor on import of which route is
> installed
>   > first.??
>   >   >
&

Re: [c-nsp] PFR Question

[David Prall]

This is where PfR is involved to route around the primary carrier to the
secondary.

--
http://dcp.dcptech.com

> -Original Message-
> From: jack daniels [mailto:jckdaniel...@gmail.com]
> Sent: Thursday, March 25, 2010 8:50 PM
> To: David Prall
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] PFR Question
> 
> Hi David,
> 
> In a multipath instance PE1 will install the Equal Cost route with rd
> 1:1
> first, using 1:2 as a secondary path only. Opposite on PE2.???
> whne both paths have equal cost the why route with rd1:1 will be
> primary always
> and rd 1:2 will be secondary on PE1.
> 
> EVEN IF WE advertise X.X.X.X from PE1 and PE2 still PE3 will have two
> routes in BGP table . But one in routing table.
> But how will this avoid drops when PE1and CE1 link goes down as BGP
> bring secondary path to Primary and then to routing table will take
> atleast 3 min.
> 
> Regards
> 
> 
> 
> On Fri, Mar 26, 2010 at 12:29 AM, David Prall  wrote:
> 
> 
>   1)
>   On PE1
>vrf description customer
>rd 1:1
>route-target both 1:1
>route-target import 1:2
>   On PE2
>vrf description customer
>rd 1:2
>route-target both 1:2
>route-target import 1:1
> 
>   In a multipath instance PE1 will install the Equal Cost route
> with rd 1:1
>   first, using 1:2 as a secondary path only. Opposite on PE2.
> 
>   2)
>   Could use different VRF's. Just like dual carriers. A key concern
> is a dual
>   failure, site 1 on network 1 and site 2 on network 2. The
> customer will need
>   to provide a path between the two networks via one of their
> sites.
> 
> 
>   David
> 
>   --
>   http://dcp.dcptech.com <http://dcp.dcptech.com/>
> 
> 
>   > -Original Message-
>   > From: jack daniels [mailto:jckdaniel...@gmail.com]
> 
>   > Sent: Thursday, March 25, 2010 2:41 PM
>   > To: David Prall
>   > Cc: cisco-nsp@puck.nether.net
>   > Subject: Re: [c-nsp] PFR Question
>   >
> 
>   > Hi David ,
>   >
>   > thanks man I got the basic idea :)
>   >
>   > 1) but please explain in more detail this
>   >
>   > Single VRF, 2 distinct RD's. The VRF imports both, exports one.
> The
>   > RD's are
>   > different so that multipath can be used within the core
> typically. But
>   > in
>   > this case they wouldn't use multipath and the local RD would be
> used as
>   > the
>   > determining factor on import of which route is installed
> first.??
>   >
>   >
>   > 2) Also if I use diffrent VRF for CE4---CE2 path that will also
> work -
>   > ??
>   >
>   >
>   > On Thu, Mar 25, 2010 at 11:57 PM, David Prall 
> wrote:
>   >
>   >
>   >   If the link goes away, then the update should be pretty
> quick.
>   >
>   >   Single VRF, 2 distinct RD's. The VRF imports both,
> exports one.
>   > The RD's are
>   >   different so that multipath can be used within the core
>   > typically. But in
>   >   this case they wouldn't use multipath and the local RD
> would be
>   > used as the
>   >   determining factor on import of which route is installed
> first.
>   >
>   >   The local CE (CE3) is probing for the subnet at CE1. When
> it is
>   > no longer
>   >   reachable by CE3 it will move the route to CE4. As long
> as CE4 is
>   > using CE2
>   >   as the path via the cloud then no issue.
>   >
>   >
>   >   David
>   >
>   >   --
> 
>   >   http://dcp.dcptech.com <http://dcp.dcptech.com/>
> <http://dcp.dcptech.com/>
> 
>   >
>   >
>   >   > -Original Message-
>   >   > From: jack daniels [mailto:jckdaniel...@gmail.com]
>   >
>   >   > Sent: Thursday, March 25, 2010 2:19 PM
>   >   > To: David Prall
>   >   > Cc: cisco-nsp@puck.nether.net
>   >   > Subject: Re: [c-nsp] PFR Question
>   >   >
>   >
>   >   > If a single carrier, then the CE4/CE2 path needs to be
> via
>   >   > a second RD so that the paths within the carrier are
> preferred
>   > and the
>   >  

Re: [c-nsp] PFR Question

[David Prall]

1)
On PE1
 vrf description customer
  rd 1:1
  route-target both 1:1
  route-target import 1:2
On PE2
 vrf description customer
  rd 1:2
  route-target both 1:2
  route-target import 1:1

In a multipath instance PE1 will install the Equal Cost route with rd 1:1
first, using 1:2 as a secondary path only. Opposite on PE2. 

2)
Could use different VRF's. Just like dual carriers. A key concern is a dual
failure, site 1 on network 1 and site 2 on network 2. The customer will need
to provide a path between the two networks via one of their sites.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: jack daniels [mailto:jckdaniel...@gmail.com]
> Sent: Thursday, March 25, 2010 2:41 PM
> To: David Prall
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] PFR Question
> 
> Hi David ,
> 
> thanks man I got the basic idea :)
> 
> 1) but please explain in more detail this
> 
> Single VRF, 2 distinct RD's. The VRF imports both, exports one. The
> RD's are
> different so that multipath can be used within the core typically. But
> in
> this case they wouldn't use multipath and the local RD would be used as
> the
> determining factor on import of which route is installed first.??
> 
> 
> 2) Also if I use diffrent VRF for CE4---CE2 path that will also work -
> ??
> 
> 
> On Thu, Mar 25, 2010 at 11:57 PM, David Prall  wrote:
> 
> 
>   If the link goes away, then the update should be pretty quick.
> 
>   Single VRF, 2 distinct RD's. The VRF imports both, exports one.
> The RD's are
>   different so that multipath can be used within the core
> typically. But in
>   this case they wouldn't use multipath and the local RD would be
> used as the
>   determining factor on import of which route is installed first.
> 
>   The local CE (CE3) is probing for the subnet at CE1. When it is
> no longer
>   reachable by CE3 it will move the route to CE4. As long as CE4 is
> using CE2
>   as the path via the cloud then no issue.
> 
> 
>   David
> 
>   --
>   http://dcp.dcptech.com <http://dcp.dcptech.com/>
> 
> 
>   > -Original Message-
>   > From: jack daniels [mailto:jckdaniel...@gmail.com]
> 
>   > Sent: Thursday, March 25, 2010 2:19 PM
>   > To: David Prall
>   > Cc: cisco-nsp@puck.nether.net
>   > Subject: Re: [c-nsp] PFR Question
>   >
> 
>   > If a single carrier, then the CE4/CE2 path needs to be via
>   > a second RD so that the paths within the carrier are preferred
> and the
>   > same
>   > will happen.
>   > DO YOU mean we need to have diifrent vrf on secondry end to end
> path.
>   >
>   > I didnt get this if single carrier as link PE1 and CE1 link
> fails
>   > CE3 send traffic for X.X.X.X to PE3.PE3 still has next hop
> in its
>   > vrf table as PE1
>   >
>   >
>   >
>   >
>   > Please help me as still confused if two carriers , how will
> this
>   > hhappen
>   >
>   >
>   > On Thu, Mar 25, 2010 at 11:29 PM, David Prall 
> wrote:
>   >
>   >
>   >   Is MPLS Domain a single carrier, or two carriers. If two
> carriers
>   > then the
>   >   CE3/CE4 site will see that they can't reach via CE3/CE1
> path and
>   > switch over
>   >   to CE4/CE2 path. If a single carrier, then the CE4/CE2
> path needs
>   > to be via
>   >   a second RD so that the paths within the carrier are
> preferred
>   > and the same
>   >   will happen. PfR is providing end-to-end reachability
> information
>   > in this
>   >   case, and based on that changing the local routing table.
>   >
>   >   David
>   >
>   >
>   >   --
> 
>   >   http://dcp.dcptech.com <http://dcp.dcptech.com/>
> <http://dcp.dcptech.com/>
> 
>   >
>   >
>   >   > -Original Message-
>   >
>   >   > From: jack daniels [mailto:jckdaniel...@gmail.com]
>   >   > Sent: Thursday, March 25, 2010 1:07 PM
>   >   > To: David Prall
>   >   > Cc: cisco-nsp@puck.nether.net
>   >   > Subject: Re: [c-nsp] PFR Question
>   >   >
>   >
>   >   > But if you have --
>   >   >
>   >   >
>   >   >   |CE1PE1
>   >  

Re: [c-nsp] PFR Question

[David Prall]

If the link goes away, then the update should be pretty quick. 

Single VRF, 2 distinct RD's. The VRF imports both, exports one. The RD's are
different so that multipath can be used within the core typically. But in
this case they wouldn't use multipath and the local RD would be used as the
determining factor on import of which route is installed first. 

The local CE (CE3) is probing for the subnet at CE1. When it is no longer
reachable by CE3 it will move the route to CE4. As long as CE4 is using CE2
as the path via the cloud then no issue.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: jack daniels [mailto:jckdaniel...@gmail.com]
> Sent: Thursday, March 25, 2010 2:19 PM
> To: David Prall
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] PFR Question
> 
> If a single carrier, then the CE4/CE2 path needs to be via
> a second RD so that the paths within the carrier are preferred and the
> same
> will happen.
> DO YOU mean we need to have diifrent vrf on secondry end to end path.
> 
> I didnt get this if single carrier as link PE1 and CE1 link fails
> CE3 send traffic for X.X.X.X to PE3.PE3 still has next hop in its
> vrf table as PE1
> 
> 
> 
> 
> Please help me as still confused if two carriers , how will this
> hhappen
> 
> 
> On Thu, Mar 25, 2010 at 11:29 PM, David Prall  wrote:
> 
> 
>   Is MPLS Domain a single carrier, or two carriers. If two carriers
> then the
>   CE3/CE4 site will see that they can't reach via CE3/CE1 path and
> switch over
>   to CE4/CE2 path. If a single carrier, then the CE4/CE2 path needs
> to be via
>   a second RD so that the paths within the carrier are preferred
> and the same
>   will happen. PfR is providing end-to-end reachability information
> in this
>   case, and based on that changing the local routing table.
> 
>   David
> 
> 
>   --
>   http://dcp.dcptech.com <http://dcp.dcptech.com/>
> 
> 
>   > -Original Message-
> 
>   > From: jack daniels [mailto:jckdaniel...@gmail.com]
>   > Sent: Thursday, March 25, 2010 1:07 PM
>   > To: David Prall
>   > Cc: cisco-nsp@puck.nether.net
>   > Subject: Re: [c-nsp] PFR Question
>   >
> 
>   > But if you have --
>   >
>   >
>   >   |CE1PE1
>   > PE3CE3
>   >  X.X.X.X-| MPLS
> DOMAIN-
>   > --
>   >  |  CE2PE2
>   > PE4CE4
>   >
>   >
>   > Now my primary link is CE1-PE1 and secondary is CE2-PE2
>   > If my CE1-PE1 goes down i route traffic via CE2-PE2<<<<< understand
>   > this ok...
>   >
>   > when traffic from CE3 for X.X.X.X reaches PE3 , next hop is
> still PE1 (
>   > as MPBGP has not converged so fast in MPLS domain of SP) ...so
> how will
>   > traffic be forwareded , as PFR claims 3 sec.
>   >
>   >
>   > On Thu, Mar 25, 2010 at 10:16 PM, David Prall 
> wrote:
>   >
>   >
>   >   PfR is a unidirectional feature. The router on the other
> end
>   > needs to be
>   >   configured with PfR as well in order to have
> bidirectional
>   > visibility.
>   >   Typically the master controller will be local to the
> site.
>   >
>   >   --
> 
>   >   http://dcp.dcptech.com <http://dcp.dcptech.com/>
> <http://dcp.dcptech.com/>
> 
>   >
>   >
>   >
>   >   > -Original Message-
>   >   > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-
> nsp-
>   >   > boun...@puck.nether.net] On Behalf Of jack daniels
>   >   > Sent: Thursday, March 25, 2010 12:35 PM
>   >   > To: cisco-nsp@puck.nether.net
>   >   > Subject: Re: [c-nsp] PFR Question
>   >   >
>   >   > dear guys,
>   >   >
>   >   > is my mail being delivered to group as no one replied.
>   >   >
>   >   > On Wed, Mar 24, 2010 at 11:42 PM, jack daniels
>   >   > wrote:
>   >   >
>   >   > > Hi Network champs,
>   >   > >
>   >   > > I'm stuck in understanding of PFR . Docs say it
> converges in
>   > 3 sec (
>   >   > for
>   >   > > realtime traffic VOICE )..

Re: [c-nsp] PFR Question

[David Prall]

Is MPLS Domain a single carrier, or two carriers. If two carriers then the
CE3/CE4 site will see that they can't reach via CE3/CE1 path and switch over
to CE4/CE2 path. If a single carrier, then the CE4/CE2 path needs to be via
a second RD so that the paths within the carrier are preferred and the same
will happen. PfR is providing end-to-end reachability information in this
case, and based on that changing the local routing table. 

David

--
http://dcp.dcptech.com


> -Original Message-
> From: jack daniels [mailto:jckdaniel...@gmail.com]
> Sent: Thursday, March 25, 2010 1:07 PM
> To: David Prall
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] PFR Question
> 
> But if you have --
> 
> 
>   |CE1PE1
> PE3CE3
>  X.X.X.X-| MPLS DOMAIN-
> --
>  |  CE2PE2
> PE4CE4
> 
> 
> Now my primary link is CE1-PE1 and secondary is CE2-PE2
> If my CE1-PE1 goes down i route traffic via CE2-PE2<<<<< this ok...
> 
> when traffic from CE3 for X.X.X.X reaches PE3 , next hop is still PE1 (
> as MPBGP has not converged so fast in MPLS domain of SP) ...so how will
> traffic be forwareded , as PFR claims 3 sec.
> 
> 
> On Thu, Mar 25, 2010 at 10:16 PM, David Prall  wrote:
> 
> 
>   PfR is a unidirectional feature. The router on the other end
> needs to be
>   configured with PfR as well in order to have bidirectional
> visibility.
>   Typically the master controller will be local to the site.
> 
>   --
>   http://dcp.dcptech.com <http://dcp.dcptech.com/>
> 
> 
> 
>   > -Original Message-
>   > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
>   > boun...@puck.nether.net] On Behalf Of jack daniels
>   > Sent: Thursday, March 25, 2010 12:35 PM
>   > To: cisco-nsp@puck.nether.net
>   > Subject: Re: [c-nsp] PFR Question
>   >
>   > dear guys,
>   >
>   > is my mail being delivered to group as no one replied.
>   >
>   > On Wed, Mar 24, 2010 at 11:42 PM, jack daniels
>   > wrote:
>   >
>   > > Hi Network champs,
>   > >
>   > > I'm stuck in understanding of PFR . Docs say it converges in
> 3 sec (
>   > for
>   > > realtime traffic VOICE )...
>   > >
>   > > I understand you can send traffic out secondry link but what
> about
>   > traffic
>   > > which has to come back from remote end ( for which SP has not
>   > converged).
>   > >
>   > > But if you have --
>   > >
>   > >
>   > >
>   > > |CE1PE1
>   > > PE3CE3
>   > >  X.X.X.X-| MPLS
>   > > DOMAIN---
>   > >  |  CE2PE2
>   > > PE4CE4
>   > >
>   > >
>   > > Now my primary link is CE1-PE1 and secondary is CE2-PE2
>   > > If my CE1-PE1 goes down i route traffic via CE2-PE2<<<<< understand
>   > this
>   > > ok...
>   > >
>   > >
>   > > BUT MY QUESTION IS -
>   > >
>   > > PE3 and PE4 ( for this VRF) still has NOW converged the BGP
> and still
>   > for
>   > > it next hop for X.X.X.X is PE1. So how fwd can happen in 3
> sec untill
>   > > Service providers all routers dont converge and understand
> that CE1-
>   > PE1 link
>   > > is down.
>   > >
>   > >
>   > > Regards
>   > >
>   > >
> 
>   > ___
>   > 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] PFR Question

[David Prall]

PfR is a unidirectional feature. The router on the other end needs to be
configured with PfR as well in order to have bidirectional visibility.
Typically the master controller will be local to the site.

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of jack daniels
> Sent: Thursday, March 25, 2010 12:35 PM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] PFR Question
> 
> dear guys,
> 
> is my mail being delivered to group as no one replied.
> 
> On Wed, Mar 24, 2010 at 11:42 PM, jack daniels
> wrote:
> 
> > Hi Network champs,
> >
> > I'm stuck in understanding of PFR . Docs say it converges in 3 sec (
> for
> > realtime traffic VOICE )...
> >
> > I understand you can send traffic out secondry link but what about
> traffic
> > which has to come back from remote end ( for which SP has not
> converged).
> >
> > But if you have --
> >
> >
> >
> > |CE1PE1
> > PE3CE3
> >  X.X.X.X-| MPLS
> > DOMAIN---
> >  |  CE2PE2
> > PE4CE4
> >
> >
> > Now my primary link is CE1-PE1 and secondary is CE2-PE2
> > If my CE1-PE1 goes down i route traffic via CE2-PE2< this
> > ok...
> >
> >
> > BUT MY QUESTION IS -
> >
> > PE3 and PE4 ( for this VRF) still has NOW converged the BGP and still
> for
> > it next hop for X.X.X.X is PE1. So how fwd can happen in 3 sec untill
> > Service providers all routers dont converge and understand that CE1-
> PE1 link
> > is down.
> >
> >
> > Regards
> >
> >
> ___
> 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] Using L3 switches as CPE

[David Prall]

> Hi all,
> 
> I'm going to be deploying some old 3550's as CPE on a
> Fibre-over-Ethernet network. I've never used a layer-3 switch for this
> job before, I've always used a router with a separate switch. I'm
> looking for some advice, as the setup is a bit different from what I'm
> used to.
> 
> What I think I have to do is this:
> 
> - trunk vlan 768 through gi0/1 back to my PE router

Just set the port as an access port. No need to trunk.


> - configure an int vlan768 to contain the /30 ptp IP

Correct

> - configure a second vlan (eg: 5) and apply one of the client's IP
> addresses on it (which will act as their default gw)

Correct

> - configure the fa interfaces as access ports for vlan 5
> - enable ip-routing
> - set up BGP as usual, using int vlan768 as the update-source

Shouldn't have to explicitly configure this.

> 
> Does this sound right? Can anyone offer any other advice regarding this
> setup, particularly any config techniques that I should know about for
> this type of deployment?
> 

As long as the GigE port is line rate you shouldn't have any issues. If you
are providing a subrate service, then they really need something with HQoS
so that they can send what they want, and not let you randomly drop what
they send.

> Steve
> ___
> 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] Sup720 CoPP, limits on CPU performance

[David Prall]

Rodney,
Just span the RP traffic. 

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper
_c11_553261.html

For ISIS you need to create a class that matches all ip traffic, then use
the class-default for everything that isn't ip. 

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Rodney Dunn
> Sent: Wednesday, March 24, 2010 10:50 PM
> To: Dobbins, Roland
> Cc: Cisco-nsp
> Subject: Re: [c-nsp] Sup720 CoPP, limits on CPU performance
> 
> I'm going to bring it back up again. Why we don't do "Ingress Netflow"
> on the control plane interface is beyond me. You could then easily
> export and trend. I can't remember if FNF would catch the non-ip
> traffic
> so that could be trended also.
> 
> Rodney
> 
> 
> 
> On 3/24/10 5:35 AM, Dobbins, Roland wrote:
> >
> > On Mar 24, 2010, at 4:28 PM, Gert Doering wrote:
> >
> >> (So in general, I agree with you, I just want a more fool-proof way
> to
> >> configure CoPP-drop-default in a way that has no surprising side-
> effects)
> >
> > I proposed a self-learning mode for CoPP, based upon identifying 'to-
> me' traffic via the NetFlow cache, many years ago.  Unfortunately, it
> wasn't ever taken up, AFAIK.
> >
> > -
> --
> > 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/
> ___
> 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] IPSec crypto map on MPLS enabled interface?

[David Prall]

LDP and IPSec aren't friendly together on the same interface. A Front-Side
VRF (fVRF) is typically used in a vrf-lite/multi-vrf ce situation without
LDP enabled. You could try tunnel protection instead of a crypto-map. The
order of operations is a key issue here, IPSec has to happen prior to label
imposition. 

If it is only a CE - PE connection then no problems, but since it is the PE
doing the encryption as well. 

I've done this a couple times where the crypto interface was the vrf
interface, and we decrypted/encrypted there and then put the traffic onto a
core labeled interface without encryption.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: Phil Mayers [mailto:p.may...@imperial.ac.uk]
> Sent: Thursday, March 11, 2010 4:48 AM
> To: David Prall
> Cc: 'Peter Rathlev'; 'cisco-nsp'
> Subject: Re: [c-nsp] IPSec crypto map on MPLS enabled interface?
> 
> On 03/10/2010 05:44 PM, David Prall wrote:
> > You could do MPLSoGREoIPSec
> 
> Maybe, if you control both the design and feature set of both ends.
> 
> But still, it seems pretty clear this is a bug or feature limitation to
> me. IP/IPSEC/GRE packets are arriving at/leaving the router. The next
> hop adjacency happens to be MPLS. That should not matter.

___
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] IPSec crypto map on MPLS enabled interface?

[David Prall]

You could do MPLSoGREoIPSec

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Peter Rathlev
> Sent: Wednesday, March 10, 2010 12:07 PM
> To: Phil Mayers
> Cc: cisco-nsp
> Subject: Re: [c-nsp] IPSec crypto map on MPLS enabled interface?
> 
> On Tue, 2010-03-09 at 13:35 +0100, Peter Rathlev wrote:
> > And the encrypted traffic leaves the box tagged too.
> 
> I assumed a little too much here. :-)
> 
> It turns out that the traffic leaves the box unencrypted unless it
> originated on the box itself. So ping inside the tunnel interface works
> fine, but traffic arriving from outside the box only gets GRE
> encapsulated, not IPSec. MPLS always comes on top.
> 
> I ended up having to use a non-MPLS interface as the "outside"
> interface
> to make the box actually encrypt things.
> 
> I thought I could pull this off on a 7200. They're so versatile. :-)
> 
> --
> Peter
> 
> 
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] Limiting DHCP on a Bridge Group

[David Prall]

Garry,
Wondering if you could do the wireless and vlan1 as unnumbered to a
loopback. Then they are two distinct interfaces, on the same subnet. Or
could always split the subnet into two distinct /25's instead of a single
/24. 

David

--
http://dcp.dcptech.com


> -Original Message-
> From: Garry [mailto:g...@gmx.de]
> Sent: Wednesday, February 10, 2010 2:39 PM
> To: David Prall
> Cc: 'c-nsp'
> Subject: Re: [c-nsp] Limiting DHCP on a Bridge Group
> 
> On 10.02.2010 20:30, David Prall wrote:
> > I think the match interface is looking at where the policy is
> assigned. I
> > know the policy isn't supported on the physical interfaces. I have to
> do all
> > my QoS on fa4 inbound.
> >
> > Why not place an acl on the vlan interface for the wired ports. Not
> sure if
> > it would be hit first, or if the bvi would capture it.
> 
> I recon it ends up in the BVI, as adding the access-list to vlan1 ends
> up with no hits, while adding the same to the BVI increases the hit
> counter correctly, and dhcp requests are blocked ... but BVI won't help
> as it would also block the requests on wlan ...

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

Re: [c-nsp] Limiting DHCP on a Bridge Group

[David Prall]

I think the match interface is looking at where the policy is assigned. I
know the policy isn't supported on the physical interfaces. I have to do all
my QoS on fa4 inbound.

Why not place an acl on the vlan interface for the wired ports. Not sure if
it would be hit first, or if the bvi would capture it.

Moved to an 881 at home, so I don't have my 871W anymore.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: Garry [mailto:g...@gmx.de]
> Sent: Wednesday, February 10, 2010 2:06 PM
> To: c-nsp
> Cc: David Prall
> Subject: Re: [c-nsp] Limiting DHCP on a Bridge Group
> 
> On 10.02.2010 19:04, David Prall wrote:
> > Match protocol is nbar, I can never remember which require "ip nbar
> > protocol-discovery" on the interface.
> 
> Tried it (put it in the bvi1 interface), still getting DHCP replies
> though .. recognition is working fine, though ...
> 
>dhcp 21
> 1180 352
> 
> The policy map/class seem to be attached to the BVI correctly, too:
> 
> T#show policy-map int
>  BVI1
> 
>   Service-policy input: NODHCP
> 
> Class-map: NODHCP (match-all)
>   0 packets, 0 bytes
>   5 minute offered rate 0 bps, drop rate 0 bps
>   Match: protocol dhcp
>   Match: input-interface FastEthernet0
>   drop
> [..]
> Class-map: class-default (match-any)
>   931 packets, 57159 bytes
>   5 minute offered rate 1000 bps, drop rate 0 bps
>   Match: any
> 
> Even added another class with input interface of VLAN1, still no
> success
> ... on the show policy-map command, none of the class-maps show any IP
> traffic, except for the default class ...
> 
> After setting up two seperate classes to check for either an interface,
> or the protocol, it looks like the protocol part is working, while the
> interface match seems to fail ... adding both vlan1 and bvi1, I guess
> the class/policy map isn't able to differentiate the incoming interface
> anymore at that stage, as all the traffic is listed under BVI1, though
> the computer used to connect to the router at that point is connected
> to
> Fa0 ...:
> 
> Class-map: test1 (match-any)
>   81 packets, 4860 bytes
>   5 minute offered rate 0 bps, drop rate 0 bps
>   Match: input-interface FastEthernet0
> 0 packets, 0 bytes
> 5 minute rate 0 bps
>   Match: input-interface FastEthernet1
> 0 packets, 0 bytes
> 5 minute rate 0 bps
>   Match: input-interface FastEthernet2
> 0 packets, 0 bytes
> 5 minute rate 0 bps
>   Match: input-interface FastEthernet3
> 0 packets, 0 bytes
> 5 minute rate 0 bps
>   Match: input-interface Vlan1
> 0 packets, 0 bytes
> 5 minute rate 0 bps
>   Match: input-interface BVI1
> 81 packets, 4860 bytes
> 5 minute rate 0 bps
> 
> Any suggestion as to how to get around this? Maybe adding seperate
> vlans
> to each port and binding them to the bridge group?
> >
> > Why not use an access-list denying dhcp
> > deny udp any eq bootpc any eq bootps
> 
> Because I still need the DHCP to go through on the WLAN link?
> 
> Tnx, garry

___
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] Best practice - Core vs Access Router

[David Prall]

Your drops and flushes counts are the same. A flush is a control plane
packet that pushed to CPU even though the input queue was filled. I don't
believe these two numbers should be the same unless all of the input queue
was filled with these packets.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Andy B.
> Sent: Wednesday, February 10, 2010 2:01 PM
> To: David Freedman
> Cc: nsp-cisco
> Subject: Re: [c-nsp] Best practice - Core vs Access Router
> 
> On Wed, Feb 10, 2010 at 7:48 PM, David Freedman
>  wrote:
> > So, are you checking your interfaces for incrementing drop/error
> counters?
> >
> > Are you seeing any of this when there is the problem occuring?
> > (clear counters , sh int summ etc..)
> >
> 
> I am having input drops all the time, no matter how high or low I set
> the incoming hold-queue.
> 
> The OSPF and IBGP interfaces approx. 30 minutes after I cleared the
> counters:
> 
> TenGigabitEthernet8/1 is up, line protocol is up (connected)
>   Input queue: 0/2000/622/622 (size/max/drops/flushes); Total output
> drops: 0
> 
> TenGigabitEthernet9/1 is up, line protocol is up (connected)
>   Input queue: 0/4096/1664/1664 (size/max/drops/flushes); Total output
> drops: 0
> 
> TenGigabitEthernet9/2 is up, line protocol is up (connected)
>   Input queue: 0/4096/1916/1916 (size/max/drops/flushes); Total output
> drops: 0
> 
> 
> These links are not congested! Te9/1 is the busiest with maybe 6.5 out
> of 10 Gig. The other two are below 5 Gig.
> ___
> 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] Best practice - Core vs Access Router

[David Prall]

Andy,
By excluding 0.00 your excluding those that have had 0.00 anywhere in the
time list. Just use sort and look at the top few. Although most likely the
same.

If you have a number of large Ethernet subnets with few systems on them,
then "sh ip arp" will contain a number of incompletes. If it is the entire
subnet filled with incompletes then someone is looking for all of your
systems and is most likely doing a ping sweep, then enabling "mls rate-limit
unicast cef glean" will be worthwhile. These are both Adj Manager and ARP
Input I believe. 

The other one is if you've run out of TCAM space, because your over the
limits with the number of routes you have. Don't know if you're running an
XL or not. 

CPU doesn't look out of order currently. Need to capture it ongoing to see
what process is pushing it to 24%, and even then it should still be
forwarding traffic. 

You might need to look at the DFC's as well, to see if one is having issues:
Remote command module X sh proc cpu sort

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Andy B.
> Sent: Wednesday, February 10, 2010 1:44 PM
> To: Phil Mayers
> Cc: nsp-cisco
> Subject: Re: [c-nsp] Best practice - Core vs Access Router
> 
> I am currently facing this strange behaviour once again. Nothing
> suspicious in terms of CPU:
> 
> #sh proc cpu sort | ex 0.00
> CPU utilization for five seconds: 7%/3%; one minute: 24%; five minutes:
> 23%
>  PID Runtime(ms)   Invoked  uSecs   5Sec   1Min   5Min TTY Process
>  123   823552748 891845755923  1.35%  1.32%  1.24%   0 IP Input
>  14242990360 548209142 78  0.63%  0.15%  0.06%   0 IP SNMP
>  17681597832 313530395260  0.63%  0.20%  0.12%   0 SNMP
> ENGINE
>  28695557652  68837887   1388  0.31%  4.77%  4.27%   0 BGP
> Router
>   468724  6895   1265  0.31%  0.33%  0.24%   2 SSH
> Process
>  16998755140   5844411  16897  0.31%  0.31%  0.31%   0 Adj
> Manager
>992740444 222352412417  0.23%  0.40%  0.41%   0 ARP
> Input
>  32020411156 140247526145  0.15%  1.64%  1.57%   0 BGP I/O
>  18064470940  51288798   1257  0.15%  0.58%  0.44%   0 CEF
> process
>  16727190044 390437731 69  0.15%  0.12%  0.10%   0 IPv6
> Input
> 
> #remote command switch sh proc cpu sort | ex 0.00
> CPU utilization for five seconds: 10%/0%; one minute: 14%; five
> minutes: 20%
>  PID Runtime(ms)   Invoked  uSecs   5Sec   1Min   5Min TTY Process
>  102   577414400  14603714  39539  5.19%  2.76%  2.58%   0 Vlan
> Statistics
>   42  11702922242664309865  0  3.91%  3.83%  3.87%   0 slcp
> process
>  25779620728  46604862   1708  0.23%  1.31%  0.92%   0 CEF
> process
>  15224224440  35123075689  0.15%  0.08%  0.07%   0 CEF LC
> Stats
>   3329231032 224654615130  0.15%  0.08%  0.07%   0 SCP
> Download Lis
>  13139865856   1338254  29789  0.07%  0.08%  0.11%   0 TCAM
> Manager pro
>  12737865260 135955648278  0.07%  0.07%  0.07%   0 Spanning
> Tree
>  18712366092   3103775   3984  0.07%  0.04%  0.05%   0 v6fib
> stat colle
>  23911888108   8600338   1382  0.07%  0.04%  0.03%   0 LTL MGR
> cc
> 
> Packet loss to the router (nothing behind it) is around 25%.
> And still loosing random BGP and OSPF sessions. SNMP graphs are not
> being generated either.
> 
> Currently feeling quite desperate, because I have no clue where to look
> next...
> 
> Andy
> 
> On Tue, Feb 9, 2010 at 6:56 PM, Phil Mayers 
> wrote:
> > On 09/02/10 17:39, Church, Charles wrote:
> >>
> >> I was going by the 'show proc cpu hist' he gave for both the SP and
> RP.
> >> Both looked pretty bad across the board.
> >
> > His graphs don't look that dis-similar to mine, and we have no such
> > problems. The peak/avg CPU don't look so unreasonable to me given the
> load
> > and setup he's described.
> >
> > To summarise in this thread, it has been suggested:
> >
> >  1. Netflow is the problem - to which the OP said he's already tried
> > disabling it
> >
> >  2. CPU punts, specifically gleans, are the problem - in which case
> CoPP or
> > MLS rate limiters can be tried, but the OP really IMHO needs to
> confirm this
> > with a span of the CPU
> >
> >  3. The 6500 is just no good buy a juniper or asr1k (!) which I
> strongly
> > dispute. It may be awkward and have odd limits, but it OUGHT TO
> HANDLE the
> > load we've been told about; therefore something is wrong
> >
> > ...and lots more besides. I'm exhausted from following the thread,
> but my
> > advice to the OP is to determine what is hitting the CPU *during an
> outage*,
> > then proceed from there.
> >
> > I'm going to stop reading now.
> > ___
> > cisco-nsp mailing list  cisco-...@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipe

Re: [c-nsp] Limiting DHCP on a Bridge Group

[David Prall]

Match protocol is nbar, I can never remember which require "ip nbar
protocol-discovery" on the interface. 

Why not use an access-list denying dhcp
deny udp any eq bootpc any eq bootps

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Garry
> Sent: Wednesday, February 10, 2010 12:50 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Limiting DHCP on a Bridge Group
> 
> Hi,
> 
> I've got a setup that could use some tweaking ...
> 
> CPE is a 876W, with the 4 wired switch ports (read: VLAN1) and the WLAN
> being in a bridge group, LAN ip on the BVI1 interface.
> 
> LAN ports are only for designated boxes, while there are select users
> that may use the WLAN link to connect. For those, the router is running
> as a DHCP server, too.
> Anyway, I would like to limit the DHCP answers to just the WLAN link. I
> know I could go ahead and just split up the bridge group, with routing
> between the networks, but due to some other requirements, WLAN and
> wired
> lan needs to be in the same broadcast domain (at least unless the
> customer goes through some major reconfiguration).
> 
> I've received some suggestion as to using a policy map with class maps
> matching on proto dhcp and the incoming interfaces, dropping the
> traffic
> when it matched, while still forwarding the class default ... anyway, I
> tried setting that up, but still got DHCP on the FE ports ...
> 
> Any other suggestions? Or some hint on what I missed? Here's an excerpt
> from the config ...
> 
> ---
> class-map match-all NODHCP
>  match protocol dhcp
>  match input-interface FastEthernet0
> class-map match-all NODHCP1
>  match protocol dhcp
>  match input-interface FastEthernet1
> class-map match-all NODHCP2
>  match protocol dhcp
>  match input-interface FastEthernet2
> class-map match-all NODHCP3
>  match protocol dhcp
>  match input-interface FastEthernet3
> 
> policy-map NODHCP
>  class NODHCP
>drop
>  class NODHCP1
>drop
>  class NODHCP2
>drop
>  class NODHCP3
>drop
>  class class-default
> !
> interface BVI1
>  ip address 10.1.1.1 255.255.255.0
>  service-policy input NODHCP
> 
> Help appreciated, -garry
> ___
> 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] IOS Server Load Balancing on C3560-E switches ??

[David Prall]

Create a loopback interface on the servers with the VIP. Point a static
route for the VIP at the servers physical address, make the VIP on the same
subnet as the physicals. Let CEF take care of it. You lose a lot of dynamic
capabilities that are available via monitoring. You'll need Enhanced Object
Tracking to monitor that the server is alive.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: Matthew Huff [mailto:mh...@ox.com]
> Sent: Wednesday, February 10, 2010 11:20 AM
> To: 'David Prall'; 'cisco-nsp'
> Subject: RE: [c-nsp] IOS Server Load Balancing on C3560-E switches ??
> 
> Yes, it looks like IOS SLB is only available on the 6500/7600. Too bad.
> This is for straight revere-proxy web caches for Oracle WebCache so it
> uses http/https. We may have to purchase an ACE appliance. Anyone have
> any suggestions for a turnkey (not linux server based, etc) appliance
> that does http/https load balancing? Something as simple and cheap as
> possible.
> 
> 
> 
> 
> Matthew Huff   | One Manhattanville Rd
> OTA Management LLC | Purchase, NY 10577
> http://www.ox.com  | Phone: 914-460-4039
> aim: matthewbhuff  | Fax:   914-460-4139
> 
> 
> 
> > -Original Message-
> > From: David Prall [mailto:d...@dcptech.com]
> > Sent: Wednesday, February 10, 2010 10:36 AM
> > To: Matthew Huff; 'cisco-nsp'
> > Subject: RE: [c-nsp] IOS Server Load Balancing on C3560-E switches ??
> >
> > IOS SLB is on the 6500 and 7200. Not on the 3560-E / 3750-E.
> >
> > Could always use Anycast via a loopback on the servers and let CEF
> ECMP take
> > care of it. But this is typically only done for UDP applications. Not
> sure
> > if EOT is on the 3560-E for Static Routes, or you could use BGP from
> the
> > servers.
> >
> > David
> >
> > --
> > http://dcp.dcptech.com
> >
> >
> > > -Original Message-
> > > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> > > boun...@puck.nether.net] On Behalf Of Matthew Huff
> > > Sent: Wednesday, February 10, 2010 10:14 AM
> > > To: 'cisco-nsp (cisco-nsp@puck.nether.net)'
> > > Subject: [c-nsp] IOS Server Load Balancing on C3560-E switches ??
> > >
> > > With IP services on a 3560-E, is it possible to do server load
> > > balancing? If so, any caveat's that I should be aware of? We just
> need
> > > to front end two web servers (oracle identity management) for http
> and
> > > https (no ssl offloading needed). I hate to have to buy an ACE just
> for
> > > these two servers
> > >
> > > 
> > > Matthew Huff   | One Manhattanville Rd
> > > OTA Management LLC | Purchase, NY 10577
> > > http://www.ox.com  | Phone: 914-460-4039
> > > aim: matthewbhuff  | Fax:   914-460-4139
> > >
> >


___
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] IOS Server Load Balancing on C3560-E switches ??

[David Prall]

IOS SLB is on the 6500 and 7200. Not on the 3560-E / 3750-E.

Could always use Anycast via a loopback on the servers and let CEF ECMP take
care of it. But this is typically only done for UDP applications. Not sure
if EOT is on the 3560-E for Static Routes, or you could use BGP from the
servers.

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Matthew Huff
> Sent: Wednesday, February 10, 2010 10:14 AM
> To: 'cisco-nsp (cisco-nsp@puck.nether.net)'
> Subject: [c-nsp] IOS Server Load Balancing on C3560-E switches ??
> 
> With IP services on a 3560-E, is it possible to do server load
> balancing? If so, any caveat's that I should be aware of? We just need
> to front end two web servers (oracle identity management) for http and
> https (no ssl offloading needed). I hate to have to buy an ACE just for
> these two servers
> 
> 
> Matthew Huff   | One Manhattanville Rd
> OTA Management LLC | Purchase, NY 10577
> http://www.ox.com  | Phone: 914-460-4039
> aim: matthewbhuff  | Fax:   914-460-4139
> 


___
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] IPV6 again

[David Prall]

So XP doesn't support IPv6 DHCP, nor do they support IPv6 DNS. Not sure
about the macintosh. 

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Michael Robson
> Sent: Friday, January 29, 2010 11:33 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] IPV6 again
> 
> OK so looking at/listening to various recommendations, when allocating
> IPV6 addresses, stateless auto-configuration with DHCPv6 used to dish
> out the DNS servers and domain looks the most appealing. Since the IOS
> version we are using on our 6500s doesn't support IPV6 DHCP relaying
> (12.2(18)SXF13) I tried to set up a test using the 6500 itself to serve
> the DNS and domain information but I cannot get it to work. When I use
> the following configuration the clients are configured with appropriate
> v6 IPs and can get out into the IPV6 Internet, but no DNS or domain
> information is received. Turning on "debug ipv6 DHCP" yields no entries
> in the log at all for either an iMac or an XP laptop: am I missing some
> configuration?
> 
> 
> interface Vlan798
>  ipv6 address X/64
>  ipv6 enable
>  ipv6 nd other-config-flag
>  ipv6 dhcp server test
> end
> !
> !
> ipv6 dhcp pool test
>  dns-server Y
>  domain-name Z
> !
> 
> 
> 
> Thanks,
> 
> Michael
> --
> ___
> 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] Busting up VLANs and bridging

[David Prall]

Create a dot1q trunk to the server and configure the server the same. Add an
additional interface to the server. Remove the second vlan altogether and
add the subnet as a secondary on the first vlan.

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Security Team
> Sent: Thursday, January 28, 2010 7:45 PM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Busting up VLANs and bridging
> 
> What is the "right" way to combine IP layer 3 traffic so that it can go
> to
> multiple VLANs? I'm working with a Catalyst 65xx setup.
> 
> For example, I am starting from a working setup that looks something
> like
> this:
> 
> interface GigabitEthernet4/1
>  speed auto
>  switchport
>  switchport access vlan 247
> !
> interface GigabitEthernet4/2
>  speed auto
>  switchport
>  switchport access vlan 248
> !
> interface Vlan247
>  ip address 192.168.247.1 255.255.255.0
> !
> interface Vlan248
>  ip address 192.168.248.1 255.255.255.0
> 
> Now, if I wanted to actually have a server 192.168.247.36 in Vlan247,
> but I
> want to make that server become a bridge so that I can give it other IP
> addresses in other blocks how would I do that?
> 
> So let's say the *.247.36 IP of the server is working, but I want to
> change
> my setup so that the server also has 192.168.248.64/29 on it (i.e. I am
> busting up the .248. Netblock from a /24 to smaller blocks that will be
> on
> different servers).
> 
> How would I go about doing this?
> 
> Thanks,
> CJ
> ___
> 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/