Re: [c-nsp] Feedback on upcoming removal of FTP access to secured software
Hi, On Tue, Sep 14, 2010 at 10:37:25AM -0800, Leif Sawyer wrote: If you take it a step further and use ssh keys, then you've got an additional layer of security for them. I don't think Cisco understands ssh keys. 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 pgpl7wMafVnJy.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] Feedback on upcoming removal of FTP access to secured software
Hi, On Tue, Sep 14, 2010 at 08:58:05PM -0400, Jared Mauch wrote: I may be able to lead the cabal if folks so desire, rounding up the right people from the cisco side. Count me in. But you know that already :-) 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 pgpIuImqNa93D.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/
[c-nsp] Conditional advertise-map
Hi all, I have a scenario where I have two upstreams ASN5511 and ASN36997. Both do send me a default route and I choose ASN5511 as the best path. All my outbound traffic is via ASN5511 and the return is distributed between the two. What I want however is to use an advertise map so I ONLY advertise my prefixes to ASN5511 so I only use his link but fail-over to advertising my prefixes to ASN36997 in the event ASN5511 fails. I have created the the two route-maps to be matched NO_DEFAULT_FT and AS_LIST and configured as below. ## access list below is to avoid me feeding back to my up-streams the routes learned from other up-streams. That way I only advertise to the up-streams only prefixes from me and my down-streams. ip as-path access-list 10 deny ^5511_ ip as-path access-list 10 deny ^12455_ ip as-path access-list 10 deny ^36997_ ip as-path access-list 10 permit .* !! ## Match against filter below. If anything from ASN5511 is available, ip as-path access-list 20 permit ^5511_ !! route-map NO_DEFAULT_FT permit 10 match as-path 20 !! route-map AS_LIST permit 10 match as-path 10 !! neighbor 41.222.1.33 advertise-map AS_LIST non-exist-map NO_DEFAULT_FT Any ideas why it doesn't work. PS. Am working on drawing :) -- cheers Richard ___ 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] Multihoming
Hi, I am pretty new to this concept and would appreciate any guidance on how as a customer I can achieve redundacy with autofailover between 2 ISPs. Can I achieve this when I have a /29 from ISP1 and do not have my own PI ips? All my services dns, email, wan are hosted by the ISP1. Any assistance on this will be appreciated. Rocker ___ 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] Multihoming
Hi Rocker, Have a look into F5 GTM. Thanks. :-) regards, YapCH http://itcertguides.blogspot.com/ Message: 10 Date: Wed, 15 Sep 2010 12:00:56 +0300 From: Rocker Feller rocker.rockerfel...@gmail.com To: cisco_nsp cisco-nsp@puck.nether.net Subject: [c-nsp] Multihoming Message-ID: aanlktinxk4x=mkhemosmualwi6=jst-xw+aaii9g+...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, I am pretty new to this concept and would appreciate any guidance on how as a customer I can achieve redundacy with autofailover between 2 ISPs. Can I achieve this when I have a /29 from ISP1 and do not have my own PI ips? All my services dns, email, wan are hosted by the ISP1. Any assistance on this will be appreciated. Rocker ___ 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] Multihoming
Not many options for you I'm afraid. Some people filter out routes smaller than a /24. Even if you had a /24 from ISP1, you would then have to get their permission to have ISP2 advertise it. Most aren't willing to do this. Is a micro (/24) allocation from ARIN (if in the US) a possibility? If so, you could then run BGP to multiple providers and make this a very simple configuration. If not, you'll likely have to rely on application-layer redundancy. You can prioritize MX records if you are hosting your mail on-site through ISP1's ip addressing (what you stated seemed a bit unclear), and you could probably do some round-robin DNS entries for web hosting, but it won't be perfect. On 09/15/2010 02:00 AM, Rocker Feller wrote: Hi, I am pretty new to this concept and would appreciate any guidance on how as a customer I can achieve redundacy with autofailover between 2 ISPs. Can I achieve this when I have a /29 from ISP1 and do not have my own PI ips? All my services dns, email, wan are hosted by the ISP1. Any assistance on this will be appreciated. Rocker ___ 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] Conditional advertise-map
Richard, I have a scenario where I have two upstreams ASN5511 and ASN36997. Both do send me a default route and I choose ASN5511 as the best path. All my outbound traffic is via ASN5511 and the return is distributed between the two. What I want however is to use an advertise map so I ONLY advertise my prefixes to ASN5511 so I only use his link but fail-over to advertising my prefixes to ASN36997 in the event ASN5511 fails. I have created the the two route-maps to be matched NO_DEFAULT_FT and AS_LIST and configured as below. ## access list below is to avoid me feeding back to my up-streams the routes learned from other up-streams. That way I only advertise to the up-streams only prefixes from me and my down-streams. ip as-path access-list 10 deny ^5511_ ip as-path access-list 10 deny ^12455_ ip as-path access-list 10 deny ^36997_ ip as-path access-list 10 permit .* !! ## Match against filter below. If anything from ASN5511 is available, ip as-path access-list 20 permit ^5511_ !! route-map NO_DEFAULT_FT permit 10 match as-path 20 !! route-map AS_LIST permit 10 match as-path 10 !! neighbor 41.222.1.33 advertise-map AS_LIST non-exist-map NO_DEFAULT_FT Any ideas why it doesn't work. I'm not 100% sure, but as far as I was able to find out, you can't use an AS-path ACL in the non-exist-map (NO_DEFAULT_FT) to match on the prefixes. The router searches the main routing table (so the match for routes is not limited to BGP prefixes), which does not include the AS path information. Can you replace this with a prefix list matching on some AS5511 prefixes? oli ___ 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] Multihoming
Hi Rocker, Rocker Feller wrote: I am pretty new to this concept and would appreciate any guidance on how as a customer I can achieve redundacy with autofailover between 2 ISPs. You need PI space to do this. Because each ISP can only route his own PA spaces plus the PI spaces from his customers. Maybe there could be a solution with doing some NAT on ISP2 to let your PA space from ISP1 look like PA space from ISP2. This could do redundancy in upstream direction but not in downstream. But if you have some public servers you need PI space. -- Greetings Thomas ___ 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] Multi Area OSPF
Hi Guys, Im having some issues with setting up multi area ospf between a j 2320 and a cisco 1812. I have a funny feeling the issues will be user related. The j2320 is acting as an abr with backbone area 0.0.0.0 and stub area 0.0.0.1 and advertises a default route into the stub area. The 1812 is set as a stub with no other routing protocols being used. When I use the redistribute static or redistribute connected commands it advises these cant be used as the router is an asbr. The router is only running 1 ospf process for the stub area so I am not sure why this is occurring. I add the network x.x.x.x y.y.y.y area 0.0.0.1 command and can start seeing a default route being sent by the juniper which is great but the juniper cannot see anything being sent from the router. I can get around this by setting the network in the ospf process to 0.0.0.0 255.255.255.255 but is this the correct way to do this as it would mean that any interface on the router will be sending out ospf requests which I do not want to occur as I want to be specific. Any ideas? Nick -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. ___ 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] Multi Area OSPF
On Wed, 15 Sep 2010, Nick Ryce wrote: Hi Guys, Im having some issues with setting up multi area ospf between a j 2320 and a cisco 1812. I have a funny feeling the issues will be user related. The j2320 is acting as an abr with backbone area 0.0.0.0 and stub area 0.0.0.1 and advertises a default route into the stub area. The 1812 is set as a stub with no other routing protocols being used. When I use the redistribute static or redistribute connected commands it advises these cant be used as the router is an asbr. The router is only running 1 ospf process for the stub area so I am not sure why this is occurring. I don't believe you can redistribute anything into OSPF in a stub area. If you need that, you need the stub to be an NSSA...which is basically a stub area that can have ASBRs (can export routes into OSPF to be advertised beyond the area). -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] Conditional advertise-map
Richard, Is the arrangement that 36997 will provide a backup service for you, so its a last resort to pull traffic through them? If that is the case, have you tried prepending your advertisments towards 36997? Also, I can see from global bgp they are not peering with eachother so its not a situation where communities could help. The other solution is to advertise a supernet to 36997 and break this in half and advertise both subnets to 5511 (assuming you have a decent sized prefix /24). Perhaps you have already tried these solutions, or don't want to head that way, i'm not sure :) I'll check this one out actually (your advertise map) - its a good situation to lab up and try! If you are having problems because of the access lists trying to prevent re-advertisment of routes, you could tag them when they come in instead (add community), and filter them out on egress... Hope this helps. On 15 September 2010 09:08, Richard Mikisa rmik...@gmail.com wrote: Hi all, I have a scenario where I have two upstreams ASN5511 and ASN36997. Both do send me a default route and I choose ASN5511 as the best path. All my outbound traffic is via ASN5511 and the return is distributed between the two. What I want however is to use an advertise map so I ONLY advertise my prefixes to ASN5511 so I only use his link but fail-over to advertising my prefixes to ASN36997 in the event ASN5511 fails. I have created the the two route-maps to be matched NO_DEFAULT_FT and AS_LIST and configured as below. ## access list below is to avoid me feeding back to my up-streams the routes learned from other up-streams. That way I only advertise to the up-streams only prefixes from me and my down-streams. ip as-path access-list 10 deny ^5511_ ip as-path access-list 10 deny ^12455_ ip as-path access-list 10 deny ^36997_ ip as-path access-list 10 permit .* !! ## Match against filter below. If anything from ASN5511 is available, ip as-path access-list 20 permit ^5511_ !! route-map NO_DEFAULT_FT permit 10 match as-path 20 !! route-map AS_LIST permit 10 match as-path 10 !! neighbor 41.222.1.33 advertise-map AS_LIST non-exist-map NO_DEFAULT_FT Any ideas why it doesn't work. PS. Am working on drawing :) -- cheers Richard ___ 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] Multihoming
You could probably get away with a second provider if you implement NAT and don't really need to provide services to the outside world from that location. For example if it was an office connection and you really just needed internet access with some redundancy. If things are more complicated than that - for instance if you are hosting incoming vpn connections, web services etc from that site, you really should look into getting your own IP space when you start talking about multiple providers, for instance if ISP1 goes down and you are providing these services, you are pretty much screwed. As Walter suggested, you can play with DNS a bit and move things around - but it is a very manual time consuming process and services will be unworkable during the transition. On 15 September 2010 10:00, Rocker Feller rocker.rockerfel...@gmail.comwrote: Hi, I am pretty new to this concept and would appreciate any guidance on how as a customer I can achieve redundacy with autofailover between 2 ISPs. Can I achieve this when I have a /29 from ISP1 and do not have my own PI ips? All my services dns, email, wan are hosted by the ISP1. Any assistance on this will be appreciated. Rocker ___ 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] Multi Area OSPF
Nick, As soon as you redistribute from another protocol (connected, static included) into OSPF, that router then acts as an ASBR. According to both routers, that area will contain an ASBR and can therefore not be a stub. Cheers On 15 September 2010 11:32, Nick Ryce nick.r...@lumison.net wrote: Hi Guys, Im having some issues with setting up multi area ospf between a j 2320 and a cisco 1812. I have a funny feeling the issues will be user related. The j2320 is acting as an abr with backbone area 0.0.0.0 and stub area 0.0.0.1 and advertises a default route into the stub area. The 1812 is set as a stub with no other routing protocols being used. When I use the redistribute static or redistribute connected commands it advises these cant be used as the router is an asbr. The router is only running 1 ospf process for the stub area so I am not sure why this is occurring. I add the network x.x.x.x y.y.y.y area 0.0.0.1 command and can start seeing a default route being sent by the juniper which is great but the juniper cannot see anything being sent from the router. I can get around this by setting the network in the ospf process to 0.0.0.0 255.255.255.255 but is this the correct way to do this as it would mean that any interface on the router will be sending out ospf requests which I do not want to occur as I want to be specific. Any ideas? Nick -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. ___ 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] Multihoming
On 9/15/10 2:26 AM, Walter Keen wrote: Not many options for you I'm afraid. Some people filter out routes smaller than a /24. Even if you had a /24 from ISP1, you would then have to get their permission to have ISP2 advertise it. Most aren't willing to do this. Is a micro (/24) allocation from ARIN (if in the US) a possibility? If so, you could then run BGP to multiple providers and make this a very simple configuration. If not, you'll likely have to rely on application-layer redundancy. You can prioritize MX records if you are hosting your mail on-site through ISP1's ip addressing (what you stated seemed a bit unclear), and you could probably do some round-robin DNS entries for web hosting, but it won't be perfect. You can now get a /24 in ARIN land if you're an end user. https://www.arin.net/policy/proposals/2010_2.html ~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/
Re: [c-nsp] Multihoming
On Wed, 15 Sep 2010, Walter Keen wrote: Not many options for you I'm afraid. Some people filter out routes smaller than a /24. Even if you had a /24 from ISP1, you would then have to get their permission to have ISP2 advertise it. Most aren't willing to do this. Huh? Get a /24 from one of the ISPs. Get an ASN from ARIN or whoever is the appropriate registry for your area. Advertise (BGP) that /24 to both ISPs. I've never heard of an ISP not allowing this (except that most probably won't do BGP with you if you're on a low end connection like DSL/cable. If you have some sort of leased line or ethernet connectivity to each provider, it shouldn't be an issue. Is a micro (/24) allocation from ARIN (if in the US) a possibility? If so, you could then run BGP to multiple providers and make this a very simple configuration. If not, you'll likely have to rely on application-layer redundancy. You can prioritize MX records if you are hosting your mail on-site through ISP1's ip addressing (what you stated seemed a bit unclear), and you could probably do some round-robin DNS entries for web hosting, but it won't be perfect. Another option might be to get a small amount of space from each provider, and VPN into something more stable/better connected. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] Multihoming
On Wed, 15 Sep 2010, Voigt, Thomas wrote: Hi Rocker, Rocker Feller wrote: I am pretty new to this concept and would appreciate any guidance on how as a customer I can achieve redundacy with autofailover between 2 ISPs. You need PI space to do this. Because each ISP can only route his own PA spaces plus the PI spaces from his customers. You don't need PI space to multihome. At least not in the ARIN region. You do generally need at least a /24 if you want any reasonable chance of the internet accepting your BGP announcement. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] Multihoming
Jon there seems to be a bit of a common belief that advertising a /24 or some prefix that has been assigned by a provider, out to another provider, is bad practise. I don't get it either and haven't seen issues myself. The only scenario I can think of is (in some odd configurations) when the original provider sees part of their own network being advertised by another ISP, they filter it and it breaks connectivity, or the original provider's igp contains that prefix somehow already.. ? On 15 September 2010 16:17, Jon Lewis jle...@lewis.org wrote: On Wed, 15 Sep 2010, Voigt, Thomas wrote: Hi Rocker, Rocker Feller wrote: I am pretty new to this concept and would appreciate any guidance on how as a customer I can achieve redundacy with autofailover between 2 ISPs. You need PI space to do this. Because each ISP can only route his own PA spaces plus the PI spaces from his customers. You don't need PI space to multihome. At least not in the ARIN region. You do generally need at least a /24 if you want any reasonable chance of the internet accepting your BGP announcement. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] Multihoming
On Wed, 15 Sep 2010, Heath Jones wrote: Jon there seems to be a bit of a common belief that advertising a /24 or some prefix that has been assigned by a provider, out to another provider, is bad practise. I don't get it either and haven't seen issues myself. This is done quite a bit, as (again, I'm only familiar with practices in the ARIN region) this is basically the only way a small organization (ISP or end user) could multihome in the past. ARIN just adopted a policy allowing multihomed end users to get a PI /24. So that's an option now as well. The only scenario I can think of is (in some odd configurations) when the original provider sees part of their own network being advertised by another ISP, they filter it and it breaks connectivity, or the original provider's igp contains that prefix somehow already.. ? Ideally, both ISPs would be aware of your intentions to multihome and not be dumb enough to filter your announcement via the other ISP. It wouldn't surprise me if that sort of filtering has happened though. Of course, it wouldn't surprise me if your ISP broke your prefix filter, didn't use prefix filters, lost your interface config, assigned your interface /30 to another customer, or fundamentally altered your route-map (if they have one) such that they stopped accepting some of your routes. I've seen all these things happen. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] Conditional advertise-map
On Wed, Sep 15, 2010 at 5:38 PM, Heath Jones hj1...@gmail.com wrote: Richard, Is the arrangement that 36997 will provide a backup service for you, so its a last resort to pull traffic through them? If that is the case, have you tried prepending your advertisments towards 36997? Yes, arrangement is to you them as a fall back option. Prepend is what i intend to try now. Also, I can see from global bgp they are not peering with eachother so its not a situation where communities could help. The other solution is to advertise a supernet to 36997 and break this in half and advertise both subnets to 5511 (assuming you have a decent sized prefix /24). Can't do this because I have some customers downstream whose's prefixes I can't break up yet they insist that they only want to use the AS511 link. Perhaps you have already tried these solutions, or don't want to head that way, i'm not sure :) I'll check this one out actually (your advertise map) - its a good situation to lab up and try! If you are having problems because of the access lists trying to prevent re-advertisment of routes, you could tag them when they come in instead (add community), and filter them out on egress... Hope this helps. Thanks On 15 September 2010 09:08, Richard Mikisa rmik...@gmail.com wrote: Hi all, I have a scenario where I have two upstreams ASN5511 and ASN36997. Both do send me a default route and I choose ASN5511 as the best path. All my outbound traffic is via ASN5511 and the return is distributed between the two. What I want however is to use an advertise map so I ONLY advertise my prefixes to ASN5511 so I only use his link but fail-over to advertising my prefixes to ASN36997 in the event ASN5511 fails. I have created the the two route-maps to be matched NO_DEFAULT_FT and AS_LIST and configured as below. ## access list below is to avoid me feeding back to my up-streams the routes learned from other up-streams. That way I only advertise to the up-streams only prefixes from me and my down-streams. ip as-path access-list 10 deny ^5511_ ip as-path access-list 10 deny ^12455_ ip as-path access-list 10 deny ^36997_ ip as-path access-list 10 permit .* !! ## Match against filter below. If anything from ASN5511 is available, ip as-path access-list 20 permit ^5511_ !! route-map NO_DEFAULT_FT permit 10 match as-path 20 !! route-map AS_LIST permit 10 match as-path 10 !! neighbor 41.222.1.33 advertise-map AS_LIST non-exist-map NO_DEFAULT_FT Any ideas why it doesn't work. PS. Am working on drawing :) -- cheers Richard ___ 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/ -- cheers Richard ___ 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] Multihoming
I currently do this for one of my sites and haven't had any issues. You just get a LOA from the ISP you get your /24 from and send it to the other ISP. Easy Peasy. On Wed, Sep 15, 2010 at 10:30 AM, Heath Jones hj1...@gmail.com wrote: Jon there seems to be a bit of a common belief that advertising a /24 or some prefix that has been assigned by a provider, out to another provider, is bad practise. I don't get it either and haven't seen issues myself. The only scenario I can think of is (in some odd configurations) when the original provider sees part of their own network being advertised by another ISP, they filter it and it breaks connectivity, or the original provider's igp contains that prefix somehow already.. ? On 15 September 2010 16:17, Jon Lewis jle...@lewis.org wrote: On Wed, 15 Sep 2010, Voigt, Thomas wrote: Hi Rocker, Rocker Feller wrote: I am pretty new to this concept and would appreciate any guidance on how as a customer I can achieve redundacy with autofailover between 2 ISPs. You need PI space to do this. Because each ISP can only route his own PA spaces plus the PI spaces from his customers. You don't need PI space to multihome. At least not in the ARIN region. You do generally need at least a /24 if you want any reasonable chance of the internet accepting your BGP announcement. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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-...@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] Conditional advertise-map
Hi, On Wed, Sep 15, 2010 at 03:38:17PM +0100, Heath Jones wrote: Also, I can see from global bgp they are not peering with eachother so its not a situation where communities could help. If 36997 would offer a make it worse than peering/upstream community, of course it would help. The other solution is to advertise a supernet to 36997 and break this in half and advertise both subnets to 5511 (assuming you have a decent sized prefix /24). If you had to pay the money for the router upgrades just to handle the ever-growing BGP tables, I bet you were more careful about suggesting deaggregation... 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 pgpLjgFNNNe3B.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] Multihoming
It looks like this subject has been beat to death so I'll skip the usual about obtaining a /24 form ARIN and a public ASN. Global load-balancing is an option as it allows you to fail over your DNS entries to the second providers IP space. This pretty much negates the need for BGP if all you were using it for was failover. There are also companies that offer global load-balancing as a service so you don't have to worry about managing the box itself. It's DNS based so the load-balancer itself can be anywhere in the world technically. Redundancy is usually taken care of as well. ___ 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] Multihoming
One last comment. There are alot of people suggesting that you find a way to advertise the /29 to the other ISP. This is not possible. The ISP that gave it to you probably isn't willing to de-aggregate it when sending it to the internet and the ISP that needs to accept it probably doesn't accept blocks under a certain size to keep their routing table sizes under control. If you look at a route server in another AS you'll probably only see a /21 or better that contains your block. ISP's normally advertise aggregates only unless the customer was assigned a large block (/24 or better for most) and requested that they do so. Then they advertise both. On Wed, Sep 15, 2010 at 12:30 PM, Keegan Holley keegan.hol...@sungard.comwrote: It looks like this subject has been beat to death so I'll skip the usual about obtaining a /24 form ARIN and a public ASN. Global load-balancing is an option as it allows you to fail over your DNS entries to the second providers IP space. This pretty much negates the need for BGP if all you were using it for was failover. There are also companies that offer global load-balancing as a service so you don't have to worry about managing the box itself. It's DNS based so the load-balancer itself can be anywhere in the world technically. Redundancy is usually taken care of as well. ___ 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] strange vlan issue
Hi All, I'm really puzzled by a switch that has stopped working on one vlan only. This switch has vlans 1 and 2. vlan 1 no longer will pass traffic. I can't even ping out to it's gateway from the switch, but you can ping the switch from it's gateway. A show cdp nei shows what it is connected to. I have replaced the cable and switched to different ports with no luck. I have never seen an issue where a switch will just stop passing traffic on 1 vlan. We replaced the switch and all is fine, so just want to know if someone else has seen this issue before. The switch is a 2950. It has been in service and running flawlessly with the same config since November of 2002. Thanks, Lee ___ 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] Multihoming
Another option might be to get a small amount of space from each provider, and VPN into something more stable/better connected. Something I've been considering is to have the customer build a GRE tunnel (its Internet traffic anyway) back to our router over their other ISP's connection. We could then route their public IP space over either connection. It doesn't give all the same benefits of BGP (for example, if something happens to my AS or router, the customer is screwed), but it should make for cheap and easy multihoming. Anybody have any thoughts on this? Tim Huffman Director of Engineering BOB - Business Only Broadband, LLC O (630) 590-6012 C (630) 340-1925 t...@bobbroadband.com www.bobbroadband.com -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jon Lewis Sent: Wednesday, September 15, 2010 10:15 AM To: Walter Keen Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Multihoming On Wed, 15 Sep 2010, Walter Keen wrote: Not many options for you I'm afraid. Some people filter out routes smaller than a /24. Even if you had a /24 from ISP1, you would then have to get their permission to have ISP2 advertise it. Most aren't willing to do this. Huh? Get a /24 from one of the ISPs. Get an ASN from ARIN or whoever is the appropriate registry for your area. Advertise (BGP) that /24 to both ISPs. I've never heard of an ISP not allowing this (except that most probably won't do BGP with you if you're on a low end connection like DSL/cable. If you have some sort of leased line or ethernet connectivity to each provider, it shouldn't be an issue. Is a micro (/24) allocation from ARIN (if in the US) a possibility? If so, you could then run BGP to multiple providers and make this a very simple configuration. If not, you'll likely have to rely on application-layer redundancy. You can prioritize MX records if you are hosting your mail on-site through ISP1's ip addressing (what you stated seemed a bit unclear), and you could probably do some round-robin DNS entries for web hosting, but it won't be perfect. Another option might be to get a small amount of space from each provider, and VPN into something more stable/better connected. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] Multihoming
Yeah it would work - 2 tunnels and routing done on your side.. Problem is increased latency, jitter and lack of QOS, but for data traffic / backup / something else that needs redundancy it should be ok. You could provide managed firewalls etc etc for them - it's a product if thats what your asking.. ;) On 15 September 2010 17:42, Tim Huffman t...@bobbroadband.com wrote: Another option might be to get a small amount of space from each provider, and VPN into something more stable/better connected. Something I've been considering is to have the customer build a GRE tunnel (its Internet traffic anyway) back to our router over their other ISP's connection. We could then route their public IP space over either connection. It doesn't give all the same benefits of BGP (for example, if something happens to my AS or router, the customer is screwed), but it should make for cheap and easy multihoming. Anybody have any thoughts on this? Tim Huffman Director of Engineering BOB - Business Only Broadband, LLC O (630) 590-6012 C (630) 340-1925 t...@bobbroadband.com www.bobbroadband.com -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of Jon Lewis Sent: Wednesday, September 15, 2010 10:15 AM To: Walter Keen Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Multihoming On Wed, 15 Sep 2010, Walter Keen wrote: Not many options for you I'm afraid. Some people filter out routes smaller than a /24. Even if you had a /24 from ISP1, you would then have to get their permission to have ISP2 advertise it. Most aren't willing to do this. Huh? Get a /24 from one of the ISPs. Get an ASN from ARIN or whoever is the appropriate registry for your area. Advertise (BGP) that /24 to both ISPs. I've never heard of an ISP not allowing this (except that most probably won't do BGP with you if you're on a low end connection like DSL/cable. If you have some sort of leased line or ethernet connectivity to each provider, it shouldn't be an issue. Is a micro (/24) allocation from ARIN (if in the US) a possibility? If so, you could then run BGP to multiple providers and make this a very simple configuration. If not, you'll likely have to rely on application-layer redundancy. You can prioritize MX records if you are hosting your mail on-site through ISP1's ip addressing (what you stated seemed a bit unclear), and you could probably do some round-robin DNS entries for web hosting, but it won't be perfect. Another option might be to get a small amount of space from each provider, and VPN into something more stable/better connected. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] Conditional advertise-map
I thought you'd say that... There is absolutely *NO* reason why an additional entry needs to occupy space in TCAM in this case. If you have 2 contiguous prefixes that can be directly aggregated to a single prefix on the next subnet boundary, and that share the same next-stage-treatment (egress, queueing etc), they can take up only 1 spot. If a router isn't preprocessing routing information before it goes to the forwarding plane, then its not efficiently using the expensive resources.. I get your point about the bgp table size, but i'm not suggesting he breaks a /16 into /24's or something... Please keep that in mind! I am well aware of the point you are making, but still believe that my suggestion is a viable solution to the problem. Oh, and for the record, it would change from 1 prefix into 3, not into 2 like i suggested before (my fault). On 15 September 2010 18:28, Gert Doering g...@greenie.muc.de wrote: Hi, On Wed, Sep 15, 2010 at 05:55:24PM +0100, Heath Jones wrote: You will probably find that the as path prepending will chew more memory than 1 more prefix matching an existing as path so the subnetting option works out better. To the contrary. Different AS paths are just DRAM. Every additional prefix is forwarding memory, read: limited and very expensive TCAM (or SRAM or whatever). [Lower-end routers have BGP tables and forwarding tables in the same DRAM memory, so there it's just DRAM, but for higher-end, the forwarding tables go to hardware memory] just not cricket. I'm just trying to help him out with some suggestions. It would turn 1 prefix into 2 - thats hardly unreasonable.. Right now, about half(!) of the global routing table is deaggregates. If those people would all aggregate properly, the routing table would still fit into non-XL TCAMs - for us alone (and we're a small ISP) that would have saved about 150.000 US$ in not-yet-needed TCAM upgrades. It *does* matter. 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-35655025 g...@net.informatik.tu-muenchen.de ___ 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] Conditional advertise-map
Hi, On Wed, Sep 15, 2010 at 06:38:26PM +0100, Heath Jones wrote: I thought you'd say that... There is absolutely *NO* reason why an additional entry needs to occupy space in TCAM in this case. If you have 2 contiguous prefixes that can be directly aggregated to a single prefix on the next subnet boundary, and that share the same next-stage-treatment (egress, queueing etc), they can take up only 1 spot. If a router isn't preprocessing routing information before it goes to the forwarding plane, then its not efficiently using the expensive resources.. Well, the theory agrees with you. Unfortunately, routers out there in the market (and remember, this is *cisco*-nsp) don't do this. I have asked for it for a number of times, but it's a tricky problem (like: you have a /16 that encompasses 256 /24, the RIB barely fits into the FIB space, and then the /16 goes away - 253 extra FIB entries needed - non-deterministic boom) *and* Cisco has no commercial interest in spending lots of engineering effort to the goal of selling *less* expensive hardware... 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 pgpSF27YCaWPA.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] strange vlan issue
Lee Starnes wrote: Hi All, I'm really puzzled by a switch that has stopped working on one vlan only. This switch has vlans 1 and 2. vlan 1 no longer will pass traffic. I can't even ping out to it's gateway from the switch, but you can ping the switch from it's gateway. A show cdp nei shows what it is connected to. I have replaced the cable and switched to different ports with no luck. I have never seen an issue where a switch will just stop passing traffic on 1 vlan. We replaced the switch and all is fine, so just want to know if someone else has seen this issue before. The switch is a 2950. It has been in service and running flawlessly with the same config since November of 2002. Post the config here and lets take a look. ___ 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] Conditional advertise-map
On Wed, 2010-09-15 at 18:38 +0100, Heath Jones wrote: There is absolutely *NO* reason why an additional entry needs to occupy space in TCAM in this case. No reason at all? Are there any examples of this kind of TCAM compression being used out in the wild? On carrier grade equipment? Though not a logical extension, I propose that if it doesn't exists even though it's widely understood there must be some reason for that. Deaggregation is bad, m-kay? :-D -- 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] Conditional advertise-map
Carrier grade equipment means nothing more than heavy metal boxes containing fast interfaces, lots of bugs and a hefty price tag. The only reason it works is because of the number of users ironing out all the bugs over time in post-production. Keep in mind that every vendor will want to charge 100% price for 0% product. Actually, thats every company in general. The point is that 'carrier grade' is a bullshit term that just means expensive. Perhaps I'm being a little pessimistic, but with the problems I've seen on carrier networks, its a joke really.. I'd love to hear some technical reasons why this cannot / is not / will not be done. I think its a good idea, clearly a number of people have had it. On 15 September 2010 19:00, Peter Rathlev pe...@rathlev.dk wrote: On Wed, 2010-09-15 at 18:38 +0100, Heath Jones wrote: There is absolutely *NO* reason why an additional entry needs to occupy space in TCAM in this case. No reason at all? Are there any examples of this kind of TCAM compression being used out in the wild? On carrier grade equipment? Though not a logical extension, I propose that if it doesn't exists even though it's widely understood there must be some reason for that. Deaggregation is bad, m-kay? :-D -- 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] Conditional advertise-map
On Wed, 2010-09-15 at 19:23 +0100, Heath Jones wrote: Carrier grade equipment means nothing more than heavy metal boxes containing fast interfaces, [...] I didn't reveal what I imply by carrier grade, and I certainly would not imply stable or works as advertised as being natural candidates. :-) By carrier grade I meant equipment performing hardware forwarding, thus giving certain guaranteed limits for processing delay. I'm not sure carrier grade is that good a term though, hence the quotation marks. I don't work at a carrier or even an ISP. We're just an enterprise, government healthcare in DK. We still need and use hardware forwarding devices though. I'd love to hear some technical reasons why this cannot / is not / will not be done. I think its a good idea, clearly a number of people have had it. To quote Lincoln Dale from Cisco: it gets nondeterministic very very quickly and does not scale from a control plane perspective.. Take a look at http://www.mail-archive.com/cisco-nsp@puck.nether.net/msg29079.html -- 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] strange vlan issue
Did you see if the switch had the correct MAC address for it's default gateway? Reboot the switch before replacing it? It's been a long time, but I've seen things like that after replacing a router - the switch refused to learn the new mac address for the default gateway. Lee On 9/15/10, Lee Starnes lee.t.star...@gmail.com wrote: Hi All, I'm really puzzled by a switch that has stopped working on one vlan only. This switch has vlans 1 and 2. vlan 1 no longer will pass traffic. I can't even ping out to it's gateway from the switch, but you can ping the switch from it's gateway. A show cdp nei shows what it is connected to. I have replaced the cable and switched to different ports with no luck. I have never seen an issue where a switch will just stop passing traffic on 1 vlan. We replaced the switch and all is fine, so just want to know if someone else has seen this issue before. The switch is a 2950. It has been in service and running flawlessly with the same config since November of 2002. Thanks, Lee ___ 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] Conditional advertise-map
Cheers for the link, there seems to be a fair bit about this on rrg mailing list.. I don't quite know if he is talking about the same method though. A lot of what i'm reading over there is talking about very non-deterministic methods. There's a few ideas floating around thats for sure! On 15 September 2010 19:33, Peter Rathlev pe...@rathlev.dk wrote: On Wed, 2010-09-15 at 19:23 +0100, Heath Jones wrote: Carrier grade equipment means nothing more than heavy metal boxes containing fast interfaces, [...] I didn't reveal what I imply by carrier grade, and I certainly would not imply stable or works as advertised as being natural candidates. :-) By carrier grade I meant equipment performing hardware forwarding, thus giving certain guaranteed limits for processing delay. I'm not sure carrier grade is that good a term though, hence the quotation marks. I don't work at a carrier or even an ISP. We're just an enterprise, government healthcare in DK. We still need and use hardware forwarding devices though. I'd love to hear some technical reasons why this cannot / is not / will not be done. I think its a good idea, clearly a number of people have had it. To quote Lincoln Dale from Cisco: it gets nondeterministic very very quickly and does not scale from a control plane perspective.. Take a look at http://www.mail-archive.com/cisco-nsp@puck.nether.net/msg29079.html -- 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] strange vlan issue
I had similar problem a year ago. two 7609/SUP720 trunked together with 20-30 VLAN's one vlan (vlan 800 or close to 800) running one of the important BGP sessions refused any traffic Removed all vlan 800 config, reapplied back without success. Reload was not an option. changed to vlan 900, everything OK. To your problem with 2950: Did anything change around this switch? Connected switches? DTP, VTP, port security, duplex? Jon Fra: cisco-nsp-boun...@puck.nether.net [cisco-nsp-boun...@puck.nether.net] p#229; vegne av Lee Starnes [lee.t.star...@gmail.com] Sendt: 15. september 2010 18:44 Til: cisco-nsp@puck.nether.net Emne: [c-nsp] strange vlan issue Hi All, I'm really puzzled by a switch that has stopped working on one vlan only. This switch has vlans 1 and 2. vlan 1 no longer will pass traffic. I can't even ping out to it's gateway from the switch, but you can ping the switch from it's gateway. A show cdp nei shows what it is connected to. I have replaced the cable and switched to different ports with no luck. I have never seen an issue where a switch will just stop passing traffic on 1 vlan. We replaced the switch and all is fine, so just want to know if someone else has seen this issue before. The switch is a 2950. It has been in service and running flawlessly with the same config since November of 2002. Thanks, Lee ___ 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] Multihoming
Sent from my iPhone On 15.09.2010, at 18:42, Tim Huffman t...@bobbroadband.com wrote: Something I've been considering is to have the customer build a GRE tunnel (its Internet traffic anyway) back to our router over their other ISP's connection. We could then route their public IP space over either connection. You will probably have a lot of problems with Path MTU discovery. Andree ___ 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] Feedback on upcoming removal of FTP access to secured software
On Tue, 14 Sep 2010 21:13:35 +0100, you wrote: It's also looks like Cisco may be vaguely moving in the direction of locking CCO accounts down to be able to access only software downloads for which there are active smartnet contracts. Active service contracts, yes that's what they're doing. (They have informed us partners). It doesn't have to be SMARTnet contracts, though. -A ___ 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] Feedback on upcoming removal of FTP access to secured software
On Sep 15, 2010, at 4:32 PM, Asbjorn Hojmark - Lists wrote: On Tue, 14 Sep 2010 21:13:35 +0100, you wrote: It's also looks like Cisco may be vaguely moving in the direction of locking CCO accounts down to be able to access only software downloads for which there are active smartnet contracts. Active service contracts, yes that's what they're doing. (They have informed us partners). It doesn't have to be SMARTnet contracts, though. My favorite errors are when downloading software updates for EVAL gear it warns me that I'm a software thief. While I don't dispute that this happens, it's frustrating that the process is going further down this path, it's going to make me grumpier as I deal with them as a vendor. - Jared ___ 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] Feedback on upcoming removal of FTP access to secured software
On 9/15/2010 13:32, Asbjorn Hojmark - Lists wrote: On Tue, 14 Sep 2010 21:13:35 +0100, you wrote: It's also looks like Cisco may be vaguely moving in the direction of locking CCO accounts down to be able to access only software downloads for which there are active smartnet contracts. Active service contracts, yes that's what they're doing. (They have informed us partners). It doesn't have to be SMARTnet contracts, though. How would this work for old unsupported equipment? ~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/
Re: [c-nsp] Multi Area OSPF
On Wed, 15 Sep 2010 11:32:05 +0100, you wrote: The 1812 is set as a stub with no other routing protocols being used. When I use the redistribute static or redistribute connected commands it advises these cant be used as the router is an asbr. The router is only running 1 ospf process for the stub area so I am not sure why this is occurring. Don't redistribute into the area. Just use network statements for the connected networks that you want the router to advertise into the area. If you need to redistribute something into the area (including static routes), you're using the wrong area type. -A ___ 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] Feedback on upcoming removal of FTP access to secured software
On Wed, 2010-09-15 at 22:32 +0200, Asbjorn Hojmark - Lists wrote: On Tue, 14 Sep 2010 21:13:35 +0100, you wrote: It's also looks like Cisco may be vaguely moving in the direction of locking CCO accounts down to be able to access only software downloads for which there are active smartnet contracts. Active service contracts, yes that's what they're doing. (They have informed us partners). It doesn't have to be SMARTnet contracts, though. With the new lifetime upgrades thingy for the small Catalyst devices there would be no need to restrict access to the basic feature images (IP Base for 3560 et cetera). I would even go so far as to say that restricting access to that software (unless legally obliged) would mean that they're lying about these lifetime upgrades. (They might very well no restrict access to just that kind of software, I haven't bothered to check.) I still don't understand why Cisco would do this. Is pirated Cisco software really that big an economic problem for them? Aren't most if not all of their big customers already in compliance anyway? Personally I imagine that thieving of Cisco software mostly happens when amatuers (no offense meant) get their hands on some piece of laid off hardware. -- 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] Feedback on upcoming removal of FTP access to secured software
On Wed, 2010-09-15 at 13:43 -0700, Seth Mattinen wrote: On 9/15/2010 13:32, Asbjorn Hojmark - Lists wrote: Active service contracts, yes that's what they're doing. (They have informed us partners). It doesn't have to be SMARTnet contracts, though. How would this work for old unsupported equipment? They'll sell you a nice warm IBLM report, convincing you to buy loads of new-and-improved[0] equipment to replace you old malfunctioning[1] equipment. And the report is free[2]. -- Peter [0]: new-and-improved in this context means more expensive, more buggy software and less built-in features. And smaller buffers. [1]: malfunctioning in this context means proven design with well-known failure modes and failure frequencies that does what it's supposed to do. [2]: Except you have to pay for them to actually make the report. (I havn't figured out what the free thing is then.) ___ 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] Feedback on upcoming removal of FTP access to secured software
Hi, On Wed, Sep 15, 2010 at 01:43:46PM -0700, Seth Mattinen wrote: How would this work for old unsupported equipment? For security updates, you can go through TAC, and get the updates even if you have no contract. If there's neither a convenient security update nor a contract, then it's getting interesting - theoretically, you can buy IOS updates. In practice, nearly no cisco partner/reseller seems to understand *how* to do that. At some time in the past, we bought 12.0 for all our routers (then ip-only, for something like 23 EUR/box, but we wanted to do it properly), and it was an interesting excercise. 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 pgpnh0Kq7LcjY.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] Feedback on upcoming removal of FTP access to secured software
On 2010-09-15 23:05, Peter Rathlev wrote: And the report is free[2]. [2]: Except you have to pay for them to actually make the report. (I havn't figured out what the free thing is then.) The report IS free. You're propably being charged by a Partner. One way or another, if anyone is willing to charge you for it, please contact Your account team at Cisco to sort this out. -- Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net ___ 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] Feedback on upcoming removal of FTP access to secured software
On 2010-09-15 23:05, Gert Doering wrote: If there's neither a convenient security update nor a contract, then it's getting interesting - theoretically, you can buy IOS updates. In practice, nearly no cisco partner/reseller seems to understand *how* to do that. At some time in the past, we bought 12.0 for all our routers (then ip-only, for something like 23 EUR/box, but we wanted to do it properly), and it was an interesting excercise. You buy a CD with specific feature-set on them as a spare P/N (CDxx[platform-feature-set]=), however there's no guarantee short of unpacking and checking what specific version will be there on the CDs. The trick is - if you don't have contract, the software on the CD is the only version you can use, and there's no bundled CCO account you can use to download newer/older versions. So, it's makes more sense to have a contract because you get freedom to download specific version/newer versions in the future *and* TAC/hardware support (unless the hardware support is covered by the specific service the box is covered already). That's not always possible, as there's no option to buy a contract for a box that is already EoS. -- Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net ___ 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] Feedback on upcoming removal of FTP access to secured software
On Wed, 2010-09-15 at 23:20 +0200, Łukasz Bromirski wrote: On 2010-09-15 23:05, Peter Rathlev wrote: And the report is free[2]. [2]: Except you have to pay for them to actually make the report. (I havn't figured out what the free thing is then.) The report IS free. You're propably being charged by a Partner. That is correct. The partner charged. One way or another, if anyone is willing to charge you for it, please contact Your account team at Cisco to sort this out. We've done exactly that. We've now been more or less promised (although not formally/written) by our AM that he'll try to get Cisco Advanced Services to perform an enterprise wide IBLM. But: He says that even when AS performs the IBLM, we still have to pay. We can get a refund when purchasing new equipment later, but still have to pay up front. We were told that there's no way we can escape paying for the junior technician that pushes the button. (And in one place they charged for *30* man hours to enter the same SNMPv2 community on ~80 devices. Talk about slow typing!) Are they pulling our legs? -- 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] Conditional advertise-map
Gert, You've got me thinking about this whole non-determinism thing and something just entered my brain.. The debates here and on other threads seem to be based on the notion that aggregating prefixes in tcam becomes non-deterministic due to not being able to guarantee future # of tcam prefixes if the topology changes. Does that mean that people think routing is completely deterministic now, and that we can guarantee noone will go and advertise a shitload of /24's? Or, does it mean that people think its more likely for a topology change to affect the aggregation in a tcam because the egress interface will change? It seems probability comes into play here, but my gut feeling is that very few networks would run into any real issues with tcam aggregation. Perhaps that is enough from me on the subject - I don't want to spam the thread if people aren't interested in this stuff.. Please do let me know your thoughts either on here or directly! Cheers Heath On 15 September 2010 18:43, Gert Doering g...@greenie.muc.de wrote: Hi, On Wed, Sep 15, 2010 at 06:38:26PM +0100, Heath Jones wrote: I thought you'd say that... There is absolutely *NO* reason why an additional entry needs to occupy space in TCAM in this case. If you have 2 contiguous prefixes that can be directly aggregated to a single prefix on the next subnet boundary, and that share the same next-stage-treatment (egress, queueing etc), they can take up only 1 spot. If a router isn't preprocessing routing information before it goes to the forwarding plane, then its not efficiently using the expensive resources.. Well, the theory agrees with you. Unfortunately, routers out there in the market (and remember, this is *cisco*-nsp) don't do this. I have asked for it for a number of times, but it's a tricky problem (like: you have a /16 that encompasses 256 /24, the RIB barely fits into the FIB space, and then the /16 goes away - 253 extra FIB entries needed - non-deterministic boom) *and* Cisco has no commercial interest in spending lots of engineering effort to the goal of selling *less* expensive hardware... 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-35655025 g...@net.informatik.tu-muenchen.de ___ 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] Feedback on upcoming removal of FTP access to secured software
...theres always the CCIE option for CCO download access...or are they getting rid of that too? :-( alan ___ 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] Feedback on upcoming removal of FTP access to secured software
Hi, But: He says that even when AS performs the IBLM, we still have to pay. We can get a refund when purchasing new equipment later, but still have to pay up front. given that the IBLM is nothing more than a method by which service partners can gain excellent visibility into your customer network and initiate deeper and broader customer conversations - I'm quoting cisco here - its not do do with them caring about you...its to do with them getting you to buy more stuff. now, given that a lot of their competitors are able to put all the features onto much older kit...but everytime you want a new feature you have to buy new kit...we'll its making peers in this community think about the future and what they might buy next time. also, to charge for this? hello? theres plenty of free tools out there that can make an inventory of a companies network...given enough information and seeding. most of these tools are now available as virtual images to make the task a little easier too. alan ___ 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] Feedback on upcoming removal of FTP access to secured software
On 2010-09-16 00:04, Peter Rathlev wrote: The report IS free. You're propably being charged by a Partner. That is correct. The partner charged. That's of course doable - Cisco can't forbid Partner to ask for money for the work they're putting into sending some engineer to do the work. However, usually partner is including the fee for the work engineer did in future purcharses. We've done exactly that. We've now been more or less promised (although not formally/written) by our AM that he'll try to get Cisco Advanced Services to perform an enterprise wide IBLM. Well, sure, AS can also do what IBLM can do and even better, they can generate other interesting reports that IBLM tool can't generate, but this is completely another service. We were told that there's no way we can escape paying for the junior technician that pushes the button. (And in one place they charged for *30* man hours to enter the same SNMPv2 community on ~80 devices. Talk about slow typing!) Well, find another Partner. If you're satisfied with the current one, negotiate. One way or another, they will propably have to count in the SE work hours into the potential order - and either you won't be able to see it, or they'll show it as a separate line quoting X$ which may or may not be satisfactory for you (negotiations time). The truth is, partners (Gold/Silver) are actually given additional discount if they qualified for AIP program, so they can easily use that money to pay for their own work onsite at the time of IBLM: http://www.cisco.com/web/offer/channel/channel_services/16804/11/Next_Wave_CDS_Launch_Presentation_PF01.pdf At take a look here for the Partner site detailing the program: http://www.cisco.com/web/europe/partners/sales/IBLM/index.html -- Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net ___ 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] Feedback on upcoming removal of FTP access to secured software
On 2010-09-16 00:38, Alan Buxey wrote: also, to charge for this? hello? theres plenty of free tools out there that can make an inventory of a companies network...given enough information and seeding. most of these tools are now available as virtual images to make the task a little easier too. The IBLM report automates the work that could potentially take a number of days to complete - it shows given specific hardware P/N and software running on the box if it's still in sale or reached some milestone - EoS/EoL/EoE. No open source software I know of would generate such report, as it would need to cross-check the contents of some of the tools CCO provides. IBLM tool uses internal database that drives those tools that are customer-facing. Is it a sales tool? Yes it is. The additional value it brings would however need somebody else to do the work, and the IBLM by itself doesn't require signing 'future potential contract' with your blood. -- Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net ___ 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] Feedback on upcoming removal of FTP access to secured software
Just wondering.. Does IBLM access some generic(ish) webservice back to base (cisco) for updates to the EoL/S etc? What if the address of that could make its way around... 2010/9/15 Łukasz Bromirski luk...@bromirski.net On 2010-09-16 00:38, Alan Buxey wrote: also, to charge for this? hello? theres plenty of free tools out there that can make an inventory of a companies network...given enough information and seeding. most of these tools are now available as virtual images to make the task a little easier too. The IBLM report automates the work that could potentially take a number of days to complete - it shows given specific hardware P/N and software running on the box if it's still in sale or reached some milestone - EoS/EoL/EoE. No open source software I know of would generate such report, as it would need to cross-check the contents of some of the tools CCO provides. IBLM tool uses internal database that drives those tools that are customer-facing. Is it a sales tool? Yes it is. The additional value it brings would however need somebody else to do the work, and the IBLM by itself doesn't require signing 'future potential contract' with your blood. -- Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net ___ 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] Conditional advertise-map
Heath, All, On Sep 15, 2010, at 12:13 MDT, Heath Jones wrote: I completely agree with the problem of tcam overflow if an aggregated prefix dissapears! I did overlook that though, thanks for pointing it out! I think it is still certainly an advantage to do aggregation pre-tcam. We are only better off than where we are now. Even if the FIB gets hammered because of some change on the wider internet (if the tcam overflows), it could revert to software forwarding for some prefixes / catchall type arrangement. Obviously the selection of prefixes to catch in software is important... I wonder if someone has modelled this - see just how much aggregation could realistically be done at each AS. I'd imagine its similar to the info you got about 1/2ish of the prefixes out there being deaggregates..? In the past couple years, there has been a couple of IETF drafts and discussion, mostly in GROW, regarding FIB aggregation methods and associated modeling by research folks. At the last IETF, the following was presented at GROW: http://www.ietf.org/proceedings/78/slides/grow-2/grow-2.htm http://tools.ietf.org/html/draft-uzmi-smalta-00 As the slides above note, this is building upon an earlier draft presented at IETF 76: https://www.ietf.org/proceedings/76/slides/grow-2.pdf (I'm not sure why this PDF is missing the content in most slides. It's likely a bug when the slides were auto-converted from PPT to PDF. Unfortunately, I don't know where to get a copy of the slides without the missing content). http://tools.ietf.org/html/draft-zhang-fibaggregation-02 The nice thing is the research folks have put thought into various levels of FIB compression that could potentially be achieved. (I, for one, am very grateful for their efforts). The various levels of FIB compression allow one to achieve more optimal compression at the expense of additional CPU consumption and, more concerning, at the higher levels of FIB compression (level 3 and level 4 in draft-zhang) introduction of artificial aggregates (a.k.a.: whiteholing) that could, under certain conditions, introduce routing/forwarding loops, attraction/routing of additional traffic that otherwise would get dropped, etc. Most importantly, the research folks have spent some time doing theoretical modeling to characterize the amount of compression that could be achieved at each level (see drafts/slides for details). In addition, particularly with the SMALTA work, they've looked at how to optimize their compression algorithms to (try to) efficiently maintain a fully optimized! , compressed FIB while, all the while, dealing with incoming routing updates (prefixes, aggregates, etc.) appearing and disappearing. Better still, the SMALTA folks are not introducing additional aggregates and, according to their model, they were able to stay within 1% to 6% of a one-shot, fully optimized compressed FIB. IMHO, the SMALTA draft appears to be one of the more promising avenues. The one challenge is, of course, these are just theoretical models (likely good ones), but theoretical models with associated assumptions nonetheless -- IOW, it would be *very* interesting to take this work a step further and actually hook this up to a live, production network and document those results, but I'm unaware of any efforts to do that. In summary, don't give up hope that this is completely intractable problem quite yet. And, if anything, press your vendors to read those drafts and understand the simulation models results and, if possible, explain why this doesn't work or, failing that, why they haven't implemented it, yet. :-) -shane ___ 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/
