[c-nsp] 7609 DHCP alternatives - EVC / Subinterfaces
Hi All I am trying to test DHCP functionality with 7600 router. Traffic arrives from all customer facing interfaces (ES+), arrive using the same VLAN. 7600 perfoms DHCP relay and acts as a gateway for all of them. With the new cards ES+ we have two options for the configuration of customer facing interfaces 1. Using EVC + SVI interface int g4/1 service instance 100 ethernet encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric bridge-domain 100 split-horizon int g4/2 service instance 100 ethernet encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric bridge-domain 100 split-horizon int Vlan 100 ip address 10.0.0.1 255.255.255.0 ip helper address 192.168.0.1 2. Using IP subinterfaces int loopback 100 ip address 10.0.0.1 255.255.255.0 int g4/1.100 encapsulation dot1q 100 ip address unnumbered loopback 100 ip helper address 192.168.0.1 int g4/2.100 encapsulation dot1q 100 ip address unnumbered loopback 100 ip helper address 192.168.0.1 Both configurations seem to achieve the same effect but I am not sure which one is the preferable for large amount of traffic / subscribers. For example due to the bridge domain I would expect that the first alternative will create more entries in the mac-address table. Thanx Victor ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ip sla question
On Mon, 2009-10-19 at 15:33 -0700, Alex Wa wrote: Why do we need to specify dst-port as in ip sla 1 udp-jitter dest-ip DEST-PORT even when the ip sla responder doen't have one particular port where it listens to? If you only enable ip sla responder the query device uses control packets to enable the port you specify on the receiving device. If you specify a port on the receiving device (e.g. ip sla responder udp-echo port 65500) you can run SLA probes without control packets from the query device: ip sla 1 udp-echo 10.0.0.1 65500 control disable ! So the port is always used, but the IP SLA control packets tells the receiving device to listen on the specific port before the probe is sent. -- 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] Xconnect on Portchannel interface [EoMPLS]
On Fri, 16 Oct 2009, Marko Milivojevic wrote: Hello. 2009/10/16 Lukasz Trabinski luk...@trabinski.net: Hello I have problem with xconnect on portchannel interface. [...] How to do xconnect from untagged portchanel interface? Have you tried disabling LACP on the EC interface and have it statically configured (mode on)? Yes, it's works but only from cisco side. On other side of port-chanell we have Force10 device and when I configure mode on, I have port-channel UP. on cisco device, but down on Force10. The question is, why it's works when xconnect is configured on subinterface with tagged vlan? Maybe is it conflict with LACP/MPLS signalization? ___ cisco-nsp 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] Xconnect on Portchannel interface [EoMPLS]
Yes, it's works but only from cisco side. On other side of port-chanell we have Force10 device and when I configure mode on, I have port-channel UP. on cisco device, but down on Force10. The question is, why it's works when xconnect is configured on subinterface with tagged vlan? Maybe is it conflict with LACP/MPLS signalization? I had another thought after my original reply, but for some reason I didn't send you follow-up. Have you tried not enabling EC on Cisco doing xconnect (PE) at all and simply having it just on end-nodes: A===PE1---PE2===B Enable EC just on A and B and do simple xconnect from all interfaces on PE1 and PE2? My knowledge is very rusty, but it could be that LACP will be carried over in port mode. -- Marko CCIE #18427 (SP) My network blog: http://cisco.markom.info/ ___ cisco-nsp 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] DWDM optics on 6500s
Thanks. I assume that even though the 6509-V-E is available, until the 80gig line cards and Sup are available, you'd be stuck at 40gig/slot? Chuck -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tony Varriale Sent: Monday, October 19, 2009 5:07 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] DWDM optics on 6500s It will shortly but it won't do you any good with the existing family of sups. The 2T will be the first (and last?) sup that can push the bandwidth to all those slots. You can also reference the 6509-V-E...it's ready for 80gbps/slot. You can order that today. Note that it's a NEBS chassis. tv - Original Message - From: Church, Charles cchur...@harris.com To: Kevin Graham kgra...@industrial-marshmallow.com Cc: cisco-nsp@puck.nether.net Sent: Monday, October 19, 2009 1:12 PM Subject: Re: [c-nsp] DWDM optics on 6500s Are you saying a 6513-E chassis exists? I can't find any reference to it. That would solve a few of the problems we currently have (density issue) Chuck -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Kevin Graham Sent: Monday, October 19, 2009 11:45 AM To: Nick Hilliard; mti...@globaltransit.net Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] DWDM optics on 6500s As a side issue, there are electrical limitations imposed by the physical cross-bar unit inside the actual chassis, but I don't know how much of a problem these limitations are in practice. 6500E was the key for this. Besides nutty amounts of POE capacity, it also picked up improved backplane for 20g+ fabric and extending to all 11 LC slots in the 6513. (Still need to dig up details, as faster SSO time is also tied to chassis, though I can't recall why). ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] XFP, SFP+, ???
So, I am looking at doing DWDM for some mid-haul passive-splitter links around NYC metro - working with a carrier that's buying dark and offering to hand me lambdas off passive splitters. I'm going to need to punch enough power to go 20-40km + losses in the passive splitters. Do I need to look at SXI + SIP-400 + SPA to go XFP? Am I better off with a 6704 to get XENPAK even tho it's not the best board in the known universe? Or do I go with X2 tuned optics? Effectively, what's the cheapest practical option, assuming I need no more than 4 ports per 6500 and don't have 1 slot available? (I have physical space constraints, I mostly work with 03E and 04E chassis) Thanks, -bacon ___ cisco-nsp 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] Content Services Switch (CSS) question
On Mon, 19 Oct 2009 23:35:46 +0200, Per A erpa22...@yahoo.com wrote: I have an application out in the world that is submitting a blank XML document to one of my web services and it is causing the server to throw an exception. The exceptions are happening with enough frequency that the server is getting overwhelmed. I want to prevent these requests from reaching the server and I'm hoping that I can use CSS to identify the requests and send back an error (or send to another server to handle) when the METHOD=POST and Content Length = 0. Is this possible? Hi Per A, It's been a while since I last played with the arrowp^WCSS-Boxes, but it should be possible. You need a L5-Rule, to act on that headerfield and redirect it to another service, which then acts different on what you want as response, maybe returning a 404. Greetings, Jan -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ cisco-nsp 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] DWDM optics on 6500s
I assume that even though the 6509-V-E is available, until the 80gig line cards and Sup are available, you'd be stuck at 40gig/slot? Correct (nothing special about the 09-V-E in this respect compared to any other the -E's as far as I know). This is the same as how the traditional (pre-E) 6500 chassis was capable of doing to do 2x20gb per slot, but it was a step ahead of the rest of the system which would only deliver 8gb (w/ SFM/SFM2) until the Sup720 was released. ___ cisco-nsp 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] XFP, SFP+, ???
So, I am looking at doing DWDM for some mid-haul passive-splitter links around NYC metro - working with a carrier that's buying dark and offering to hand me lambdas off passive splitters. Did you consider an active unit before you go running in vendor coloured pluggable compatability issues (which technically should be few and far between now cisco have pulled their finger out) http://www.nanog.org/meetings/nanog42/presentations/pluggables.pdf is a good presentation from nanog42 with regards to pluggables. I see you have 6500, but you make no mention of 1G or 10G being your requirement, if you meant 10G then I assume this means you are thinking of WS-X6704/8 and in such case you can /technically/ get hold of coloured xenpaks (I believe opnext manafacture these) but I would personally not waste my money here. If 1G, your options are more open, plenty of people manafacture coloured SFPs which are cisco compatible Dave. Jeff Bacon wrote: So, I am looking at doing DWDM for some mid-haul passive-splitter links around NYC metro - working with a carrier that's buying dark and offering to hand me lambdas off passive splitters. I'm going to need to punch enough power to go 20-40km + losses in the passive splitters. Do I need to look at SXI + SIP-400 + SPA to go XFP? Am I better off with a 6704 to get XENPAK even tho it's not the best board in the known universe? Or do I go with X2 tuned optics? Effectively, what's the cheapest practical option, assuming I need no more than 4 ports per 6500 and don't have 1 slot available? (I have physical space constraints, I mostly work with 03E and 04E chassis) Thanks, -bacon ___ cisco-nsp 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] XFP, SFP+, ???
I see you have 6500, but you make no mention of 1G or 10G being your requirement, if you meant 10G then I assume this means you are thinking of WS-X6704/8 and in such case you can /technically/ get hold of coloured xenpaks (I believe opnext manafacture these) but I would personally not waste my money here. If 1G, your options are more open, plenty of people manafacture coloured SFPs which are cisco compatible Desire is for 10G. If I wanted 1G I can just have the carrier give me switched enet and not bother with any of the fuss. I could temporarily use 1G colored SFPs but that's IMO a throwaway. The bandwidth requirement is for 1G X 10G; primarily bursting to 3-5G with well under 1G average for now, eventually the average will come up but that's 6mo-1yr+. Policing the streams to fit in a 1G pipe is not an option; the bursts have to get through and dropping packets is not acceptable. 6708 uses X2, yes? Or are we considering XENPAK/X2 interchangeable from the POV of buying colored optics? Using an external box to condition the wave is an option but now I'm paying bux for the colored optics in the box, plus the box, plus the 10G to get into the 6500, which seems like a net big lose. -bacon ___ cisco-nsp 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] Bonded T1 Circuits
Hi Everyone: Two questions: 1. I need to bond two T1 circuits. Does anyone have a working sample config? The POP end is a 7206VXR with NPE-G2 and the PA-MC-2T3-EC Card, and the customer end is a Cisco 1841. 2. Also need to bond as many as 4 T1s. Would that be pushing it, and what would generally be the cleanest way to do it? Dominic ___ cisco-nsp 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] XFP, SFP+, ???
On 20/10/2009 15:55, Jeff Bacon wrote: Using an external box to condition the wave is an option but now I'm paying bux for the colored optics in the box, plus the box, plus the 10G to get into the 6500, which seems like a net big lose. The advantage that this gives you is that you don't end up paying for coloured xenpaks or X2s (both of which are ridiculously expensive), and you do end with a transmission system which is completely vendor and transceiver independent. Cheap is a fluid concept. Are you measuring cheap according to up-front capex right now, or by 1Y / 3Y / 5Y tco or whatever your depreciation time period is, or by reusability if you change from one client transceiver type to another? Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Bonded T1 Circuits
something like this should work (got it off one of production router): interface Serial0/0/0 mtu 4470 no ip address encapsulation ppp ppp multilink ppp multilink group 1 interface Serial0/1/0 mtu 4470 no ip address encapsulation ppp ppp multilink ppp multilink group 1 interface Multilink1 mtu 4470 ip address 192.168.11.205 255.255.255.252 ppp multilink ppp multilink group 1 ppp multilink fragment disable Regards, Ge Moua | Email: moua0...@umn.edu Network Design Engineer University of Minnesota | Networking Telecommunications Services Dominic wrote on 10/20/2009 10:05 AM: Hi Everyone: Two questions: 1. I need to bond two T1 circuits. Does anyone have a working sample config? The POP end is a 7206VXR with NPE-G2 and the PA-MC-2T3-EC Card, and the customer end is a Cisco 1841. 2. Also need to bond as many as 4 T1s. Would that be pushing it, and what would generally be the cleanest way to do it? Dominic ___ cisco-nsp 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] Bonded T1 Circuits
Hi Dominic, We do ours with MLPPP: interface Multilink1 bandwidth 3072 ip address no cdp enable ppp multilink ppp multilink group 1 ! interface Serial0/0/0:0 bandwidth 1536 no ip address no ip proxy-arp encapsulation ppp no cdp enable ppp multilink ppp multilink group 1 ! interface Serial0/0/1:0 bandwidth 1536 no ip address no ip proxy-arp encapsulation ppp no cdp enable ppp multilink ppp multilink group 1 1) Both serial interfaces are a part of the logical Multilink interface. Nice part about this is you can add and remove circuits/interfaces to the Multilink quite easily. 2) Depending on the router on your end, you may run into limitations for how many ckts you can have in the bundle and have it work properly. Not sure how many the 1841 will support. In our case, I believe our 2821 can support a max of 4 T1s. -Jeff -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dominic Sent: Tuesday, October 20, 2009 10:06 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Bonded T1 Circuits Hi Everyone: Two questions: 1. I need to bond two T1 circuits. Does anyone have a working sample config? The POP end is a 7206VXR with NPE-G2 and the PA-MC-2T3-EC Card, and the customer end is a Cisco 1841. 2. Also need to bond as many as 4 T1s. Would that be pushing it, and what would generally be the cleanest way to do it? Dominic ___ cisco-nsp 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] XFP, SFP+, ???
On 20/10/2009 15:55, Jeff Bacon wrote: Using an external box to condition the wave is an option but now I'm paying bux for the colored optics in the box, plus the box, plus the 10G to get into the 6500, which seems like a net big lose. The advantage that this gives you is that you don't end up paying for coloured xenpaks or X2s (both of which are ridiculously expensive), and you do end with a transmission system which is completely vendor and transceiver independent. Well, yer always dependent on _some_ vendor - be it Cisco, opt-whoever, or whoever's making your external box. I suppose if you're avoiding XENPAK/X2 and trying to go XFP, then your XFP is theoretically portable. (Though you could fork for a SIP400 and the 10G SPA and then be XFP-happy.) Cheap is a fluid concept. Are you measuring cheap according to up-front capex right now, or by 1Y / 3Y / 5Y tco or whatever your depreciation time period is, or by reusability if you change from one client transceiver type to another? Up-front capex, 2yr TCO (though in the given case I'm not sure what else factors into TCO besides the MRC of the fiber path and cost of rack space). It feels like a crap-shoot on XFP / SFP+, with reach issues on the SFP+ that could be an issue. From the docs Peter kindly posted earlier, it appears Cisco is planning to cope with SFP+ with the CVR-X2-SFP10G OneX X2-SFP+ adapters. Doesn't help now b/c it's SR/copper only, but I'd be surprised if this didn't get fleshed out. ___ cisco-nsp 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] Bonded T1 Circuits
Jeff Wojciechowski wrote: 2) Depending on the router on your end, you may run into limitations for how many ckts you can have in the bundle and have it work properly. Not sure how many the 1841 will support. In our case, I believe our 2821 can support a max of 4 T1s. You could do 8 if you use four VWIC-2MFT-T1 cards, which is pretty much as high as you'd ever want to go with MLPPP. ~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] XFP, SFP+, ???
On Tue, 20 Oct 2009 10:56:02 -0500, Jeff Bacon wrote It feels like a crap-shoot on XFP / SFP+, with reach issues on the SFP+ that could be an issue. From the docs Peter kindly posted earlier, it appears Cisco is planning to cope with SFP+ with the CVR-X2-SFP10G OneX X2-SFP+ adapters. Doesn't help now b/c it's SR/copper only, but I'd be surprised if this didn't get fleshed out. Well, the biggest problem with SFP+ is, no DWDM nor 80 km version exists today and noone knows when (if at all) this will be available. As for the adapter, an X2-XFP is also doable and would help many customers, but it's apparently not planned... With kind regards, M. ___ cisco-nsp 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] XFP, SFP+, ???
On Tue, Oct 20, 2009 at 09:14:26AM -0500, Jeff Bacon wrote: So, I am looking at doing DWDM for some mid-haul passive-splitter links around NYC metro - working with a carrier that's buying dark and offering to hand me lambdas off passive splitters. I'm going to need to punch enough power to go 20-40km + losses in the passive splitters. Do I need to look at SXI + SIP-400 + SPA to go XFP? Am I better off with a 6704 to get XENPAK even tho it's not the best board in the known universe? Or do I go with X2 tuned optics? Effectively, what's the cheapest practical option, assuming I need no more than 4 ports per 6500 and don't have 1 slot available? (I have physical space constraints, I mostly work with 03E and 04E chassis) SIP/SPA or ES cards are horrifically overpriced if all you want to do is use XFP. You can find DWDM XENPAKs which work just fine, but they're quite pricey if you get them new, and in limited quantity if you want to find them used. If you only need a pair of DWDM optics you're probably fine to find a used or third party XENPAK to meet your needs, and this will be the cheapest option. If you actually have to buy these things in any kind of quantity (i.e. hundreds+) you're probably going to want to go XFP purely for availability and lead time. Your best (or atleast cheapest, but I can't say anything bad about them other than they don't do FEC like some similar higher priced/lower density converters) bet if you need an external converter to run DWDM XFP line side and LR client side is the MRV 2XFP repeater in a Fiber Driver chassis. http://www.mrv.com/datasheets/FD/PDF300/MRV-FD-2XFP_HI.pdf -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ cisco-nsp 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] Multicast trickery
Hi All I am in need of pointers regarding a multicast configuration that does not fit the models found online or in the literature I have at hand. The network is built on PIM-SM with 2 BSR-RP routers (core1 and core2). At Core1 we receive a set of Multicast streams from IPTV-Provider 1 via PIM-SM and MSDP, this works fine. The mroutes are announced to Core2 via MSDP, works fine. At Core2 we receive a set of Multicasts that are flooded too us, this is the problem source. I can't distribute this in MSDP if I run PIM-SM. If I run PIM-DM they call me in a hurry and tell me that my PIM packets are disturbing the network. - So long I have not been able to filter out PIM packets with outbound acls on the SVI. I have used IP IGMP unidirectional... but that broke MSDP between the cores. Trying ip mroute gave me invalid source address How should I proceed too accept the multicast streams and inject them into MDSP. My hope is that I will get to a point where I can use MSDP between cores and ANYCAST my RPs. Best regards Mattias Gyllenvarg Omnitron Sweden ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast trickery
Hi Hans I have set BSR-BORDER on the interface, so that should not be it. I want too run PIM-DM but as long as I send PIM-packets I can not. Anyone have a theory about the filter not biting? Im not at work now but it looks something like. Deny ip pim any any Deny ip any multicast Permit any any Best regards Mattias Gyllenvarg 2009/10/20 Hans Verkerk hverk...@winitu.com: Hi, If I run PIM-DM they call me in a hurry and tell me that my PIM packets are disturbing the network. Maybe your BSR packets are interfering with SP2's network, so include ip pim bsr-border on interface facing SP2. PIM DM sources can be distributed as follows into MSDP: http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_msdp _im_pim_sm_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp105549 3 HTH, Hans -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Wyatt Mattias Gyllenvarg Sent: Tuesday, October 20, 2009 6:23 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Multicast trickery Hi All I am in need of pointers regarding a multicast configuration that does not fit the models found online or in the literature I have at hand. The network is built on PIM-SM with 2 BSR-RP routers (core1 and core2). At Core1 we receive a set of Multicast streams from IPTV-Provider 1 via PIM-SM and MSDP, this works fine. The mroutes are announced to Core2 via MSDP, works fine. At Core2 we receive a set of Multicasts that are flooded too us, this is the problem source. I can't distribute this in MSDP if I run PIM-SM. If I run PIM-DM they call me in a hurry and tell me that my PIM packets are disturbing the network. - So long I have not been able to filter out PIM packets with outbound acls on the SVI. I have used IP IGMP unidirectional... but that broke MSDP between the cores. Trying ip mroute gave me invalid source address How should I proceed too accept the multicast streams and inject them into MDSP. My hope is that I will get to a point where I can use MSDP between cores and ANYCAST my RPs. Best regards Mattias Gyllenvarg Omnitron Sweden ___ 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] Inserting a default route into a MPLS/VPN pointing out of the VRF
On Mon, Oct 19, 2009 at 04:49:40PM -0500, Justin Shore wrote: I've come across route-leaking examples but they all require me to point traffic to an outward-facing interface. Ie, I can't just point the default route to a specific upstream-facing interface. Is there another way? I can't see a solution with importing routes at the route-target level. Can I point it to a loopback outside of the VRF? [ ... ] This is probably a simple process but I haven't had to do it before without the FWSM which made it trivially easy. What simple solution have I overlooked and will kick myself for missing later? Cisco has no support for: ip route vrf vrfX x.x.x.x/x next-hop next-hop vrfY where the traffic in vrfX matching that route would be sent over into vrfY (and then forwarded according to vryY's forwarding table). (Some other vendors can do that.) (In your case, you want vrfY to be global, but that's not doable either.) The only clean way is to connect via an interface. For example, connect a cable from GIa/b to GIc/d and then configure: int GIa/b ip address x.x.x.1/30 int GIc/d ip vrf forwarding vrfX ip address x.x.x.2/30 ip route vrf vrfX 0.0.0.0/0 GIc/d x.x.x.1 (obviosuly I'm not using exact IOS commands above, but you get the idea.) On some platforms, this can be done with tunnels instead of physical interfaces to avoid using two physical ports and dealing with the risk that those ports might fail: int lo1 ip address z.z.z.10/32 int lo2 ip address x.x.x.20/32 int tun1 ip address x.x.x.1/30 tunnel source lo1 tunnel destination x.x.x.20 int tun2 ip vrf forwarding vrfX ip address x.x.x.2/30 tunnel source lo2 tunnel destination x.x.x.20 ip route vrf vrfX 0.0.0.0/0 tun2 How well this works depends on how tunnels are implemented on the platform you're using. It works fine on software-based routers. ASR1000s worked OK in my testing. Never tried 6500/7600s. Note that the suggestion to leak default from your global table into the VRF potentially fails on two accounts. First, you might or might not have a default in your global table. Second, if you do, leaking that would direct all internet traffic to follow the default route, and, assuming you have default plus a lot of more other routes in your global table, you wouldn't want traffic covered by a more-specific in the global table to follow the default if it originated in vrfX. That is, with a global table of: 100.0.0.0/8- A 0.0.0.0/0 - B if you import only 0.0.0.0/0 into a vrf, then all traffic matching the default in that VRF will be sent to B, even traffic traffic to 100.0.0.0/8. -- Brett ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Bonded T1 Circuits
You could do 8 if you use four VWIC-2MFT-T1 cards, which is pretty much as high as you'd ever want to go with MLPPP. With the major caveat that the clock is shared between both ports on a the VWIC. Even knowing this, it has still bitten us when originally identical T1's got groomed onto different upstream circuits. HWIC-4T1/E1 doesn't have this limitation, but is only supported on the 2821 and up. ___ cisco-nsp 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] Bonded T1 Circuits
MLPPP working config below. Do the same thing on the remote router ie:create multilink interface with IP address and add DS1 interfaces to multilink group interface Multilink1 description Orinda bundle DS3 channels 11,18,12 ip address xxx.xxx.x.177 255.255.255.252 ip flow ingress ppp multilink multilink-group 1 service-policy output MLPPP-4.6 interface Serial1/0/0/11:0 description Orinda #1 Circuit ID -001PT no ip address encapsulation ppp ppp multilink multilink-group 1 ! interface Serial1/0/0/12:0 description Link to Orinda #3 CID xxx-001PT no ip address encapsulation ppp ppp multilink multilink-group 1 interface Serial1/0/0/18:0 description Orinda USD #2 Circuit ID xxx-001PT no ip address encapsulation ppp ppp multilink multilink-group 1 --- On Tue, 10/20/09, Dominic domi...@broadconnect.ca wrote: From: Dominic domi...@broadconnect.ca Subject: [c-nsp] Bonded T1 Circuits To: cisco-nsp@puck.nether.net Date: Tuesday, October 20, 2009, 8:05 AM Hi Everyone: Two questions: 1. I need to bond two T1 circuits. Does anyone have a working sample config? The POP end is a 7206VXR with NPE-G2 and the PA-MC-2T3-EC Card, and the customer end is a Cisco 1841. 2. Also need to bond as many as 4 T1s. Would that be pushing it, and what would generally be the cleanest way to do it? Dominic ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast trickery
Wyatt, I have set BSR-BORDER on the interface, so that should not be it. I want too run PIM-DM but as long as I send PIM-packets I can not. Anyone have a theory about the filter not biting? how about ip multicast boundary ACL# and blocking ALL-PIM-ROUTERS 224.0.0.13 and allowing all other groups from another SP? Best Regards, -mat ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multicast trickery
Hi Mattias If I understand your topology correctly, the configuration should be very similar to what you would use for any other internal source. The difference in this case that the source in this case is the provider network, and being untrusted requires additional precautions on the input interface (only). Considering a conventional Anycast RP multicast topology for a moment, when the multicast packets are received by the DR, the DR encapsulates the packets as unicast register messages and sends them to the nearest RP for that group. The RP effectively converts the first register messages to a source active message, and then sends the SA to each configured MSDP peer. In this example the SA is originated because a register messages has been received for a new source. The register message is sent to that router because it is a active RP for the group. Since you are using BSR you have only one active RP for each group, and is may be important which that is in this case. Is your second C-RP is the active RP for the group you are having problems with? Tested a topology with a combined DR and RP, some years ago. It may work if you run PIM-SM and the RP is the DR for the subnet, but if I recall correctly, behaviour differed between different routers/software versions and it did not work well/often. You should be able to test this easily enough by debugging msdp and pinging an unused multicast group from a router connected to your RP. With pim-sm enabled on the RP's input interface, and the RP elected as DR, you may still find that no SA is originated. You could try to persuade your second provider to provide MSDP and BGP information, but I guess you have already tried that approach. Alternatively attach another router to your RP and have the provider present the multicast stream on that. As well as the bsr boundary, and acls to stop pim (inc unicast pim), make sure you have pim register rate-limit applied. You must also make sure that traffic to the auto rp groups is not permitted into your network. IP multicast boundary is useful. The method in the link that Hans provided should also work, though I would think it wise to test in a lab first if you are thinking of applying it to one of your main C-RP routers; or apply it on another router entirely. The acl you mentioned will not stop multicast packets sent by the router on which it is applied, and that is likely to be why multicast traffic is still leaking through. If this router is the RP for a particular multicast group, when one of your sources begins sending to a group, the first packet the RP router receives is as a unicast register message, which it decapsulates before transmission. The path of the packet through the router is not the same as for native multicast, since it is unicast to the RP and has to be punted to the CPU; it may be that these decapsulated packets are not being filtered. If you have static RP definitions anywhere in your network, traffic to groups without a configured RP might also be leaking out. IP multicast boundary may help. You mentioned Anycast-RP, and using that with static RP definitions is quite straightforward to configure and maintain, perhaps easier than you think. Paul. On Tue, Oct 20, 2009 at 6:03 PM, Wyatt Mattias Gyllenvarg wyatt.elias...@gmail.com wrote: Hi Hans I have set BSR-BORDER on the interface, so that should not be it. I want too run PIM-DM but as long as I send PIM-packets I can not. Anyone have a theory about the filter not biting? Im not at work now but it looks something like. Deny ip pim any any Deny ip any multicast Permit any any Best regards Mattias Gyllenvarg 2009/10/20 Hans Verkerk hverk...@winitu.com: Hi, If I run PIM-DM they call me in a hurry and tell me that my PIM packets are disturbing the network. Maybe your BSR packets are interfering with SP2's network, so include ip pim bsr-border on interface facing SP2. PIM DM sources can be distributed as follows into MSDP: http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_msdp _im_pim_sm_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp105549 3 HTH, Hans -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Wyatt Mattias Gyllenvarg Sent: Tuesday, October 20, 2009 6:23 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Multicast trickery Hi All I am in need of pointers regarding a multicast configuration that does not fit the models found online or in the literature I have at hand. The network is built on PIM-SM with 2 BSR-RP routers (core1 and core2). At Core1 we receive a set of Multicast streams from IPTV-Provider 1 via PIM-SM and MSDP, this works fine. The mroutes are announced to Core2 via MSDP, works fine. At Core2 we receive a set of Multicasts that are flooded too us, this is the problem source. I can't distribute this in MSDP if I run
[c-nsp] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS
Hi All, Has anyone gotten ASA based VPN (soft clients) to work with Windows 2008 NPS - AD Integrated RADIUS to work? As our engineer put it: Cisco does not have a document for authentication configuration with Windows 2008. Since they say the ASA configuration looks fine they have washed their hands of it and want to close the case. I can see this in the logs on our AD server: Contact the Network Policy Server administrator for more information. User: Security ID:NULL SID Account Name: %domain\username% Account Domain: - Fully Qualified Account Name: - Client Machine: Security ID:NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: %some ip address% Calling Station Identifier: %some originating ip address% NAS: NAS IPv4 Address:%ip of server% NAS IPv6 Address:- NAS Identifier: - NAS Port-Type: Virtual NAS Port: 159744 RADIUS Client: Client Friendly Name: whl_vpn_new Client IP Address: %ip address of client% Authentication Details: Proxy Policy Name: - Network Policy Name: - Authentication Provider: - Authentication Server: %fqdn of server% Authentication Type: - EAP Type: - Account Session Identifier: - Reason Code:49 Reason: The connection attempt did not match any connection request policy. If this has been asked and answered (or if there is a better forum for this), I apologize. If someone could nudge me in the right direction that would be very awesome. Technet for the above error is pretty pointless as usual Thanks again, -Jeff ___ cisco-nsp 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] Bonded T1 Circuits
Looks like I'm late to the game but I would recommend MLPPP. Note the EC card has the MLPPP offload so I would stick with those. The only thing to be aware of is always turn off frag (I believe you have received config examples of this). http://www.cisco.com/en/US/prod/collateral/modules/ps2033/prod_white_paper0900aecd8056d3cb.html tv - Original Message - From: Dominic domi...@broadconnect.ca To: cisco-nsp@puck.nether.net Sent: Tuesday, October 20, 2009 10:05 AM Subject: [c-nsp] Bonded T1 Circuits Hi Everyone: Two questions: 1. I need to bond two T1 circuits. Does anyone have a working sample config? The POP end is a 7206VXR with NPE-G2 and the PA-MC-2T3-EC Card, and the customer end is a Cisco 1841. 2. Also need to bond as many as 4 T1s. Would that be pushing it, and what would generally be the cleanest way to do it? Dominic ___ cisco-nsp 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] Inserting a default route into a MPLS/VPN pointing out of the VRF
Phil Bedard wrote: If you are already using a VRF to carry the default table you should be able to import a default route from that vrf into your customer vrf. You can use an import-map to select only the default. The only time I've implemented something similar to this I've used external firewalls which have their own trusted sub-int into the customer network and their untrust side connected to an Internet router. Similar to what you say you are doing on the datacenter side. You could do the same thing without a firewall, just need a dedicated trunk so you can bridge between the default VRF/global table and the customer VRF. Then just static routes out that interface. Thanks to all the replies. I didn't word my initial message very well. My Internet tables are in the default VRF (ie, the global VRF). I don't carry around Inet tables in dedicated VRFs (though I've been told by some that this is a good idea). My FWSMs provided me the same functionality as your external FWs. Unfortunately this is for raw, unfiltered and unprotected customer Internet access. I suppose a different technique would be to take these special customers and use routing to push traffic destined for the special peering network into that dedicated VRF and keep all their other traffic in the default VRF. While I can say that I can't envision a way to accomplish that. I think it's easier to start in the dedicated VRF and leak traffic out of it. I thought of a couple possible solutions last night. One was the use of the 'global' statement in the default route inside the VRF. It has the same problems as the static route to an interface. I want the core Ps to make a routing decision on the upstream exit point which I can't do if I'm setting the next-hop to be an IP on an upstream router or an interface facing an upstream router. The other option I thought of was to not inject the default on the core Ps but instead do it on PE1, the peering router to this special network. Ultimately PE1 will be dual-homed to P1 and P2. I could then set the next-hop for the default in the VRF on PE1 to be a FHRP floater on P1 and P2 and use that as the global IP. I think that would work too but haven't tried it. Another c-nsp reader gave me what I think will most likely be my solution. His suggestion was to use an import map on the VRD, a route-map and prefix-list to import a default route into the VRF that way. I'm sure that will work. I'm intrigued by the tunnel solutions too. PE1 will be replaced with an ASR in a few months so I may give that a try as well. It's good to know all the various ways to accomplish the goal in case I have to implement something different someday. Thanks for all the suggestions Justin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Inserting a default route into a MPLS/VPN pointing out of the VRF
Brett Frankenberger wrote: Cisco has no support for: ip route vrf vrfX x.x.x.x/x next-hop next-hop vrfY where the traffic in vrfX matching that route would be sent over into vrfY (and then forwarded according to vryY's forwarding table). (Some other vendors can do that.) (In your case, you want vrfY to be global, but that's not doable either.) I cracked open my MPLS books last night and found a similar solution with an IP next-hop in the MPLS VPN Arch book. It set the next-hop to be an IP in the global VRF by using the 'global' keyword. ip default vrf VRFx 0.0.0.0 0.0.0.0 1.2.3.4 global It has the same problems as the other solution I found for setting the next-hop to be an exit interface. I want the Ps to make a routing decision to determine the exit path for the packet, not hardcode it to go one way or another (and possibly have a iBGP-meshed BR1 decide that the better exit point would be another BR and route that back to the core P to get to BR2. This is why I was wondering if the target interface or IP could be a loopback on the Ps. I really need to lab these ideas. The only clean way is to connect via an interface. For example, connect a cable from GIa/b to GIc/d and then configure: int GIa/b ip address x.x.x.1/30 int GIc/d ip vrf forwarding vrfX ip address x.x.x.2/30 ip route vrf vrfX 0.0.0.0/0 GIc/d x.x.x.1 (obviosuly I'm not using exact IOS commands above, but you get the idea.) I thought about that and I could do that. It's an added expense though. On some platforms, this can be done with tunnels instead of physical interfaces to avoid using two physical ports and dealing with the risk that those ports might fail: int lo1 ip address z.z.z.10/32 int lo2 ip address x.x.x.20/32 int tun1 ip address x.x.x.1/30 tunnel source lo1 tunnel destination x.x.x.20 int tun2 ip vrf forwarding vrfX ip address x.x.x.2/30 tunnel source lo2 tunnel destination x.x.x.20 ip route vrf vrfX 0.0.0.0/0 tun2 How well this works depends on how tunnels are implemented on the platform you're using. It works fine on software-based routers. ASR1000s worked OK in my testing. Never tried 6500/7600s. This is a thought. I haven't tried it on 7600s either but it's worth trying to see if it would work. Note that the suggestion to leak default from your global table into the VRF potentially fails on two accounts. First, you might or might not have a default in your global table. Second, if you do, leaking that would direct all internet traffic to follow the default route, and, assuming you have default plus a lot of more other routes in your global table, you wouldn't want traffic covered by a more-specific in the global table to follow the default if it originated in vrfX. That is, with a global table of: 100.0.0.0/8- A 0.0.0.0/0 - B if you import only 0.0.0.0/0 into a vrf, then all traffic matching the default in that VRF will be sent to B, even traffic traffic to 100.0.0.0/8. I originate a default in my IGP on each BR currently. I'm thinking about moving that into iBGP though. I'll originate a default on the Ps in the VRF with MP-iBGP. This touches on the problem I outlined above talking about the Ps making the decision on exit path. My Ps are part of the iBGP mesh with full tables from the BRs. In theory they should make the same routing decision for a given packet that a BR will do when it receives that same packet milliseconds later. I'm going to try the importing of the default in the VRF statement. I think that will work but I'll find out for sure with my testing. If it doesn't then I may have to try the tunneling solution. I may have to settle for inefficient routing for a few months until the ASR comes in and then do tunnels on it. Either way I think I'm on the right track. Thanks for the insight Justin ___ cisco-nsp 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] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS
With a 5510 we are using 2008 NPS for AD auth. Do you have something under you Connection Request Policy? The log seems to be telling you that there is something missing there. Thanks, Erik -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wojciechowski Sent: Tuesday, October 20, 2009 3:58 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS Hi All, Has anyone gotten ASA based VPN (soft clients) to work with Windows 2008 NPS - AD Integrated RADIUS to work? As our engineer put it: Cisco does not have a document for authentication configuration with Windows 2008. Since they say the ASA configuration looks fine they have washed their hands of it and want to close the case. I can see this in the logs on our AD server: Contact the Network Policy Server administrator for more information. User: Security ID: NULL SID Account Name: %domain\username% Account Domain: - Fully Qualified Account Name: - Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: %some ip address% Calling Station Identifier: %some originating ip address% NAS: NAS IPv4 Address:%ip of server% NAS IPv6 Address:- NAS Identifier: - NAS Port-Type: Virtual NAS Port: 159744 RADIUS Client: Client Friendly Name: whl_vpn_new Client IP Address: %ip address of client% Authentication Details: Proxy Policy Name: - Network Policy Name: - Authentication Provider: - Authentication Server: %fqdn of server% Authentication Type: - EAP Type: - Account Session Identifier: - Reason Code:49 Reason: The connection attempt did not match any connection request policy. If this has been asked and answered (or if there is a better forum for this), I apologize. If someone could nudge me in the right direction that would be very awesome. Technet for the above error is pretty pointless as usual Thanks again, -Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] 802.1ad 4PortsWIC 1751
Hello experts, I need to know if a 4PortsWIC support 802.1ad(ethertype 0x88a8) to connect one of it's ports as a trunk to an Extreme summit 48si. Cisco1751(4PortsWIC_Port1 as a Trunk)(Port1 as a Trunk)Extrme Summit 48si I connected a PC to each side of the topology and don't see each other trough the VMAN. Best regards. _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us ___ cisco-nsp 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] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS
Jeff, I've done several VPN setups with 2008 NPS, and from what I remember offhand they were no different than the 'old' IAS. Some of the items might have moved around a bit in the GUI, but the basic IAS functionality is still there. From the error message, I would look at the connection policies, because if I am remembering correctly the default is not very useful and needs to be changed. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wojciechowski Sent: Tuesday, October 20, 2009 3:58 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS Hi All, Has anyone gotten ASA based VPN (soft clients) to work with Windows 2008 NPS - AD Integrated RADIUS to work? As our engineer put it: Cisco does not have a document for authentication configuration with Windows 2008. Since they say the ASA configuration looks fine they have washed their hands of it and want to close the case. I can see this in the logs on our AD server: Contact the Network Policy Server administrator for more information. User: Security ID:NULL SID Account Name: %domain\username% Account Domain: - Fully Qualified Account Name: - Client Machine: Security ID:NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: %some ip address% Calling Station Identifier: %some originating ip address% NAS: NAS IPv4 Address:%ip of server% NAS IPv6 Address:- NAS Identifier: - NAS Port-Type: Virtual NAS Port: 159744 RADIUS Client: Client Friendly Name: whl_vpn_new Client IP Address: %ip address of client% Authentication Details: Proxy Policy Name: - Network Policy Name: - Authentication Provider: - Authentication Server: %fqdn of server% Authentication Type: - EAP Type: - Account Session Identifier: - Reason Code:49 Reason: The connection attempt did not match any connection request policy. If this has been asked and answered (or if there is a better forum for this), I apologize. If someone could nudge me in the right direction that would be very awesome. Technet for the above error is pretty pointless as usual Thanks again, -Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Router reccomendation
I'm looking for a box that can take in a gigabit connection, which will have 6 sites remotely connected each at 100mbit. It's likely that near full rate will be desired on the remote sites in this hub/spoke design. The customer has some 3750's and 2800 series routers, but I am looking to see if anyone has a recommendation on the 3750's passing 100mbit (routed) and something for a main site router that could aggregate 600mbit or more. ___ cisco-nsp 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] FW: ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS
Its Windowstry restarting NPS Service :) Thanks to the off-list responses! -Jeff -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wojciechowski Sent: Tuesday, October 20, 2009 2:58 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS Hi All, Has anyone gotten ASA based VPN (soft clients) to work with Windows 2008 NPS - AD Integrated RADIUS to work? As our engineer put it: Cisco does not have a document for authentication configuration with Windows 2008. Since they say the ASA configuration looks fine they have washed their hands of it and want to close the case. I can see this in the logs on our AD server: Contact the Network Policy Server administrator for more information. User: Security ID:NULL SID Account Name: %domain\username% Account Domain: - Fully Qualified Account Name: - Client Machine: Security ID:NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: %some ip address% Calling Station Identifier: %some originating ip address% NAS: NAS IPv4 Address:%ip of server% NAS IPv6 Address:- NAS Identifier: - NAS Port-Type: Virtual NAS Port: 159744 RADIUS Client: Client Friendly Name: whl_vpn_new Client IP Address: %ip address of client% Authentication Details: Proxy Policy Name: - Network Policy Name: - Authentication Provider: - Authentication Server: %fqdn of server% Authentication Type: - EAP Type: - Account Session Identifier: - Reason Code:49 Reason: The connection attempt did not match any connection request policy. If this has been asked and answered (or if there is a better forum for this), I apologize. If someone could nudge me in the right direction that would be very awesome. Technet for the above error is pretty pointless as usual Thanks again, -Jeff ___ cisco-nsp 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] FW: ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS
Oh God, Winders in the authorization chain. Clearly someone doesn't like sleeping well.;) The only thing I've seen more frightening than that is an entirely Windows NT 4.0 based heart care environment where the review stations would crash when the Fore ATM adapters took more than 50 megabits of traffic. (Sorry sir, we'd be working on your heart attack and trying to do some imaging here but we've bluescreened, can you hold?) - Original Message - From: Jeff Wojciechowski jeff.wojciechow...@midlandpaper.com To: cisco-nsp@puck.nether.net Sent: Tuesday, October 20, 2009 2:16 PM Subject: [c-nsp] FW: ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS Its Windowstry restarting NPS Service :) Thanks to the off-list responses! -Jeff -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wojciechowski Sent: Tuesday, October 20, 2009 2:58 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASA 5505 VPN with 2008 NPS as AD Integrated RADIUS Hi All, Has anyone gotten ASA based VPN (soft clients) to work with Windows 2008 NPS - AD Integrated RADIUS to work? As our engineer put it: Cisco does not have a document for authentication configuration with Windows 2008. Since they say the ASA configuration looks fine they have washed their hands of it and want to close the case. I can see this in the logs on our AD server: Contact the Network Policy Server administrator for more information. User: Security ID: NULL SID Account Name: %domain\username% Account Domain: - Fully Qualified Account Name: - Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: %some ip address% Calling Station Identifier: %some originating ip address% NAS: NAS IPv4 Address:%ip of server% NAS IPv6 Address:- NAS Identifier: - NAS Port-Type: Virtual NAS Port: 159744 RADIUS Client: Client Friendly Name: whl_vpn_new Client IP Address: %ip address of client% Authentication Details: Proxy Policy Name: - Network Policy Name: - Authentication Provider: - Authentication Server: %fqdn of server% Authentication Type: - EAP Type: - Account Session Identifier: - Reason Code:49 Reason: The connection attempt did not match any connection request policy. If this has been asked and answered (or if there is a better forum for this), I apologize. If someone could nudge me in the right direction that would be very awesome. Technet for the above error is pretty pointless as usual Thanks again, -Jeff ___ cisco-nsp 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] Router reccomendation
Being switched based the 3750 will do 100Mbit easily. Its software features its lacks and has limited route table size. For your head end router, 600Mb/s is at the tope end of what you should expect from a 7201/7200 NPE-G2. Certainly if you wanted QoS you couldn't do it. So if you have basic feature requirements only then you could look at another 3750 (or any of the larger switches - 4500,4900,6500). If you want a router rather than a L3 Switch, then you're looking at an ASR1002 ESP5. Dean -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Walter Keen Sent: 20 October 2009 22:14 To: 'Cisco-nsp' Subject: [c-nsp] Router reccomendation I'm looking for a box that can take in a gigabit connection, which will have 6 sites remotely connected each at 100mbit. It's likely that near full rate will be desired on the remote sites in this hub/spoke design. The customer has some 3750's and 2800 series routers, but I am looking to see if anyone has a recommendation on the 3750's passing 100mbit (routed) and something for a main site router that could aggregate 600mbit or more. ___ cisco-nsp 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] Router reccomendation
I've routed over a gigabit with a 3750 switch taking limited BGP tables. It will meet your throughput needs fine as long as you don't need large BGP tables or fancy features. -- Randy -- Original Message --- From: Walter Keen walter.k...@rainierconnect.net To: 'Cisco-nsp' cisco-nsp@puck.nether.net Sent: Tue, 20 Oct 2009 14:13:49 -0700 Subject: [c-nsp] Router reccomendation I'm looking for a box that can take in a gigabit connection, which will have 6 sites remotely connected each at 100mbit. It's likely that near full rate will be desired on the remote sites in this hub/spoke design. The customer has some 3750's and 2800 series routers, but I am looking to see if anyone has a recommendation on the 3750's passing 100mbit (routed) and something for a main site router that could aggregate 600mbit or more. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ --- End of Original Message --- ___ cisco-nsp 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] DWDM optics on 6500s
Yup! No 80g cards yet. I haven't been debriefed on the architecture but I'm assuming it is going to be 2 x 40g or 4 x 20g backplane lanes. tv - Original Message - From: Church, Charles cchur...@harris.com To: Tony Varriale tvarri...@comcast.net; cisco-nsp@puck.nether.net Sent: Tuesday, October 20, 2009 9:14 AM Subject: RE: [c-nsp] DWDM optics on 6500s Thanks. I assume that even though the 6509-V-E is available, until the 80gig line cards and Sup are available, you'd be stuck at 40gig/slot? Chuck -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tony Varriale Sent: Monday, October 19, 2009 5:07 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] DWDM optics on 6500s It will shortly but it won't do you any good with the existing family of sups. The 2T will be the first (and last?) sup that can push the bandwidth to all those slots. You can also reference the 6509-V-E...it's ready for 80gbps/slot. You can order that today. Note that it's a NEBS chassis. tv - Original Message - From: Church, Charles cchur...@harris.com To: Kevin Graham kgra...@industrial-marshmallow.com Cc: cisco-nsp@puck.nether.net Sent: Monday, October 19, 2009 1:12 PM Subject: Re: [c-nsp] DWDM optics on 6500s Are you saying a 6513-E chassis exists? I can't find any reference to it. That would solve a few of the problems we currently have (density issue) Chuck -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Kevin Graham Sent: Monday, October 19, 2009 11:45 AM To: Nick Hilliard; mti...@globaltransit.net Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] DWDM optics on 6500s As a side issue, there are electrical limitations imposed by the physical cross-bar unit inside the actual chassis, but I don't know how much of a problem these limitations are in practice. 6500E was the key for this. Besides nutty amounts of POE capacity, it also picked up improved backplane for 20g+ fabric and extending to all 11 LC slots in the 6513. (Still need to dig up details, as faster SSO time is also tied to chassis, though I can't recall why). ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
