[c-nsp] same mac for different ip addr
Hi all. Can someone give me an answer on this. We have a platform that run on Redhat EntR5.3 and uses subinterfaces. I seem that the platform sends the same MAC for all interfaces. What happens in the arp table on the default gateway. Does it keep track of all ip address or does it overwrite it. /Arne ___ 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 peer groups / performance question
Hi, On Mon, Apr 19, 2010 at 10:02:34PM -0400, Paul Stewart wrote: Has anyone studied how much faster BGP peer groups are on very loaded routers? I have a customer that I'm doing work with currently that has about 300 BGP peers on a Sup720/7613 box. Downstream customers take about 10 minutes to receive a full routing table. With current IOS versions, peer group don't bring any performance advantages (as peers with identical output policies get grouped into update-groups automatically). OTOH, peer-groups / peer-templates are nice to reduce the size of your router configuration, so for us, it's still worth using them. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpvsThdx5asx.pgp Description: PGP signature ___ 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 mac for different ip addr
Hello Arne, Can someone give me an answer on this. We have a platform that run on Redhat EntR5.3 and uses subinterfaces. I seem that the platform sends the same MAC for all interfaces. What happens in the arp table on the default gateway. Does it keep track of all ip address or does it overwrite it. /Arne on the router, only one MAC should be mapped to one IP but not vice versa. Several IPs can point to the same MAC. Cheers Sascha ___ 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] 3550s, SDM, and Feature Manager
Can anyone provide some kind of insight as to exactly how the feature-manager on a 3550 handles assigning Vlan interfaces to vlan-labels? I ran into some issues tonight attempting to deploy an ACL across all interfaces on a 3550, where the switch started switching some Vlan interfaces in software. From what I can tell, the switch is organizing different Vlans into different vlan-labels in feature manager, and each vlan-label would compile and attempt to install my ACL, instead of all the vlan interfaces being grouped into a single vlan-label, that only compiled the ACL once. This is causing a major issue, as I'm unable to actually deploy a 11-line ACL on 40 Vlan interfaces on a single 3550 with the default SDM template (1K security ACL TCAM entries). From switch to switch the number of vlan-labels and vlans changes -- I'm really only running into TCAM exhaustion issues on 10% of my switches that I attempt this on. But I am curious as to what's going on internally, and why two interfaces, that seem to be relatively identical, would end up on different vlan-labels. For example -- two interfaces, both configured almost identically, but assigned to different vlan-labels. Output of most of the relevant commands I know follows. If anyone can provide any insight, it would be appreciated. interface Vlan104 description deviceid=12345/server1.example.com ip address 10.10.34.17 255.255.255.248 secondary ip address 192.168.184.233 255.255.255.248 no ip redirects no ip unreachables no ip proxy-arp end interface Vlan137 description object_id=54321/server2.example.com ip address 172.17.96.49 255.255.255.248 secondary ip address 192.168.187.185 255.255.255.248 no ip redirects no ip unreachables no ip proxy-arp end #show fm vlan-label 8 Input Features: Interfaces or VLANs: Vl104 Priority: normal Bits: NoUnreach NoRedirect Vlan Map: (none), 0 VMRs. Access Group: (none), 1 VMRs. Multicast Boundary: (none), 0 VMRs. Output Features: Interfaces or VLANs: Priority: low Bridge Group Member: no Vlan Map: (none), 0 VMRs. Access Group: (none), 0 VMRs. #show fm vlan-label 6 Input Features: Interfaces or VLANs: Vl137 Priority: normal Bits: NoUnreach NoRedirect Vlan Map: (none), 0 VMRs. Access Group: (none), 1 VMRs. Multicast Boundary: (none), 0 VMRs. Output Features: Interfaces or VLANs: Priority: low Bridge Group Member: no Vlan Map: (none), 0 VMRs. Access Group: (none), 0 VMRs. #show tcam inacl 1 vlan-l 8 Label Value: 8200(vlan label 8) Number of entries: 12 Index Ts CAMAs data 4 msk F4 00 00 00 00 E0 00 00 00 80 FF 00 00 C0 00 FF 00 00 361 94 00 00 00 00 E0 00 00 00 80 08 00 00 00 00 09 00 00 00260086 5 msk F5 00 00 00 00 E0 00 00 00 80 FF 80 00 C0 00 00 FF FF 374 94 00 00 00 00 E0 00 00 00 80 08 00 00 40 00 00 02 08 00260086 6 msk F6 00 00 00 00 00 00 00 00 80 FF 00 00 C0 00 FE 00 00 521 96 00 00 00 00 00 00 00 00 80 08 00 00 00 00 58 00 00 00260086 7 msk F6 00 00 00 00 00 00 00 00 80 FF 00 00 C0 00 FF 00 00 574 96 00 00 00 00 00 00 00 00 80 08 00 00 00 00 09 00 00 00260086 7 msk F6 00 00 00 00 00 00 00 00 80 FF 00 00 C0 00 FF 00 00 5964 96 00 00 00 00 00 00 00 00 80 08 00 00 00 00 67 00 00 00260086 9 msk FC FF FF 00 00 00 00 00 00 80 FF 00 01 00 00 00 00 00 75152 90 08 06 00 00 00 00 00 00 80 08 00 01 00 00 00 00 00 00260086 10msk F7 00 00 00 00 00 00 00 00 80 FF 80 00 C0 FF FF 00 00 841 96 00 00 00 00 00 00 00 00 80 08 00 00 80 00 B3 00 00 00260086 11msk F7 00 00 00 00 00 00 00 00 80 FF 80 00 C0 00 00 FF FF 894 96 00 00 00 00 00 00 00 00 80 08 00 00 80 00 00 00 B3 00260086 11msk F7 00 00 00 00 00 00 00 00 80 FF 80 00 C0 00 00 FF FF 9164 96 00 00 00 00 00 00 00 00 80 08 00 00 40 00 00 02 08 00260086 13msk FE FF FF 00 00 00 00 00 00 80 FF 00 00 00 00 00 00 00 107 1 92 08 06 00 00 00 00 00 00 80 08 00 00 00 00 00 00 00 00260086 IP default entry 202 msk F 0 1 0 0 1 00 FF 0 00 0 0 1624 80 9 0 1 0 0 1 00 08 0 00 0 0 2082 non-IP default entry 203 msk F 0 1 0 0 1 00 FF 0 00 0 0 1625 45 9 0 0 0 0 1 00 08 0 00 0 0 0082 #show tcam inacl 1 vlan-label 6 Label Value: 8198(vlan label 6) Number of entries: 12 Index Ts CAMAs data 4 msk F4 00 00 00 00 E0 00 00 00 80 FF 00 00 C0 00 FF 00 00 441 94 00 00 00 00 E0 00 00 00 80 06 00 00 00 00 09 00 00 00260086 5 msk F5 00 00 00 00 E0 00 00 00 80 FF 80 00 C0 00 00
Re: [c-nsp] same mac for different ip addr
On Tue, Apr 20, 2010 at 08:35:48AM +0200, Arne Larsen / Region Nordjylland wrote: Hi all. Can someone give me an answer on this. We have a platform that run on Redhat EntR5.3 and uses subinterfaces. I seem that the platform sends the same MAC for all interfaces. What happens in the arp table on the default gateway. Does it keep track of all ip address or does it overwrite it. /Arne When you say subinterfaces -- do you mean vLAN/dot11q interfaces configured with vconfig, or secondary addresses configured as aliases? In either case, it isn't a major issue. If it's vLANs, most switches maintain a different layer 2 forwarding database for each vLAN, so the same MAC in multiple vLANs is handled appropriately. If it's aliases, it still isn't an issue, as the layer 3 device will gladly store the same MAC address in the ARP table for multiple IPs. -- Brandon Ewing(nicot...@warningg.com) pgp9N3mGCNgAy.pgp Description: PGP signature ___ 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 mac for different ip addr
On 04/20/2010 07:35 AM, Arne Larsen / Region Nordjylland wrote: Hi all. Can someone give me an answer on this. We have a platform that run on Redhat EntR5.3 and uses subinterfaces. Yes I seem that the platform sends the same MAC for all interfaces. What happens in the arp table on the default gateway. Does it keep track of all ip address or does it overwrite it. /Arne It'll be fine. ARP handles 1 IP with the same mac. ___ 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 LSA Type 11
HI Hash i already knew that Cisco support Inter-AS TE but without IGP running between ASBRs and it still depend on LSA 10 to flood TE attributes internally check this link http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/gsintast.html so i want to know if Cisco supports Inter-AS TE with OSPF running between ASBRs ? and if yes that means LSA 11 is used to flood attributes if not i think there is no need for any router to generate such LSA if it isn't needed for any application thnx --Ibrahim On Mon, Apr 19, 2010 at 11:49 PM, Hash Aminu has...@gmail.com wrote: you will see type 11 if you have inter-AS TE which i believe is not widely deployed. Your Questions should be Does Cisco Supports Inter-AS TE ? Regrds Hash ___ 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] Tier-2 Internet Provider Design
Hi, I am working on the design of a large-scale Internet pop and services for a national carrier. I would appreciate if you could direct me to some very good books or guides on this subject. Thanks. Felix ___ 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] DMVPN scalability question on the 28XX ISR's
I don't know the topology of the remote networks but is there a reason that you have to run a routing protocol with remote sites ? Are they fully meshed ? If there are not multiple paths to a remote location why not just do static routes ? Look at ODR ___ 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] Two routers with Single ISP Scenario
On Mon, 2010-04-19 at 14:29 +0200, Peter Rathlev wrote: On Mon, 2010-04-19 at 14:11 +0200, shadow floating wrote: I've one of my customers who wants to stick to single ISP but wants to implement the full redundancy (no single point of failure) network scenario, is there a way to connect to 2 routers internet facing with in an active/standby fashion to a single ISP with a single IP range? The provider and the customer could both use HSRP (or VRRP or GLBP). It needs a L2 connection between the two sites though, and that might not be optimal. It can work fine though. We currently use this as a customer of AS3308. +--+ +--+ | ISP PE 1 |--- (?) ---| ISP PE 2 | +--+ +--+ | | | | +--+ +--+ | CE 1 |--| CE 2 | +--+ +--+ The top link (between ISP PE 1 and PE 2) is not strictly necessary and the ISP might prefer not having it. A much simpler and more robust approach is to get a private ASN from your ISP and run BGP. This is the scenario private ASN's are intended for and eliminates many layer 2 dependencies. All you need to do is accept a default route from the ISP and advertise your prefix to the ISP. Don't forget to test and verify that the ISP is passing on your prefixes from your advertisements rather than static routing. You will regret depending on a link failure being detected by the interfaces on both ends. Of course, if you really care about redundancy, you need to make sure the two paths between your routers and the ISP's routers are physically diverse so that when one fails, the other has a fighting chance of staying up. Watch out for common paths not just getting to the ISP but also from the ISP's points of presence you are using to their upstream connections. Also consider physical diversity of the routers at each end, you probably don't want a site problem (e.g. fire or extended power outage) to take you off the Internet either. Lot's of possibilities, your choices are limited only by your budget. For example, you may want to extend your routing through your firewalls to your internal sites so an internal network problem does not isolate the survivors (yes, you can dynamically route through firewalls without sacrificing security. But just like it is easy to add redundancy that sacrifices, rather than improves, availability; it takes care and effort to route through firewalls without degrading your security). Bottom line is you can protect against everything except your ISP fat fingering their routing tables and going completely off the air. Good luck and have fun! -- Vincent C. Jones Networking Unlimited, Inc. Phone: +1 201 568-7810 v.jo...@networkingunlimited.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/
[c-nsp] Cache Engines and Bandwidth Managers
Hello, Could anyone recommend some good cache engine platforms and bandwidth managers for use in an ISP NOC? The products should accommodate multi-gigabit throughputs, with support for 1GB/10GB interfaces. I don't mind if they are not Cisco products. Thanks. Felix ___ 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] 6500 line card mounted cable management bars (??)
We have some of these in the data center. They fit the screws on the Cat 6500 line cards, and they slide on. So they a) can be installed/removed without taking line card out and b) do NOT go in front of the dreaded fan card. They are very simple, and flat, and have a row of slits for velcro / tie downs. The funny thing, and my question, is that we don't know where we got them from :) Anyone know where these come from ? I tried several google searches and looked around on cisco.com. The bar does have a Foxconn stamp. Thanks in advance for any info. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 SH1-0151. This is the serial number, of our orbital gun. ___ 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 line card mounted cable management bars (??)
Maybe a picture will help. There is a Cisco original cabling management for C6509E-V chassis, that can be ordered as WS-C6509-V-E-CM. -pavel On Tue, Apr 20, 2010 at 9:01 PM, Brandon Applegate bran...@burn.net wrote: We have some of these in the data center. They fit the screws on the Cat 6500 line cards, and they slide on. So they a) can be installed/removed without taking line card out and b) do NOT go in front of the dreaded fan card. They are very simple, and flat, and have a row of slits for velcro / tie downs. The funny thing, and my question, is that we don't know where we got them from :) Anyone know where these come from ? I tried several google searches and looked around on cisco.com. The bar does have a Foxconn stamp. Thanks in advance for any info. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 SH1-0151. This is the serial number, of our orbital gun. ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500 line card mounted cable management bars (??)
On Tue, 20 Apr 2010, Brandon Applegate wrote: We have some of these in the data center. They fit the screws on the Cat 6500 line cards, and they slide on. So they a) can be installed/removed without taking line card out and b) do NOT go in front of the dreaded fan card. They are very simple, and flat, and have a row of slits for velcro / tie downs. On a side-note, can't we all contact our sales teams and tell them about our interest in a high-density breakout cable solution for our industry? Having RJ45 on the actual blade makes for problems with both density and cable mess when swapping LCs. We need a 12+ high density connector so a 48 port card just has 4 cables coming out of it. I know of the older cards, but we need something that'll work across vendors as well. Let's fix this cable mess in a more widely adoptable way! -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500 line card mounted cable management bars (??)
There was the old rj21 telco that Cisco used on the 10 and 10/100 cards for the 6500- but it was big and bulky, and only good to cat4/5. There is a newer connector - the MRJ21 - that terminates 24 pairs of cat5e; giving you 12 ports of 10/100 or 6 ports of 10/100/1G or PoE. It is small (about 2cmx4cm), rated for high speeds, and gives decent density. The MRJ21 is a Tyco/Amp patent, but liberally licensed to others (ADC, others), and used already on Force10's E series high-density (90 port) copper cards. Lots of modular solutions, cable assembles, patch panels, etc available. Now just have to convince Cisco after they were burned going with the MTRJ fibre connector... Brian On 10-04-20 8:39 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Tue, 20 Apr 2010, Brandon Applegate wrote: We have some of these in the data center. They fit the screws on the Cat 6500 line cards, and they slide on. So they a) can be installed/removed without taking line card out and b) do NOT go in front of the dreaded fan card. They are very simple, and flat, and have a row of slits for velcro / tie downs. On a side-note, can't we all contact our sales teams and tell them about our interest in a high-density breakout cable solution for our industry? Having RJ45 on the actual blade makes for problems with both density and cable mess when swapping LCs. We need a 12+ high density connector so a 48 port card just has 4 cables coming out of it. I know of the older cards, but we need something that'll work across vendors as well. Let's fix this cable mess in a more widely adoptable way! ___ 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 line card mounted cable management bars (??)
The MRJ21 is a Tyco/Amp patent, but liberally licensed to others (ADC, others), and used already on Force10's E series high-density (90 port) copper cards. Lots of modular solutions, cable assembles, patch panels, etc available. We need license free standards for this kind of stuff, having to do licensing is quite a big hurdle and I can understand why people are hesitant to use it. ___ 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/
