Re: [c-nsp] Inter-area Summarization problem on Nexus 9508
On Thu, Nov 16, 2017 at 02:24:17PM +0100, Brian Turnbow wrote: > Hi, > > > Dears, > > > > Anyone know what is wrong with the below range ? > > Yep, host bits are set > You need to put in the network X.X.X.80 is a valid network for a /28. > > router ospf 386 > > vrf AAA > > area 0.0.0.1 stub no-summary > > > > NX9KB9002(config-router-vrf)# area 1 range 10.203.165.80/28 > > Invalid range, host bits are set CSCve91311, which has been fixed. The parser truncates the prefix string to 15 characters, which is the longest possible IP address (but not the longest possible IP address plus mask). "10.203.165.80/28" is 16 characters. When it gets truncated to 15 characters, it becomes "10.203.165.80/2". Which does have host bits set and is invalid. -- Brett ___ cisco-nsp 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 question / interconnecting ABRs
On Wed, Nov 23, 2011 at 03:50:39AM +, Jeff Bacon wrote: On 11/21/2011 06:59 PM, Jeff Bacon wrote: Is there some better way to handle this? Or do I just do the virtual-links/dual-connects and accept the hack? Do you actually need areas? How many routes are involved? There's probably 500 routes or so; it's hard to be sure entirely because many of them hide behind summarization/range-statements. It COULD all be run as a single area 0 but given that the entire mesh spans everything from a 10G NYC metro ring to a trans-Pac internet VPN mesh, the result would seem fairly ugly. Other than the problem of how to avoid split-area syndrome when there are 1 ABRs joining an area to area 0 without creating separate links between the devices for area X and 0, it works fairly well as-is. I see no reason not to use the virtual links. (And I've done exactly what you describe, for reasons similar to the ones you have, on a larger scale than what you describe.) The only reason you seem to have for not wanting to do that is lot of books make an unsupported assertion that it's a bad idea ... I don't consider that a good reason. If someone can't explain why it's a bad idea, then I wouldn't take their word that it is. It's the best way to solve the problem you described in your original post: redundant ABRs where the best path between them is in the non-zero area they are bordering. Certainly modern routers wouldn't have a problem doing your whole network (as you describe it) in a single area. There is still some benefit in having reasonable area boundaries due to providing some isolation from LSDB problems propogating network wide. In practice, though, the code is solid enough these days that that benefit is pretty small. (Back in the day, I saw a case of a Bay (or Wellfleet or Notel) router configured with router ID 0.0.0.0. Bay/Nortel/Wellfleet code of the time would create the LSA and propogate it, but any routers that had it couldn't properly calculate a routing table. It was fortunate that that LSA didn't spread beyond the area with the router with router-id 0.0.0.0.) (Well, that and, why can't you tell an ABR to stop advertising the range statement when you've lost all other neighbors in that area? but that's a fringe case.) Yeah. You'd want to make sure there's enough redundancy between ABRs in an area to make a split in the area exceedingly unlikely. -- Brett ___ cisco-nsp 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] WARNING: Netflow Data Export Hardware assisted NAT not supported on 76xx/65xx on the same interface
On Sun, Aug 28, 2011 at 08:04:00PM +0200, Gert Doering wrote: On Sun, Aug 28, 2011 at 11:12:44AM -0500, Tony Varriale wrote: Then hire someone that knows what they are doing. Am I the only one to find that sort of remark a bit nasty? While not sporting any nice certificates, I consider myself to be somewhat experienced with Cisco platforms, and Cisco architecture - and if a prospective customer would have asked me will NAT and netflow work together? I would have checked the documentation, would not have found anything about that conflict either, and would have said no problem there. But now much money would you commit to that position? You've been doing this a while ... presumably you're well aware that not everything always works togethor on platforms that do most of their switching in ASICs. (I do a lot of GRE tunnelling and have for a long time. The first thing I thought when I learned that Sup720s would support GRE tunnels in hardware was I wonder what the limitations are. There are many, and only some of them are documented.) The comment you reference above was in respose to this: We don't have the luxury of long, involved RFP with detailed descriptions or time to work with a TME to discuss every detail of every configuration we use. We expect if a vendor advertise features, that they should work, except when they are documented (like caveats). While you might not personally know off hand if NAT and netflow work togethor, if you had a requirement for that functionality and were considering the 65xx/76xx for it, would you read the documentation, not find anything saying they won't work togethor, and then buy it? Or would you do a detailed RFP or talk to a TME about that functionality before buying it? Or if you didn't have the time or talent to do one of those things yourself, would you hire someone who did? The comment was rather blunt, but in terms of content, it was dead on. Buyers need to do their due diligence. Some are large and/or sophisticated enough to do it with in house employees, others need to hire outside talent. But if you do neither, you run the risk of being disappointed. (In response to the comment about I can't hire anyone who knows about limitations on future unreleased products. Of course you can't. But you can hire someone who knows how to do the necessary due diligence before purchasing a product.) -- Brett ___ cisco-nsp 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] FW: Overruns
On Thu, Jan 27, 2011 at 08:53:18AM +, Nick Hilliard wrote: On 27/01/2011 07:57, Mohammad Khalil wrote: its on Cisco 7606-S , the connection is port channel with 5 physical interfaces Oh, you Really Don't Want To Do That(tm). For etherchannels on EARL7 architecture, if you want your load balancing to be roughly equal, you need to ensure that your port channels are configured with either 2, 4 or 8 physical interfaces. The reason for this is due to limitations on the EARL7 chip on the sup720 - specifically, there are only 3 bits of bucket space, which means 1) no more than 8 active links and 2) severe limitations in the load balancing algorithm. If you have 5 physical interfaces, the load balancing will work out (in the optimal case) as 2:2:2:1:1. This means that you effectively have (2+2+2+1+1)/(2+2+2+2+2) = 4/5 of the total etherchannel capacity available for traffic. I.e. you're actually not gaining anything by using more than 4 physical links. Of course he is. With five links, assuming the traffic hashes evenly across the 8 buckets, he effectvly has 4GBps of throughput available. If one of the five links fails, he still has 4GBps of throughput available. With four links, assuming the traffic hashes evenly across the 8 buckets, he effectively has 4Gbps of throughput available. But if one of the four links fails, then he'll hash at 3:3:2 and effectively have 2.67Gbps available. In other words, the fifth link doesn't add any throughput benefit in the everything is working case -- four or five active links offers the same throughput -- but it offers a significant redundancy benefit. With five links, loss of one link is no impact to cpacity; with four, loss of one link is a 33% reduction in capacity. -- Brett ___ cisco-nsp 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] Bridging Serial Interfaces
On Fri, Nov 12, 2010 at 05:40:32PM -0500, Todd Shipway wrote: I've got a rather basic question, or at least I hope it is. A customer is trying to migrate from a point-to-point setup to a point-to-multipoint setup. I'm trying to help them with this by supplying serial and multilink ppp interfaces. They want these interfaces to be bridged. I've got the interfaces up and running and when configured for routing, they work fine. But they have strange default routing policies and need the bridging to be in place. I setup the bridge-group on each of the interfaces and set the protocol to ieee. interface Serial9/0/0/27:0 no ip address no cdp enable bridge-group 2 ! interface Serial9/0/0/28:0 no ip address no cdp enable bridge-group 2 bridge 2 protocol ieee I show the bridge group to be up and running as expected: Bridge Group 2 is running the IEEE compatible Spanning Tree protocol Port 106 (Serial9/0/0/27:0) of bridge group 2 is forwarding Port 107 (Serial9/0/0/28:0) of bridge group 2 is forwarding The routers at the remote end of the serial links are configured as below Router1: Interface serial 0 Ip address 172.16.0.1 255.255.255.252 Router2: Interface serial 0 Ip address 172.16.0.2 255.255.255.252 Both router1 and router2 are using the default route below: Ip route 0.0.0.0 0.0.0.0 serial 0 The issue is that no traffic will pass over the bridge. Router1 is unable to ping router2 and vice versa. Any ideas as to what I'm missing with this? You've configured your router to bridge Ethernet frames between the two serial interfaces. (Ethernet over HDLC framing) You've configured the Router1 and Router2 to send IP frames over the serial interface. (IP over HDLC framing) That won't work for reasons that should be obvious. Some options: (a) Connect the two T1s at the router in the middle with an L2VPN Layer 2 local-swtching connection, if that's supported on your platform. (b) Configure Router1 and Router2 with integrated routing and bridging. This would put the IP addresses on a BVI interface that would then be bridged to the serial interface. (c) Configure the serial interfaces on Router1 and Router2 as half-bridges. This results in the same functionality as Integrated Routing and Bridging -- you get IP over Ethernet over Serial, rather than IP over Serial -- but it's simpler to configure. AFAIK, it's only supported over PPP encapsulation, though, so you'd need to convert to PPP encapsulation on all four serial interfaces involved here. -- Brett ___ cisco-nsp 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 design
On Fri, Oct 22, 2010 at 07:24:51PM +0700, Rin wrote: Hi group, We need to design a MPLS network that has around 100 nodes (7600) divided into Core, Aggregation Access layer. OSPF and MPLS is deployed up to access layer. According to Cisco, an OSPF area should have no more than 50 nodes in order to minimize the database. With that concept, we should design our network into different areas, say Core Aggregation in Area 0, Access nodes in area 1. However, I reckon separating the network into different OSPF areas without summarization at ABR cannot minimize OSPF database, all routers still receive routes advertises by other routers. If we do summarization at ABR, MPLS cannot work since this is a continuous MPLS domain. You can't summarize the loopbacks[1], but you could summarize other routes. But, even without summaries, there are benefits to splitting the areas. It may not reduce the number of objects in the OSPF database (in fact, in some cases, it will increase them, since stub routes aren't carried as separate LSAs, but when they get summarized into the backbone or into another area, they become individual Type 3 LSAs) ... but it reduces the complexity of the OSPF route calculation, and it reduces the frequency with with the route calculation must run (since it only has to run when there's a change in an area that the router is in), and it creates opportunities for doing partial reclaculation. That said, I certainly agree with Oliver that 100 nodes is no big deal with modern equipment. (My largest area has 175 routers, most of which have considerably slower CPUs and considerably less RAM than a 7600, and it's full of microwave links, so there's a lot more topology changes than you have in what I presume is a mostly fiber-based network. It works fine.) So my question is should we separate the network into different OSPF areas as Cisco recommendation or should we keep all routers in an OSPF area 0? Note that we intend to provide MPLS L2VPN, L3VPN on this network; we can only use OSPF, ISIS is not an option. One area. (Probably even if you have customer routes in your IGP. Assuming you don't have stubby areas, if those routes are brought in as externals, the Type 5's will be in every area regardless of how many you have.) -- Brett [1] For whoever asked, the reason for that is that MPLS VPN relies on there being a /32 route to to the loopback of each PE so that there will be a distinct LSP to each PE. ___ cisco-nsp 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] Cogent IOS upgrade == BGP-3, update malformed
On Mon, Aug 23, 2010 at 01:34:50PM +0100, Zoe O'Connell wrote:
On 23/08/10 13:07, Florian Weimer wrote:
* Zoe O'Connell:
729078: Aug 22 16:21:39 MDT: %BGP-3-NOTIFICATION: sent to neighbor A.B.C.D
3/1 (update malformed) 21 bytes 31FE420C 31FE58C8 124683E8 0206CC67 00
729079: Aug 22 16:21:39 MDT: BGP: A.B.C.D Bad attributes
0060 0200 4140 0101 0040 020C 0205 00AE 0CB9 235A
2046 5BA0 4003 0426 6532 7580 0404 5DE8 C008 0800 AE52 0800 AE55 FD31
FE42 0C31 FE58 C812 4683 E802 06CC 6700 0002 1854 1608 1854 1609
5BA0 suggests its related to 32 bit ASNs. We've got the prefixes in
our table, apparently with a proper 32-bit ASN:
Yes, that's the conclusion we came to as well when we had it. (Luckily,
it was an iBGP link to a firewall so easier to troubleshoot than a
customer link). As far as I can recall, without Capability Negotiation
it can't send 4-byte ASNs and some devices have a bug or differing RFC
interpretation that means they can't handle being on the receiving end
properly - if Cogent won't change their end, an IOS upgrade on the
original psoters end should resolve it. I'm sure I sent a mail to
someone about it at the time with more precise detail, but I can't seem
to find it now.
There's no IOS upgrade that's going to make the router happy with the
message shown above. After the community attribute, it contains an
attribute startin with: 31FE420C. Among other things, that's
specifying a length of 0x420C, which is much longer than the entire
message. And it has the partial bit set on an optional,
non-transitive attribute, which isn't allowed. And it's Attribute Code
254, which doesn't exist (shouldn't cause a NOTIFY, though ... the
NOTIFY is likely being triggered by the length field.) And the 0x01 bit
it set in the flags byte, which is also wrong (but also shouldn't cause
a NOTIFY). It's pretty obviously a seriously malformed attribute.
Assuming the router is correctly logging the message it received, the
problem is on the sending end.
(It's disappointing how people troubleshoot these days. Shot in the
dark IOS upgrades and parameter changes, when the entire objectionable
message is logged and can be decoded with a copy of the BGP RFC and 10
minutes.)
-- Brett
___
cisco-nsp 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] DHCP route on VRF enabled interface.
On Sat, May 15, 2010 at 11:30:51AM -0600, victor wrote: Maybe someone would know why when router receives DHCP offer on a vrf interface the default route (option 3) gets installed in the main routing table and NOT in the corresponding VRF? Here is a piece of config and show ip route outputs: [ . . . ] Router#sho ver | in flash: System image file is flash:c181x-advipservicesk9-mz.124-6.T11.bin [ . . . ] For now to avoid confusion I removed default router offer with no ip dhcp client request router that means that I need to make sure that a correct default route is installed manually. But it doesn't work very well because the leased subnet changes periodically. So I'm looking for a way to make cisco dhcp client vrf aware. Your suggestions are appreciated. CSCsd20055, fixed in 12.4(11)T. -- Brett ___ cisco-nsp 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] DSL signals vs DOCSIS
On Fri, Dec 11, 2009 at 04:46:24AM -0800, Yuri Bank wrote: I understand that they use different frequency ranges, but why can't the DSL freqencies be converted and sent over fiber somewhere between the CPE and the DSLAM ? They could be. Do you think installing devices to do that at the point where the fiber meets the copper would be cheaper or better than installing small DSLAMs at the point where the fiber meets the copper? If so, why? -- Brett ___ cisco-nsp 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] Inserting a default route into a MPLS/VPN pointing out of the VRF
On Mon, Oct 19, 2009 at 04:49:40PM -0500, Justin Shore wrote: I've come across route-leaking examples but they all require me to point traffic to an outward-facing interface. Ie, I can't just point the default route to a specific upstream-facing interface. Is there another way? I can't see a solution with importing routes at the route-target level. Can I point it to a loopback outside of the VRF? [ ... ] This is probably a simple process but I haven't had to do it before without the FWSM which made it trivially easy. What simple solution have I overlooked and will kick myself for missing later? Cisco has no support for: ip route vrf vrfX x.x.x.x/x next-hop next-hop vrfY where the traffic in vrfX matching that route would be sent over into vrfY (and then forwarded according to vryY's forwarding table). (Some other vendors can do that.) (In your case, you want vrfY to be global, but that's not doable either.) The only clean way is to connect via an interface. For example, connect a cable from GIa/b to GIc/d and then configure: int GIa/b ip address x.x.x.1/30 int GIc/d ip vrf forwarding vrfX ip address x.x.x.2/30 ip route vrf vrfX 0.0.0.0/0 GIc/d x.x.x.1 (obviosuly I'm not using exact IOS commands above, but you get the idea.) On some platforms, this can be done with tunnels instead of physical interfaces to avoid using two physical ports and dealing with the risk that those ports might fail: int lo1 ip address z.z.z.10/32 int lo2 ip address x.x.x.20/32 int tun1 ip address x.x.x.1/30 tunnel source lo1 tunnel destination x.x.x.20 int tun2 ip vrf forwarding vrfX ip address x.x.x.2/30 tunnel source lo2 tunnel destination x.x.x.20 ip route vrf vrfX 0.0.0.0/0 tun2 How well this works depends on how tunnels are implemented on the platform you're using. It works fine on software-based routers. ASR1000s worked OK in my testing. Never tried 6500/7600s. Note that the suggestion to leak default from your global table into the VRF potentially fails on two accounts. First, you might or might not have a default in your global table. Second, if you do, leaking that would direct all internet traffic to follow the default route, and, assuming you have default plus a lot of more other routes in your global table, you wouldn't want traffic covered by a more-specific in the global table to follow the default if it originated in vrfX. That is, with a global table of: 100.0.0.0/8- A 0.0.0.0/0 - B if you import only 0.0.0.0/0 into a vrf, then all traffic matching the default in that VRF will be sent to B, even traffic traffic to 100.0.0.0/8. -- Brett ___ cisco-nsp 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] Management Vlan VS Vlan1
On Wed, Aug 19, 2009 at 10:56:23AM -0500, Murphy, William wrote: In all recent IOS versions and switching hardware you can disable VLAN 1 on trunk ports (switchport trunk allowed vlan remove 1) and the protocols you mentioned will still continue to function. This is how Cisco recommends you do it. Not on ethernet switch HWICs in 28xx and 38xx series routers. They still require VLAN 1 on all trunks. -- Brett ___ cisco-nsp 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] Global Route Leaking on same PE
On Tue, Jun 16, 2009 at 07:23:45PM +0200, Ivan Pepelnjak wrote: The last time I've seen discussion on this topic, you had to have an external back-to-back connection between a VRF interface and a global interface. Depending on the platform, you can do it with a GRE tunnel with both ends on the same router. (Should be fine on a software-switched platform; YMMV on a hardware switched platform.) ip route vrf test 64.193.x.x 255.255.255.248 192.168.222.1 global int lo888 ip address 10.0.0.1 255.255.255.255 int lo999 ip address 10.0.0.2 255.255.255.255 int tun1 ip address 10.0.0.5 255.255.255.252 tunnel source lo888 tunnel destination 10.0.0.2 int tun2 ip vrf forwarding test tunnel source lo999 tunnel destination 10.0.0.1 ip route vrf test 64.193.x.x 255.255.255.248 tunnel2 10.0.0.5 (Might want to force a larger MTU on the tunnel -- no fragmentation issues since the tunnel-encapsulated packets never leave the router.) -- Brett ___ cisco-nsp 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] Tunnel keepalive in NAT environment problem
On Tue, Nov 18, 2008 at 02:03:08PM +0100, Oliver Boehmer (oboehmer) wrote: Well, it looks like the linux NAT/firewall is not NAT'ing the keepalive GRE packets correctly, otherwise they would not arrive with the 172.16.1.1 src address on router2. Not sure what's happening there, but I would focus my attention on the NAT/firewall box.. I guess NAT for the other GRE packets work just fine? Maybe related to the different protocol type (0x0) or the lack of payload in the GRE keepalive packet? oli The issue is that a GRE keepalive packet has the originating tunnel endpoint IP address as the destination address of the encapsulated packet. That is, consider the following: interface tunnel1 tunnel source 10.0.0.1 tunnel destination 20.0.0.2 tunnel keepalive (Not sure I've got the syntax right, but you get the idea.) A keepalive packet generated by the router will look like the following: IP header: Source=10.0.0.1 Destination=20.0.0.2 Protocol=GRE GRE Header: Protocol=IP Encapsulated Packet: IP Header: Source=? (Not Inportant) Dest=10.0.0.1 Proto=GRE GRE Header: 0x The idea is that the router at the far end will received the packet, remove the outer header, and transmit the encapsulated packet. (The router at the far end will, then, not do any special processing all for a keepalive packet originating from the near end.) THe issue with keepalive is that the 10.0.0.1 appears in the encapsulated packet, so if that's being NAT'd somewhere, for keepalive to work, the NAT needs to translate the address on the encapsulated packet also. AFAIK, essentially no NATs will do that. So, anyway, suppose that 10.0.0.1 is being NAT'd to 30.0.0.1. The far end router then receives: IP header: Source=30.0.0.1 Destination=20.0.0.2 Protocol=GRE GRE Header: Protocol=IP Encapsulated Packet: IP Header: Source=? (Not Inportant) Dest=10.0.0.1 Proto=GRE GRE Header: 0x The far end router's normal GRE processing then involves removing the outer header, and attempting to send the following packer: IP Header: Source=? (Not Important) Dest=10.0.0.1 Proto=GRE GRE Header: 0x This fails because the far end router has no path to get to 10.0.0.1, because it should be sending to 30.0.0.1. The reason that isn't a problem for other GRE packets is that, in general, there's no requirement that the encapsulated packet be translated by the NAT, because, in general, the tunnel endpoint IP addresses don't appear as source or destination addresses on the encapsulated packet. More generally, GRE works fine through NAT as long as the expectation is that one or both of the tunnel endpoint addresses will be translated, but the packets flowing through the tunnel don't need NAT. However, once you enable keepalive, you effectively create a requirement that the encapsulated packets be translated, because Cisco GRE keepalive depends on using the tunnel origin/destination address in encapsulated packet. This also, in general, breaks keepalives when a tunnel interface has ip forwarding vrf ' and tunnel vrf where and aren't the same. (This is because the keepalive processing on the far end will result in a packet being send in vrf to a destination IP address that is reallyin vrf .) And, yes, I think this is horribly broken. A much better GRE keepalive implementation would be to just send IP header: Source=30.0.0.1 Destination=20.0.0.2 Protocol=GRE GRE Header: Protocol=KeepaliveRequest and have the far end router generate a IP header: Source=20.0.0.2 Destination=30.0.0.1 Protocol=GRE GRE Header: Protocol=KeepaliveResponse This would work through NAT and through complicated VRF configurations. But that's not what Cisco implemented. -- Brett ___ cisco-nsp 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] Multiple Ethernet links for redundancy
On Sat, Nov 08, 2008 at 04:26:09AM +0200, Mario Spinthiras wrote: Most beneficial is to port-channel the interfaces. This is clever in many ways. Handling the interface redundancy any other way complicates things IMHO. With a port-channel interface you have more bandwidth and redundancy. And you also have exposure to any failure that puts one of the links into a DOWN state on end of the link but not on the other and any failure that prevents traffic from flowing over a link but doesn't put the interfaces into a DOWN state. On the other hand, having two Layer 3 links and running a routing protocol protects against most such failures -- if the OSPF hellos aren't being received bidirectionally, the link won't get used. -- Brett ___ cisco-nsp 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] Layer 2 question
On Tue, Jul 29, 2008 at 12:43:10PM -0400, Mike Johnson wrote: What happens if a layer 2 switch receives a frame that needs to be forwarded out the same port that the incoming frame was received on? It will discard it. Back when Layer 2 switches were typically used to connect multiple shared-media Ethernet segments, this happened all the time -- every time two nodes on the same shared-media Ethernet segment communicated. These days, most switch ports connect only to a single device, but the operation of Layer 2 switching (which is just bridging) hasn't changed. Im realize that a typical layer 2 switch would never forward that packet upstream in the first place. However, If it did in fact happen what does the upstream L2 switch do? Consider the case of a hub (not a switch) connected to a switch port, and multiple devices on that hub communicating with each other. The switch sees all the packets, and doesn't forward them. -- Brett ___ cisco-nsp 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] SmartNet coverage on Cisco's chassis-based products
On Mon, Feb 11, 2008 at 05:28:09PM -0600, Justin Shore wrote: Tony Varriale wrote: Are they cheaper once you buy the software license? Let's not forget, the software license is not transferrable. That's a typical oops not only in this method but from 3rd party resellers. This may be blasphemy here but I'm really surprised that no one has ever taken the big C to court on this particular issue because C would almost certainly lose. It's difficult for a customer to initiate the legal action, because they'd be asking the court to rule on a hypothetical (i.e. asking the court to declare that if the customer were to attempt to use a transferred license, they'd not be violating any of Cisco's rights) or publicly stating that they had breached Cisco's interpretation and asking the court to say that no violation of Cisco's rights had occurred. Courts don't generally do that (and, in the latter case, a company probably wouldn't publicly admit their violation of Cisco's interpretation, because there's no advantage do doing so). What courts are good at is ruling on actual claims. So, here, what we'd need is for (1) Cisco to demand a relicensing fee from a customer using transferred software, (2) that customer to refuse to pay, and (3) Cisco to sue that customer. That's unlikely to happen, becasue the risk/reward to Cisco for filing suit just isn't there. If Cisco sues and loses, then everyone starts transferring licenses, because a judge said it was legal. That's a big risk, considering that currently, most customers play by Cisco's interpretation already, just out of fear that Cisco might win. So, basically, the potential reward of suing is that the small percentage of people running on transferred licenses would start paying; the risk is that a judge tells the world that Cisco's interpretation is unenforcable. There's no reason at all for Cisco to take the risk. Microsoft fought that battle against people selling the copy of Windows that came bundled with their PC or their PC and OS when they bought a new model. MS lost and set a perfect precedent. The courts found that the Doctrine of first sale does apply to OSs and bundled software. (see Softman v. Adobe) Just because C calls it a license doesn't mean that it actually is. To be clear, I think Cisco's position is unenforcable and that they'd lose in court. But the situation with Cisco is more complicated, because customers with SmartNet often aren't running the IOS that came with the box; they've upgraded (as allowed by their SmartNet contract) over time. While the right to transfer the software that came with the box might be clearly established, the right to transfer the software obtained pursuant to a SmartNet contract isn't as clear. Not that I want to take on the Big C. It is something that I've wondered about for years. If MS, Adobe and others were slapped down by the courts on this very thing then why not the Big C? Cisco hasn't make the mistake of suing anyone. -- Brett ___ cisco-nsp 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] Configure QoS by time [bcc][faked-from]
On Thu, Aug 02, 2007 at 12:06:01AM -0500, Tolstykh, Andrew wrote: You can schedule a simple job in Kiwi Cattools (freeware up to 5 managed devices). KRON supports only the exec level cli commands. I haven't tried it but would assume that the exec level command copy flash:filename running-config could be used to reconfigure the router. (Replace flash: as appropriate for the router in question, and put the configuration commands you want entered into filename.) -- Brett ___ cisco-nsp 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] Newbish OSPF DR question on VLANs
On Thu, Jun 07, 2007 at 12:57:39PM +0300, Hank Nussbacher wrote: At 05:00 AM 07-06-07 -0400, Rodney Dunn wrote: Also depends if you have the priority set and who came up first. From the OSPF Design Guide: http://www.cisco.com/warp/customer/104/1.html DR and BDR election is done via the Hello protocol. Hello packets are exchanged via IP multicast packets (Appendix B) on each segment. The router with the highest OSPF priority on a segment will become the DR for that segment. The same process is repeated for the BDR. In case of a tie, the router with the highest RID will win. The default for the interface OSPF priority is one. Remember that the DR and BDR concepts are per multiaccess segment. Setting the ospf priority on an interface is done using the ip ospf priority value interface command. [ ... ] There is something I am missing here that I am trying to understand. DR election is not pre-emptive. Once one router becomes the DR, it will remain the DR as long as it remains up; another, higher priority/router-id router coming up won't replace it. When two routers come up at roughly the same time, the router with the highet priority will become DR, with ties broken by router-id, kist as you describe above. (Similarly, if a subnet splits long enough for a router on both sides to become DR, and then the subnet is rejoined, you'll have two DRs and the one with the highest priority or router-id will win that contention and remain the DR.) If a lower-priority/router-id router comes up first and is up long enough to declare itself the DR, another router coming up later won't replace it; similarly, if the highest priority/router-id router is the DR and it goes down, a lower priority/router-id router will become the DR and will remain DR even after the higher priority/router-id router comes back up. Consequently, over the long haul, what you generally end up with is that the DR is the router with the longest uptime. An exception is that if you configure a router with priority 0, it will never become DR. (So, if all the routers on the subnet are priority 0, then there will be no DR for that subnet.) -- Brett ___ cisco-nsp 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 it won't route vlan 1 ?
On Tue, May 15, 2007 at 07:51:29PM +0200, Jerome Covini wrote: There is only one 'vlan1' if you have vlan1 on more than one interface (eg: gig1/1 and gig1/2) they are actually the same vlan. This device is a switch, not an independent router. You should be able to 'no shut' the vlan1 interface and use that instead and leave the port as a trunk. vlan1 has been generally 'pseudo-reserved' on cisco for as long as I can remember. I suspect that it was working some other way was some odd artifact of the code that they've since closed to prevent unexpected operation. For info, the platform onto which it was working was a totally different one i.e. Cisco 8540CSR with 2port GE modules. This was accepting to have multiple vlan 1 routed subinterfaces, as well as multiple vlan x routed subinterfaces . Probably the odd code artefact you are referring to ! It's not a code artifact; that's a completely different platform. The 8540CSR was more like a router -- there were no global VLAN identifiers. You could use the same VLAN ID on different interfaces pretty much at will; you could put the same LVAN (bridge-group, in 8540-speak) on multiple interfaces with a different tag on each one, and so on. The backplane architecture was ATM, not VLAN based; tags were applied at interface level as needed. The 6500 architecture, on the other hand, is built around VLANs. A Layer 3 interface is architecturally a VLAN with a SVI and a single member port; when it's done on a physical interface, the switch allocates an internal VLAN number for it; when it's done on a subinterface, the switch more or less has to use the tag you specify as the VLAN number. (There's limited hardware support for VLAN tag translation, but it's not the any VLAN with any tag on any port that something like an 8540 could do, and Cisco has elected to not try to magically configure translation to accomodate vlan tag reuse (and complain when you specify something that the hardware can't support), and to instead just not allow vlan tag reuse.) -- Brett ___ cisco-nsp 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 router recommendations
On Sat, Apr 21, 2007 at 02:32:22PM +0200, Gert Doering wrote: 7600/Sup720 will do whatever you need, provided you use a different local address for each tunnel source (if you have multiple tunnels on the same local IP address, the hardware can't do the tunneling, and the CPU is much slower). But it won't verify the source address on GRE packets it receives, which makes it feasible to forge GRE packets without forging the source address, which in some configurations makes some attacks easier. That relevant in some situations and not in others ... -- Brett ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
