Re: [c-nsp] 7600 QOS Per Sub-interface
You will need the ES/ES+ enhanced services cards to do what you want. Or SIP/SPA type cards, but at this point ES is probably a cheaper option. There are not really any good options or ways to fudge it with a 7600 with the LAN type cards. Unless you need the LAN cards specifically for the port density rather than the N x 1G bandwidth. In which case, an external loopback cable from a single WAN port (of whatever flavour) into the LAN card, running the QoS on the WAN port on lots of sub-interfaces *can* get you there. It's a nasty hack, but if you really can't afford the number of physical WAN ports you need... Yes, I know you said *good* options :) Regards, Tim. ___ cisco-nsp 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] 6k Netflow To Be or Not To Be...
On Nov 16, 2011, at 4:47 PM, Nick Hilliard wrote: Depends on hardware configuration - i.e. whether or not you're using DFCs or not. And on five-tuple diversity. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] BGP community
Hi all , is i have the community set as 100 200 300
in the show ip bgp {prefix} output it will show in an ascending order , the
question can i reverse that ?
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] BGP community
On 16/11/2011 11:41, Mohammad Khalil wrote:
in the show ip bgp {prefix} output it will show in an ascending order ,
the question can i reverse that ?
No. The community order is irrelevant to BGP.
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/
Re: [c-nsp] BGP community
Thanks
Date: Wed, 16 Nov 2011 11:56:20 +
From: n...@foobar.org
To: eng_m...@hotmail.com
CC: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] BGP community
On 16/11/2011 11:41, Mohammad Khalil wrote:
in the show ip bgp {prefix} output it will show in an ascending order ,
the question can i reverse that ?
No. The community order is irrelevant to BGP.
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/
Re: [c-nsp] Third Party Xenpaks
On 7 Nov 2011, at 17:00, cisco-nsp-requ...@puck.nether.net wrote: That sounds like an IOS bug. What does sh idprom int Tex/y | inc endor say for one of the non-Cisco parts, compared to a Cisco part? Mystery solved: without going into the full long story, 75oC ambient temperature in a datacentre causing a config register to become corrupt ended in an ancient backup IOS being booted into, one without DOM support. Prior to the reboot, the only third-party Xenpaks were SR and so had no DOM support anyway (and I won't even go into the confusion caused by the output of idprom claiming our real Cisco SR xenpaks are of the + variety, i.e. DOM supporting). ... We've never had problems with such transceivers and DOM, including with SFP+ in a X2-SFP+ converter in a 6716. Well that in itself is useful to know - 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/
Re: [c-nsp] QoS configuration conflict for flowmask on SVI interface behind FWSM
On Wed, Nov 16, 2011 at 1:49 AM, Phil Mayers p.may...@imperial.ac.uk wrote: On 11/16/2011 05:08 AM, Joseph Jackson wrote: Hey List, I'm wanting to apply a policy-map to rate limit a port that is a member of a vlan that is configured as a firewalled vlan. When I apply the service-policy input to the port directly connected to the server I get this message in the logs: %FM_EARL7-2-SWITCH_PORT_QOS_FLOWMASK_CONFLICT: QoS configuration on switch port FastEthernet1/5 conflicts for flowmask with feature configuration on SVI interface Vlan912 Can you show the class policy map you were trying to use, and the config of both interfaces (before you started)? Here ya go. class-map match-all limit-netcool-cdr match access-group 191 ! ! policy-map limit-netcool-cdr class limit-netcool-cdr police flow mask dest-only 200 62500 conform-action transmit exceed-action drop ! Directly connected interface - interface FastEthernet1/5 switchport switchport access vlan 101 no ip address speed 100 duplex full spanning-tree portfast end SVI - interface Vlan912 description ***OUTSIDE*** ip address 172.16.213.11 255.255.255.248 standby ip 172.16.213.13 standby timers 2 5 standby priority 200 standby preempt Thanks Phil! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] DSCP
DSCP 41 means CS4 or AF41 ? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] IP SLA eigrp
Hi, Is it possible to make down ip eigrp routing protocol when ip sla icmp jitter detect, let say, 200ms or 10% packet loss to other host in network. Grzegorz Zapalski ___ cisco-nsp 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] IP SLA eigrp
On 16/11/2011 15:22, Grzegorz Zapalski wrote: Is it possible to make down ip eigrp routing protocol when ip sla icmp jitter detect, let say, 200ms or 10% packet loss to other host in network. Would Performance Routing do what you're looking for? http://www.cisco.com/en/US/products/ps8787/products_ios_protocol_option_home.html 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/
Re: [c-nsp] DSCP
On Wed, Nov 16, 2011 at 05:44:48PM +0200, Mohammad Khalil wrote: DSCP 41 means CS4 or AF41 ? DSCP 41 isn't really used and doesn't make sense (last bit is tyically 0). AF41 would be DSCP 34. CS4 would be DSCP 32. RFC 4594 has some good guidelines and is a good starting point. Here's a table: 0 cs0 8 cs1 10 af11 12 af12 14 af13 16 cs2 18 af21 20 af22 22 af23 24 cs3 26 af31 28 af32 30 af33 32 cs4 34 af41 36 af42 38 af43 40 cs5 46 ef 48 cs6 56 cs7 Best regards, Rich ___ cisco-nsp 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] DSCP
On Wed, 2011-11-16 at 17:44 +0200, Mohammad Khalil wrote: DSCP 41 means CS4 or AF41 ? Neither as far as I know. CS4 is DSCP 32 and AF41 is DSCP 34. It does not seem like DSCP 41 has any specific class definition, at least not according to RFC 4594. -- 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/
Re: [c-nsp] DSCP
On Wed, Nov 16, 2011 at 10:44 AM, Mohammad Khalil eng_m...@hotmail.com wrote: DSCP 41 means CS4 or AF41 ? A handy guide: http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0/qos/configuration/guide/qos_6dscp_val.html -cjp ___ cisco-nsp 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] DSCP
Thanks for the replies That's what confused me because i review the table and there is nothing called DSCP 41 !! or DSCP 31 ! Date: Wed, 16 Nov 2011 10:28:25 -0600 From: r...@ferlie.org To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] DSCP On Wed, Nov 16, 2011 at 05:44:48PM +0200, Mohammad Khalil wrote: DSCP 41 means CS4 or AF41 ? DSCP 41 isn't really used and doesn't make sense (last bit is tyically 0). AF41 would be DSCP 34. CS4 would be DSCP 32. RFC 4594 has some good guidelines and is a good starting point. Here's a table: 0 cs0 8 cs1 10 af11 12 af12 14 af13 16 cs2 18 af21 20 af22 22 af23 24 cs3 26 af31 28 af32 30 af33 32 cs4 34 af41 36 af42 38 af43 40 cs5 46 ef 48 cs6 56 cs7 Best regards, Rich ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] IOS firewall inspection blocking TACACS
Hi, I have a fairly simple branch network with a 2911 as the edge router and some 3750s behind it. The 2911 terminates an IPSec tunnel over to our DC and all the 3750s use TACACS with AAA servers in the DC, so the TACACS traffic goes over the IPSec tunnel. I have recently decided to use IOS firewall rather than slightly un-eloquent reflexive ACLs on the router. Everything works fine when I apply the inspection rules; users can browse the Internet, I can ping to the DC through IPSec and I can access Intranet servers through IPSec etc. One thing that does not work however is TACACS, I can no longer authenticate. The connections now time out Does anyone know why this might be? Based on research the inspection is carried out before encryption, but I cannot see why the TACACS packets in particular would be blocked. I have tried inspecting tacacs also but no joy. Also tried adding inbound inspection on the inside interface of the router as well. Here is the relevant configuration: ip inspect name SES tcp router-traffic ip inspect name SES udp router-traffic ip inspect name SES icmp router-traffic ip inspect name SES h323 ip access-list extended ACL-PO17-IN permit esp any any permit udp any any eq isakmp deny ip any any interface Port-channel1.7 description Outside VLAN bandwidth 10 encapsulation dot1Q 7 ip address 213.x.x.x 255.255.255.224 no ip redirects no ip unreachables no ip proxy-arp ip inspect SES out ip access-group ACL-PO17-IN in ip nat outside no ip virtual-reassembly standby 101 ip 213.x.x.x standby 101 priority 110 standby 101 preempt standby 101 name ISP standby 101 track 2 decrement 30 crypto map IPSEC_VPN ___ cisco-nsp 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] 6k Netflow To Be or Not To Be...
As I stated in the original post. This is based on my experience with standard web traffic. Mack -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Hilliard Sent: Wednesday, November 16, 2011 2:48 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 6k Netflow To Be or Not To Be... On 15/11/2011 15:05, Mack McBride wrote: Below 5G you are unlikely to overflow (given a certain amount of tuning). Depends on hardware configuration - i.e. whether or not you're using DFCs or not. I've seen persistent overflows at 150kpps using L2 netflow, on the basis of fast flow expiry. 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] OSPF issue
Hi Guys - Just following up on this issue...Carrier is stating that they are not filtering multicast(support case is still open, but we appear to be getting nowhere) If I ping 224.0.0.5 from R2, I do not get a response from R1 via the new link - Also, debugging icmp on r1, I only see requests from R2 via the existing(working) link, so the multicast pings are not reaching R1 via the new link. R1(7206 w/ G1) connects via trunk to 3750(As portchan), and the carrier hand-off is via trunk port on the same 3750 - The switch is not doing any L3, has no filtering of multicast enabled...Am I seeing a potential ios bug? Any suggestions are greatly appreciated! Date: Sun, 13 Nov 2011 09:55:24 +0100 Subject: Re: [c-nsp] OSPF issue From: kim...@gmail.com To: johnellio...@hotmail.com CC: j...@west.net; cisco-nsp@puck.nether.net It looks like it's actually multicast packets that are getting filtered somehow. MPLS (LDP) is also making use of it for discovering the neighbors (224.0.0.2). Untill you get the multicast issue sorted with your carrier, you could do a targeted (unicast) discovery for LDP. that should work. On Sun, Nov 13, 2011 at 2:51 AM, John Elliot johnellio...@hotmail.com wrote: Cheers guys - It would appear that there is some filtering of ospf on this new link...I've changed both ends ints to non-broadcast, and added nei statements to ospf, and we now have adj that's been up for ~30min. Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2481 FULL/DR 00:01:37xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.2481 FULL/DR 00:00:31xxx.xxx.66.2 FastEthernet3/0 Ill get onto carrier tomorrow regarding the multicast filtering.Side note - Is there any potential issues with running mpls over this link(As I dont see ldp neig on R1 for R2):#sh mpls ldp neighbor port-channel 1.87(I do see ldp nei on R2 though(via both portchan1.86 + portchan1.87))Thanks again for your assistance.much appreciated! Date: Sat, 12 Nov 2011 15:49:57 -0800 From: j...@west.net To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPF issue On 11/12/11 3:26 PM, John Elliot wrote: Ok - enabling point-to-point on each of the new ints on R1+R2, and it now doesnt form adj. R1 no longer sees R2 in neighbors via new Int: Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2481 FULL/DR 00:00:35xxx.xxx.66.2 FastEthernet3/0 R2 is stuck in init: Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.2380 INIT/ -00:00:36xxx.xxx.66.61 Port-channel1.87 xxx.xxx.76.2381 FULL/BDR00:00:30xxx.xxx.66.1 Port-channel1.86 Based on your previous post re multicast pings, it may be that your provider isn't passing multicast. If this is the case you can either get them to fix this (best) or statically assign neighbors in router config mode (sort of an ugly hack). The results of show ip ospf interface [interface name] on both sides after configuring point-to-point on the interfaces would be useful information. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp 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] OSPF issue
On 11/16/11 3:28 PM, John Elliot wrote: Hi Guys - Just following up on this issue...Carrier is stating that they are not filtering multicast(support case is still open, but we appear to be getting nowhere) If I ping 224.0.0.5 from R2, I do not get a response from R1 via the new link - Also, debugging icmp on r1, I only see requests from R2 via the existing(working) link, so the multicast pings are not reaching R1 via the new link. If you ping 224.0.0.5 from a router connected to R1 on a different link, do you get a response? (I suspect your carrier is indeed filtering multicast.) R1(7206 w/ G1) connects via trunk to 3750(As portchan), and the carrier hand-off is via trunk port on the same 3750 - The switch is not doing any L3, has no filtering of multicast enabled...Am I seeing a potential ios bug? Verify that R1 is indeed communicating on 224.0.0.5 on the interface facing the carrier, then beat on them until they fix it. If it isn't and should be (no passive-interface or something misconfigured), then maybe an IOS bug. I suspect the carrier. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp 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] OSPF issue
On 11/16/11 3:28 PM, John Elliot wrote: If I ping 224.0.0.5 from R2, I do not get a response from R1 via the new link - Also, debugging icmp on r1, I only see requests from R2 via the existing(working) link, so the multicast pings are not reaching R1 via the new link. If you ping 224.0.0.5 from a router connected to R1 on a different link, do you get a response? (I suspect your carrier is indeed filtering multicast.) (Hopefully the formatting doesnt get killed by hotmail.) Yes - R1 has 3 active ospf+mpls connections (one to R2, and two to R3) R3 has 2 links to R1, both of which work without issue, and respond to 224.0.0.5 when pinging from R3: From R3 #ping 224.0.0.5 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 224.0.0.5, timeout is 2 seconds: Reply to request 0 from xxx.xxx.66.237, 8 ms Reply to request 0 from xxx.xxx.66.173, 8 ms (Note, Ive removed other replies..R3 has other ospf neighbours also) (i.e. no need for non-broadcast or neighbor statements to form adjacencies) R1(7206 w/ G1) connects via trunk to 3750(As portchan), and the carrier hand-off is via trunk port on the same 3750 - The switch is not doing any L3, has no filtering of multicast enabled...Am I seeing a potential ios bug? Verify that R1 is indeed communicating on 224.0.0.5 on the interface facing the carrier, then beat on them until they fix it. If it isn't and should be (no passive-interface or something misconfigured), then maybe an IOS bug. sh ip ospf 100 int is stating that portchan1.87 is active #sh ip ospf 100 interface Port-channel1.87 is up, line protocol is up (It has an active adj via this link atm as I have it configured with non-broadcast and neighbour statement in ospf 100) Unless there is some other test I can use to confirm portchan1.87 is indeed communicating on 224.0.0.5? Thanks again for your assistance. I suspect the carrier. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] handling customer interfaces for single IP address
I wanted to find out how some of you are handling customer interfaces, specifically when giving a customer one IP address. How do you make sure the customer is only getting bandwidth he/she is paying for? Currently, we assign customers /29 subnet to their 802.1Q sub interface and apply some policies to the sub interface. For customers wanting a single IP or broadband package that included only a single IP we have a 802.1Q sub interface with a /24 and we just assign the static IPs to the customer as they need. With this model you have to throw more bandwidth at the link in order to satisfy all customers wanting for example 20 down / 5 up Using ATM DSL this was a walk in the park but just trying to make sure we hit the nail on the head since it's all Ethernet and L2 ports for customers. I believe if we simply did a /30 for each customer on a 802.1Q interface that would solve our issue but we would waste IP addresses. Also if we did this we could route a /29 or any subnet size to their interface at that point should they need. What are your experiences and do you have any other suggestions? We do all routing on our side and hand off a L2 port. Thanks in advance, rootnet ___ cisco-nsp 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] OSPF issue
...(bug) while possible; I still think it is your *new* provider doing something funky to multicast-macs; not multicast-ip. ./Randy --- On Wed, 11/16/11, John Elliot johnellio...@hotmail.com wrote: From: John Elliot johnellio...@hotmail.com Subject: Re: [c-nsp] OSPF issue To: kim...@gmail.com Cc: cisco-nsp cisco-nsp@puck.nether.net Date: Wednesday, November 16, 2011, 3:28 PM Hi Guys - Just following up on this issue...Carrier is stating that they are not filtering multicast(support case is still open, but we appear to be getting nowhere) If I ping 224.0.0.5 from R2, I do not get a response from R1 via the new link - Also, debugging icmp on r1, I only see requests from R2 via the existing(working) link, so the multicast pings are not reaching R1 via the new link. R1(7206 w/ G1) connects via trunk to 3750(As portchan), and the carrier hand-off is via trunk port on the same 3750 - The switch is not doing any L3, has no filtering of multicast enabled...Am I seeing a potential ios bug? Any suggestions are greatly appreciated! Date: Sun, 13 Nov 2011 09:55:24 +0100 Subject: Re: [c-nsp] OSPF issue From: kim...@gmail.com To: johnellio...@hotmail.com CC: j...@west.net; cisco-nsp@puck.nether.net It looks like it's actually multicast packets that are getting filtered somehow. MPLS (LDP) is also making use of it for discovering the neighbors (224.0.0.2). Untill you get the multicast issue sorted with your carrier, you could do a targeted (unicast) discovery for LDP. that should work. On Sun, Nov 13, 2011 at 2:51 AM, John Elliot johnellio...@hotmail.com wrote: Cheers guys - It would appear that there is some filtering of ospf on this new link...I've changed both ends ints to non-broadcast, and added nei statements to ospf, and we now have adj that's been up for ~30min. Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:01:37 xxx.xxx.66.62 Port-channel1.87xxx.xxx.76.248 1 FULL/DR 00:00:31 xxx.xxx.66.2 FastEthernet3/0 Ill get onto carrier tomorrow regarding the multicast filtering.Side note - Is there any potential issues with running mpls over this link(As I dont see ldp neig on R1 for R2):#sh mpls ldp neighbor port-channel 1.87(I do see ldp nei on R2 though(via both portchan1.86 + portchan1.87))Thanks again for your assistance.much appreciated! Date: Sat, 12 Nov 2011 15:49:57 -0800 From: j...@west.net To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPF issue On 11/12/11 3:26 PM, John Elliot wrote: Ok - enabling point-to-point on each of the new ints on R1+R2, and it now doesnt form adj. R1 no longer sees R2 in neighbors via new Int: Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.248 1 FULL/DR 00:00:35 xxx.xxx.66.2 FastEthernet3/0 R2 is stuck in init: Neighbor ID Pri State Dead Time Address Interfacexxx.xxx.76.238 0 INIT/ - 00:00:36 xxx.xxx.66.61 Port-channel1.87 xxx.xxx.76.238 1 FULL/BDR 00:00:30 xxx.xxx.66.1 Port-channel1.86 Based on your previous post re multicast pings, it may be that your provider isn't passing multicast. If this is the case you can either get them to fix this (best) or statically assign neighbors in router config mode (sort of an ugly hack). The results of show ip ospf interface [interface name] on both sides after configuring point-to-point on the interfaces would be useful information. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Last call for participation in the Arbor 2011 WISR opsec survey.
[Apologies if you've already seen this message in other forums.] We'd be grateful if folks who've yet to do so would take a few minutes to participate in the 2011 WISR opsec survey - responses will be tabulated on Sunday, 20Nov11, and input from the operational community is greatly appreciated! This link redirects to the http/s-enabled survey tool: http://www.arbornetworks.com/survey/ISR2011 Thanks much! --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
