Re: [c-nsp] filter LDP bindings
On (2008-08-13 20:38 +0200), Oliver Boehmer (oboehmer) wrote: well, this dependency on what other LDP neighbors send is not really in-line with the independent control mode LDP operates in, so the implementation might not be straight-forward. I think we have misunderstanding here. All boxes would 'stupidly' accept and readvertise everything they get, no additional states here, plain 'ol ios behaviour without LDP ACL. But per node, you'd tell the nodes not to generate label, except for their loopback. End result would be, that you'd only have loop0̈́s in each MPLS spakers LIBs, without any ACL/prefix-list maintenance overhead. well, interfaces would also cover connected /30 or /31s, something you usually don't want to advertise labels for? You'd replace the 'interface' with loop0 or loopX, which ever you use for labeled destination. But wouldn't a (prefix) ACL be enough to cover most cases? Generally, loopbacks are allocated from one or more prefix ranges, so ACLs could be rather static? Yes, both can easily accomplish same goal, just bit additional admin overhead, while the true application in virtually all cases is, to generate label for single loopback interface. And actually we would have probably used 'your' way, had it been available when we wanted to implement it, instead of doing advertisement ACLs. -- ++ytti ___ 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] 4 Byte AS implementation on Cisco Routers
Hi, On Wed, Aug 13, 2008 at 04:39:53PM -0500, Richard A Steenbergen wrote: Rest assured that updating the festering piece of crap that is IOS to change every data structure that holds ASNs and every piece of code that tched them (think as-path, regexp, show/cli changes for the unbelievably retarded #.# syntax, etc), not to mention all the backwards compatibility code and testing, is especially hard. :) They have already done it for XR and Nexus, so they know how to do it. (Yes, I'm oversimplifying. But then, if they would consider it a major selling point, instead of an operational requirement for their customers, it would have happened years ago.) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [EMAIL PROTECTED] fax: +49-89-35655025[EMAIL PROTECTED] pgp0GSOtHSDFr.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] 6500 snmp and vty acls ?
On Wed, Aug 13, 2008 at 04:17:21PM -0400, Jeff Fitzwater wrote: Does anyone know if VTY and snmp ACLs are implemented in hardware or software on a 6500 with 720-CXL running 12.2(33)SXH. VTY and SNMP ACLs are done in software; they have to be, because they reference certain CPU conditions e.g. consider: vty 0 12 access-class NET_OPS in vty 13 15 access-class REALLY_VITAL in ...where you reserve VTYs 13-15 for really important stuff; clearly the CPU will have to be asked how many VTYs are open to make this work. Ditto with SNMP community strings - you might have 2 communities with mutually exclusive ACLs, and one needs to decode the SNMP header and extract the community before processing the ACL I am trying to understand COPP and move away from the VTY and SNMP ACLs. CoPP is done in hardware if everything is working correctly, though a 2nd pass of the ACLs can be performed in software to ensure that for a rate limit of N you don't get N*M pps - M being the number of DFC/PFC forwarding engines Thanks for any info. Jeff Fitzwater OIT Network Systems Princeton University ___ 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] Setting up a Internet Gateway (NAT-PE) for MPLS VPNCustomers
Andy Saykao wrote on Thursday, August 14, 2008 4:58 AM: Hi All We are looking at providing our Layer 3 MPLS VPN customers with the option of a managed internet gateway via a NAT-PE router. This would mean that remote sites no longer have to access the internet via the Central Site model as this is the way we've been implementing Internet access for MPLS VPN customers. As all our MPLS VPN customers are using private IP addresses, NAT would have to obviously take place at the NAT-PE router. [...] My delimma is that I'm not entirely sure which router should be designated as the NAT-PE router to act as the Internet Gateway for our MPLS VPN customers or if we need to put in a new PE router somewhere? So what I've brainstormed are the following ideas... 1/ Do we set the P router up as the NAT-PE router? I'm reluctant to do this because this is the core router that handles Internet traffic for all our customers and I don't want to mess it up. Agreed, I wouldn't take this path either. NAT is stateful, so future scalability is a concern, which is limited if you did this on your core/P node (turning it into a PE). 2/ Can the NAT-PE router be assigned to either PE1 or PE2? If so, I'm unsure how to apply NAT because there is only one interface on the PE router connecting to the P router so I'm not really sure where the ip nat inside and outside command would go - unless we use NAT on a stick which I don't think is recommended in a production environment. I would actually vote for some on-a-stick deployment, which is what many customers do (as far as I know). NPE-G1/G2 are popular platforms for this.. 3/ Lastly, do we need to put in a new router to act as the NAT-PE router? If so, where would this be placed - maybe between the P router and the Internet? I would add a new node, and put it somewhere close to the P router/internet connection. You can scale by adding addtl. routers and distribute your VPN customers across these nodes. The config would be along this line: you use two interfaces (can be sub-interfaces): One MPLS interface (running LDP and your IGP), and one plain-IP interface. Both connect to the P node. You create a static default in the vrf pointing over the IP interface into the global table and create per-vrf NAT statements. int Gig0/0.10 ip address 192.168.0.2 255.255.255.252 mpls ip ip nat inside ! int gig0/0.20 ip address 192.168.10.2 255.255.255.252 ip nat outside ! ip route vrf foo 0.0.0.0 0.0.0.0 Gig0/0.20 192.168.10.1 global ! ip nat pool NAT-foo 10.1.1.1 10.1.1.10 netmask 255.255.255.240 add-route ip nat source list nat-acl-foo pool NAT-foo vrf foo overload ! ip access-list extended nat-acl-foo ! define what should be translated and you define MP-iBGP and advertise the static defaults into the respective VPNs. something like this. the only addtl. challenge is to advertise the NAT pool(s) over the gig0/0.20 interface so you send the return traffic from the Internet back over this outside interface. you could use a dedicated ipv4-bgp session or another IGP instance, for example.. I hope you'll get the idea.. 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/
[c-nsp] EVC - MPLS
Hi Folks, anyone has EVC - MPLS information to share ? any document can I refer to ? regards, Jack___ 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] filter LDP bindings
Saku Ytti mailto:[EMAIL PROTECTED] wrote on Thursday, August 14, 2008 8:17 AM: On (2008-08-13 20:38 +0200), Oliver Boehmer (oboehmer) wrote: well, this dependency on what other LDP neighbors send is not really in-line with the independent control mode LDP operates in, so the implementation might not be straight-forward. I think we have misunderstanding here. All boxes would 'stupidly' accept and readvertise everything they get, no additional states here, plain 'ol ios behaviour without LDP ACL. Well, I think this is the catch: In independent control mode, LDP does not re-advertise something like a distance/path-vector routing protocol does, it advertises its local bindings. So to implement a re-advertise behaviour, one would need to change the local binding behaviour to only allocate (and advertise) a label for a remotely-learned IGP prefix x/y if you already received a remote LDP binding for this prefix or if you're the egress LSR for this FEC.. This is ordered control, something IOS only implements for cell-mode MPLS (i.e. ATM). But per node, you'd tell the nodes not to generate label, except for their loopback. right, this part is simple.. End result would be, that you'd only have loop0̈́s in each MPLS spakers LIBs, without any ACL/prefix-list maintenance overhead. agreed. But I still see challenges getting this right in independent control mode.. Am I missing something? But wouldn't a (prefix) ACL be enough to cover most cases? Generally, loopbacks are allocated from one or more prefix ranges, so ACLs could be rather static? Yes, both can easily accomplish same goal, just bit additional admin overhead, while the true application in virtually all cases is, to generate label for single loopback interface. And actually we would have probably used 'your' way, had it been available when we wanted to implement it, instead of doing advertisement ACLs. I guess so, filtering label allocation is more natural and efficient than filtering the advertisement for this very common case.. 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/
[c-nsp] 1230 Bridging of multiple VLANs
Howdy, I have two 1231G units running 12.3(2)JA3 that I'm attempting to setup as a bridge. Unit #1 uplinks to the FastE interface fine, with standard bridge, ssid and sub-interface stances to yield multiple SSIDs/VLANs on its DotRadio0 (11b) interface - works great. Unit #2 is supposed to connect to Unit #1 over DotRadio1 (11a) as a transparent bridge and continue to advertise the same multiple SSIDs/ VLANs on its other radio - DotRadio0 (11b). After trying a number of configuration combinations, it's unclear if this product generation/IOS version supports multi-VLAN bridging - as the 1400s clearly do. Also, it's a tad unclear what the exact syntax of station-role the bridge interfaces should be in; with the above configuration I assume root bridge on unit #1 and non-root bridge on unit #2 - the examples I find are for slightly different hardware versions. Much appreciate confirmation support exists for this and tips on how to yield my desired configuration - cheers! --Matt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500 snmp and vty acls ?
Matti Saarinen wrote: Are there any examples for replacing VTY ACLs with CoPP that even I could understand? The documentation in CCO isn't helpful enough. Maybe this link helps: http://aharp.ittns.northwestern.edu/papers/copp.html cheers, Thorsten ___ 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] RES: conditional bgp default-originate
On Thu, 14 Aug 2008, Hank Nussbacher wrote: I have tested this and it is working at a specific customer: neighbor 10.100.80.7 default-originate route-map track-Broadwing neighbor 10.100.80.7 distribute-list nothing-else-plus out ! ip access-list extended nothing-else-plus ! Insert any nets you wish to announce here deny ip any any access-list 50 permit 216.140.0.0 0.3.255.255 ! route-map track-Broadwing permit 10 match ip address 50 ! You want to pick a network inside your upstream that will never go away and if it does, that means their backbone has gone down. Do a few traceroutes and you will quickly figure out what are their backbone CIDRs to use. That's basically what I ended up with yesterday in the simulator. My problem with it is, without inside knowledge of my upstream networks, how do I know which routes will never go away or never even just change mask? To be safer, if I end up doing this, I'll probably put half a dozen or so networks from each upstream in the access-list. -- Jon Lewis | 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] CLIPS functionality for DHCP clients
Cisco ISG IOS feature can authenticate MAC in RADIUS. It exists in IOS images for 2800 and 2651XM as well as 7200, 10k, 7600. Eugene. Rubens Kuhl Jr. wrote: I don't think there is any Cisco low-end solution to this; 7200, ASR, 10k and SCE are the platforms I think can do this one way or the other. Consider using Mikrotik or NoCat/NoDog solutions (http://nocat.net/). Rubens On Wed, Aug 13, 2008 at 5:23 PM, Kyle Johnson [EMAIL PROTECTED] wrote: All- I'm trying to create a solution to allow for subscriber management based on client PC MAC address. I see that Redback offers this CLIPS (CPE mac address RADIUS record) method of subscriber management but Redback equipment is pretty pricey... Does anyone have a suggestion on a Cisco equivalent (PPPOE functionality/sessions based off client MAC rather than PPPOE config..) that will run on lower-end gear? Thanks- Kyle ___ 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] RES: conditional bgp default-originate
On Thu, 14 Aug 2008, Jon Lewis wrote: if it does, that means their backbone has gone down. Do a few traceroutes and you will quickly figure out what are their backbone CIDRs to use. That's basically what I ended up with yesterday in the simulator. My problem with it is, without inside knowledge of my upstream networks, how do I know which routes will never go away or never even just change mask? To be safer, if I end up doing this, I'll probably put half a dozen or so networks from each upstream in the access-list. I suggest tracking one block and not a few. Finding the right one takes about 30 minutes of traceroutes from various LGs. -Hank ___ 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] RES: conditional bgp default-originate
On Thu, 14 Aug 2008, Hank Nussbacher wrote: On Thu, 14 Aug 2008, Jon Lewis wrote: That's basically what I ended up with yesterday in the simulator. My problem with it is, without inside knowledge of my upstream networks, how do I know which routes will never go away or never even just change mask? To be safer, if I end up doing this, I'll probably put half a dozen or so networks from each upstream in the access-list. I suggest tracking one block and not a few. Finding the right one takes about 30 minutes of traceroutes from various LGs. Since the access-list only needs to match any single listed route to work, why wouldn't you track several routes to be safer? You can look at a few looking glasses and know that ProviderX will always announce some CIDR with the same netmask? That sounds like a neat trick. Nobody ever deaggregates, right? :) -- Jon Lewis | 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] 32 bit ASN
See my email yesterday. I should have an update on Monday. On Thu, Aug 14, 2008 at 11:40:39AM +0400, Tima Maryin wrote: Hello! Is there any update on this ? Rodney Dunn wrote: I'm asking about this. I'll get back with you. It's going to be in a 12.0(33)S rebuild for sure. But I need to check back on what the 12008 decision was...ie: only in 32S rebuilds? On Mon, Jul 28, 2008 at 12:24:56PM -0700, Troy Beisigl wrote: Hi, Does anyone know if the 32 bit ASN support is going to get implemented in the 12008 or 7500 RSP8 series? If not, what is recommended as replacements? ___ 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] Tele Presence - Priority Queue or CBWFQ within the SP core
Hello there, Wanted to poll the SP folks here to understand what you do in the Core for supporting Tele Presence traffic on LLQ or CBWFQ? Cisco says LLQ but i don't agree because TP is a VBR traffic. And LLQ has its cost implications. Thanks very much for the feedback John ___ 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] VMPS and 6500
Yes, it is correct. It's my understanding that VMPS server will not support on Cat6500 running IOS. Regards, Leung York University Teller, Robert [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 08/13/2008 03:15 PM To cisco-nsp@puck.nether.net cc Subject [c-nsp] VMPS and 6500 I was thinking about playing with VMPS but from what I can tell it's not supported on IOS, is that correct? Robert Teller Washington Dental Service Network Administrator (206) 528-2371 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] # The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. # ___ 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] VMPS and 6500
You may want to look into OpenVMPS or Freeradius (which supports VMPS). You can use one of these products installed on a real server to be your VMPS server. Kyle Samuel Leung wrote: Yes, it is correct. It's my understanding that VMPS server will not support on Cat6500 running IOS. Regards, Leung York University Teller, Robert [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 08/13/2008 03:15 PM To cisco-nsp@puck.nether.net cc Subject [c-nsp] VMPS and 6500 I was thinking about playing with VMPS but from what I can tell it's not supported on IOS, is that correct? Robert Teller Washington Dental Service Network Administrator (206) 528-2371 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] # The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended for the sole use of the individual and entity to whom it is addressed. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this message in error, please e-mail the sender at the above e-mail address. # ___ 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] VRF Lite Route Propagation
I've figured out how to exchange routes between VRF's with the bgp address family configuration coupled with redistribute static|connected, etc however I'm trying to propagate this information and I'm having problems getting it to work as desired. This is a VRF-Lite only environment, and what I'm trying to accomplish is this. I would like to have separate VRF's for separate internet connections, ie a 1 to 1 relationship. I would also like to be able to get this default route from within the Internet 1 VRF into multiple Client Vlan VRF's, as well as dynamically pass the client vlan connected subnets back into the Internet 1 VRF. Exchanging between the VRF's one one router isn't the issue, it's passing it dynamically from Internet 1 VRF to another neighbor router in this same vrf say using OSPF or EIGRP that I'm having trouble with. I get them to show up as B routes via the address family configuration, but I am able to pass this to the neighboring router. I hope this make sense. Thanks in advance, Nick Griffin ___ 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] Cisco authentication login page
Hi all, I'm trying to customize the default login page that the Cisco router uses for authentication proxy ( to autenticate users ). Can someone tell me how to do that ? I've tried to search in the Cisco web site, but it seems that there is no documentation about it. Looking at the default page, i see this strange string: FORM ACTION=/ method=POST target=pxywindow1INPUT TYPE=hidden NAME=au_pxytimetag VALUE=13502936 I think that the au_pxytimetag value shound be different for every message, but i don't know how to do that. Thanks in advance Carlo ___ 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] Tele Presence - Priority Queue or CBWFQ within the SP core
Hi, Wanted to poll the SP folks here to understand what you do in the Core for supporting Tele Presence traffic on LLQ or CBWFQ? Cisco says LLQ but i don't agree because TP is a VBR traffic. And LLQ has its cost implications. Problem with CBWFQ is that while you'll get a min bandwidth guarantee, there's no guarantee for latency and jitter (probably gotta stay within about 1% pkt loss, 30ms jitter max, and 150ms end-to-end latency, of course, for good quality). So, personally I'd use a priority queue with LLQ for TP (actually, a second priority queue, if available). Mark Thanks very much for the feedback John ___ 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] VRF Lite Route Propagation
Nick Griffin wrote: I've figured out how to exchange routes between VRF's with the bgp address family configuration coupled with redistribute static|connected, etc however I'm trying to propagate this information and I'm having problems getting it to work as desired. I'll take a guess at your problem... If you have everything centralized into one PE doing your intra-VRF iBGP, and also providing VRF-specific routing processes... The intra-VRF routes are propagated locally via iBGP and the vrf route-target import/export specifications. To redistributed learned routes from the VRF-specific routing processes into the iBGP mesh, you must 'redistribute [protocol]' in the BGP address-family ipv4 vrf specification. To redistributed learned routes from the iBGP import/export process back into the VRF-specific routing processes, you must 'redistribute bgp [asn]' in the routing process vrf specification. 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/
[c-nsp] route-map continue
Hello! Does anybody can clear for me the continue statement behaviour? router bgp 111 ... neighbor 10.10.10.2 route-map TEST-OUT out neighbor 10.10.10.2 send-community ... route-map TEST-OUT permit 10 match community 10 continue 20 ! route-map TEST-OUT permit 20 set metric 222 set as-path prepend 111 111 111 ! The bgp neighbor receive all prefixes, but community matched are still without prepends and med. Is it correct behaviour? P.S. Tested in 12.2S on 7200 -- Dmitry Kiselev ___ 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] VRF Lite Route Propagation
I must be missing something, see below: C1#sh ip route vrf I1 Gateway of last resort is 1.1.111.1 to network 0.0.0.0 1.0.0.0/24 is subnetted, 1 subnets C 1.1.111.0 is directly connected, Ethernet0/0.111 3.0.0.0/24 is subnetted, 1 subnets B 3.3.3.0 is directly connected, 02:26:01, Ethernet0/0.333 5.0.0.0/24 is subnetted, 1 subnets B 5.5.5.0 is directly connected, 02:26:01, Ethernet0/0.555 Want this in I1 Vrf on R1 O*E2 0.0.0.0/0 [110/1] via 1.1.111.1, 02:26:01, Ethernet0/0.111 C1# router eigrp 1 no auto-summary ! address-family ipv4 vrf VRF3 network 3.3.3.1 0.0.0.0 no auto-summary autonomous-system 1 exit-address-family ! router ospf 1 vrf I1 log-adjacency-changes redistribute static metric 1 subnets redistribute bgp 1 metric 5 subnets --- Do this you said network 1.1.111.2 0.0.0.0 area 0 ! router bgp 1 no synchronization bgp router-id 3.3.3.3 bgp log-neighbor-changes no auto-summary ! address-family ipv4 vrf VRF5 redistribute connected no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf VRF3 redistribute connected no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf I1 redistribute connected redistribute ospf 1 vrf I1 metric 5 match internal external 1 external 2 default-information originate no auto-summary no synchronization exit-address-family R1#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 1.1.111.2 1 FULL/DR 00:00:331.1.111.2 FastEthernet0/0.111 R1#sh ip route vrf I1 Gateway of last resort is 1.1.11.254 to network 0.0.0.0 1.0.0.0/24 is subnetted, 2 subnets C 1.1.11.0 is directly connected, FastEthernet0/0.11 C 1.1.111.0 is directly connected, FastEthernet0/0.111 2.0.0.0/24 is subnetted, 1 subnets S 2.2.2.0 [1/0] via 1.1.12.2 3.0.0.0/24 is subnetted, 1 subnets S 3.3.3.0 [1/0] via 1.1.111.2 S* 0.0.0.0/0 [1/0] via 1.1.11.254 R1#sh ip ospf database OSPF Router with ID (1.1.111.1) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 1.1.111.1 1.1.111.1 15240x8028 0x0072CB 1 1.1.111.2 1.1.111.2 14730x8028 0x00131F 1 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 1.1.111.2 1.1.111.2 14730x8027 0x000F38 Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 0.0.0.0 1.1.111.1 15240x8027 0x00CB4E 1 3.3.3.0 1.1.111.2 141 0x8001 0x000A57 3489660929 5.5.5.0 1.1.111.2 141 0x8001 0x00C199 3489660929 R1# On Thu, Aug 14, 2008 at 10:39 AM, Jeff Kell [EMAIL PROTECTED] wrote: Nick Griffin wrote: I've figured out how to exchange routes between VRF's with the bgp address family configuration coupled with redistribute static|connected, etc however I'm trying to propagate this information and I'm having problems getting it to work as desired. I'll take a guess at your problem... If you have everything centralized into one PE doing your intra-VRF iBGP, and also providing VRF-specific routing processes... The intra-VRF routes are propagated locally via iBGP and the vrf route-target import/export specifications. To redistributed learned routes from the VRF-specific routing processes into the iBGP mesh, you must 'redistribute [protocol]' in the BGP address-family ipv4 vrf specification. To redistributed learned routes from the iBGP import/export process back into the VRF-specific routing processes, you must 'redistribute bgp [asn]' in the routing process vrf specification. 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] Setting up a Internet Gateway (NAT-PE) for MPLS VPNCustomers
We provide customers with a managed CE router on a stick which does NAT and stateful inspection, these may hang off any PE router of our choosing, in reality we implement these as virtual systems on a larger devices with 802.1q trunks to the PE routers. Dave. Oliver Boehmer (oboehmer) wrote: Andy Saykao wrote on Thursday, August 14, 2008 4:58 AM: Hi All We are looking at providing our Layer 3 MPLS VPN customers with the option of a managed internet gateway via a NAT-PE router. This would mean that remote sites no longer have to access the internet via the Central Site model as this is the way we've been implementing Internet access for MPLS VPN customers. As all our MPLS VPN customers are using private IP addresses, NAT would have to obviously take place at the NAT-PE router. [...] My delimma is that I'm not entirely sure which router should be designated as the NAT-PE router to act as the Internet Gateway for our MPLS VPN customers or if we need to put in a new PE router somewhere? So what I've brainstormed are the following ideas... 1/ Do we set the P router up as the NAT-PE router? I'm reluctant to do this because this is the core router that handles Internet traffic for all our customers and I don't want to mess it up. Agreed, I wouldn't take this path either. NAT is stateful, so future scalability is a concern, which is limited if you did this on your core/P node (turning it into a PE). 2/ Can the NAT-PE router be assigned to either PE1 or PE2? If so, I'm unsure how to apply NAT because there is only one interface on the PE router connecting to the P router so I'm not really sure where the ip nat inside and outside command would go - unless we use NAT on a stick which I don't think is recommended in a production environment. I would actually vote for some on-a-stick deployment, which is what many customers do (as far as I know). NPE-G1/G2 are popular platforms for this.. 3/ Lastly, do we need to put in a new router to act as the NAT-PE router? If so, where would this be placed - maybe between the P router and the Internet? I would add a new node, and put it somewhere close to the P router/internet connection. You can scale by adding addtl. routers and distribute your VPN customers across these nodes. The config would be along this line: you use two interfaces (can be sub-interfaces): One MPLS interface (running LDP and your IGP), and one plain-IP interface. Both connect to the P node. You create a static default in the vrf pointing over the IP interface into the global table and create per-vrf NAT statements. int Gig0/0.10 ip address 192.168.0.2 255.255.255.252 mpls ip ip nat inside ! int gig0/0.20 ip address 192.168.10.2 255.255.255.252 ip nat outside ! ip route vrf foo 0.0.0.0 0.0.0.0 Gig0/0.20 192.168.10.1 global ! ip nat pool NAT-foo 10.1.1.1 10.1.1.10 netmask 255.255.255.240 add-route ip nat source list nat-acl-foo pool NAT-foo vrf foo overload ! ip access-list extended nat-acl-foo ! define what should be translated and you define MP-iBGP and advertise the static defaults into the respective VPNs. something like this. the only addtl. challenge is to advertise the NAT pool(s) over the gig0/0.20 interface so you send the return traffic from the Internet back over this outside interface. you could use a dedicated ipv4-bgp session or another IGP instance, for example.. I hope you'll get the idea.. 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/ ___ 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 bgp default-originate
silly question, but why not ask your provider for a default route in with your feed and simply just propagate it downstream?? Dave. Jon Lewis wrote: I'd like to be able to conditionally advertise a default route to customers taking just default routes only if my transit BGP sessions appear to be functional. I thought something like this might work: neighbor 10.1.0.2 default-originate route-map BGP-UP route-map BGP-UP permit 10 match as-path 100 ip as-path access-list 100 permit ^3356_ ip as-path access-list 100 permit ^4323_ But no such luck. Checking the docs at http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2_n1g.html#wp1037042 it seems I have to exactly match against a route for the route-map to work here. That means actually picking a few canary routes I expect to get from my upstreams and hoping they don't go anywhere or change mask. I'm not really happy with that. Are there better ways to do this? Also, while looking at the docs above and experimenting in the GNS3 simulator (emulated 2600s running c2600-i-mz.123-26.bin), I've found a few oddities. First, there's multiple errors in the docs mentioned above. i.e. From the URL above: In the following example, the last line of the configuration has been changed to show the use of an extended access list. The local router injects route 0.0.0.0 to the neighbor 172.16.2.3 only if there is a route to 192.168.0.0 with a mask of 255.255.0.0: router bgp 5 network 172.16.0.0 neighbor 172.16.2.3 remote-as 6 neighbor 172.16.2.3 default-originate route-map default-map ! route-map default-map 10 permit match ip address 1 ! access-list 100 permit ip host 192.168.0.0 host 255.255.255.0 In the above example, they did change the ACL to an extended access-list, but the route-map wasn't updated to use it (still using 1) and they say they're looking for 192.168.0.0 with a mask of 255.255.0.0, but the access-list 100 uses a /24 mask. Just above this example, the docs say that access-list 1 permit 192.168.0.0 will match a route for 192.168.0.0 with any mask. In my simulator, I have R1--R2--R3 R1 advertises 8.0.0.0/16 to R2. R2 is advertising a conditional default to R3 using the route-map route-map BGP-UP permit 10 match ip address 50 access-list 50 permit 8.0.0.0 When R2 receives 8.0.0.0/16 from R1, there are no hits on the ACL and default is not sent ot R3. If I add to access-list 50 access-list 50 permit 8.0.0.0 0.0.255.255 Standard IP access list 50 10 permit 8.0.0.0 (973 matches) 20 permit 8.0.0.0, wildcard bits 0.0.255.255 I get hits on the permit 8.0.0.0 line now, and default is sent to R3. This seems kind of broken. I haven't duplicated the setup with real hardware to see if it's a simulator screwup...but since the simulator is running actual IOS, it seems unlikely the simulator is to blame. -- Jon Lewis | 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] conditional bgp default-originate
On Thu, 14 Aug 2008, David Freedman wrote: silly question, but why not ask your provider for a default route in with your feed and simply just propagate it downstream?? I don't need/want a default route. If a destination isn't in the global routing table, I don't want to send the packets upstream. I suppose your suggestion is the easiest solution though. -- Jon Lewis | 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] filter LDP bindings
On (2008-08-14 09:41 +0200), Oliver Boehmer (oboehmer) wrote: Well, I think this is the catch: In independent control mode, LDP does not re-advertise something like a distance/path-vector routing protocol does, it advertises its local bindings. So to implement a re-advertise behaviour, one would need to change the local binding behaviour to only allocate (and advertise) a label for a remotely-learned IGP prefix x/y if you already received a remote LDP binding for this prefix or if you're the egress LSR for this FEC.. This is ordered control, something IOS only implements for cell-mode MPLS (i.e. ATM). End result would be, that you'd only have loop0̈́s in each MPLS spakers LIBs, without any ACL/prefix-list maintenance overhead. agreed. But I still see challenges getting this right in independent control mode.. Am I missing something? Perhaps I mistook that it would be easier than in reality it is, to determine this information from LIB. I assumed that creating bindings perfectly normally for data received over LDP session is no-problem and only thing that needs to change, is that in first place, you don't locally add anything to your bindings, except your Loop0. I guess so, filtering label allocation is more natural and efficient than filtering the advertisement for this very common case.. Yes (more natural than ACL filtering what you advertise out). -- ++ytti ___ 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] route-map continue
On Thu, 2008-08-14 at 18:18 +0300, Dmitry Kiselev wrote: Hello! Does anybody can clear for me the continue statement behaviour? router bgp 111 ... neighbor 10.10.10.2 route-map TEST-OUT out neighbor 10.10.10.2 send-community ... route-map TEST-OUT permit 10 match community 10 continue 20 ! route-map TEST-OUT permit 20 set metric 222 set as-path prepend 111 111 111 ! The bgp neighbor receive all prefixes, but community matched are still without prepends and med. Is it correct behaviour? P.S. Tested in 12.2S on 7200 According to FN you need 12.2SRC or 12.4T for outbound route-map continue support. Regards, 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] route-map continue
On Thu, 2008-08-14 at 20:38 +0200, Peter Rathlev wrote: On Thu, 2008-08-14 at 18:18 +0300, Dmitry Kiselev wrote: P.S. Tested in 12.2S on 7200 According to FN you need 12.2SRC or 12.4T for outbound route-map continue support. SRB should also work by the way. Regards, 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] route-map continue
i was thinking the problem was 'outbound' maps, but then when double checking i saw this Restrictions for BGP Route-Map Continue •Continue clauses are supported in outbound route maps only in Cisco IOS Release 12.0(31)S and subsequent releases. http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/cs_brmcs.html On Thu, Aug 14, 2008 at 2:38 PM, Peter Rathlev [EMAIL PROTECTED] wrote: On Thu, 2008-08-14 at 18:18 +0300, Dmitry Kiselev wrote: Hello! Does anybody can clear for me the continue statement behaviour? router bgp 111 ... neighbor 10.10.10.2 route-map TEST-OUT out neighbor 10.10.10.2 send-community ... route-map TEST-OUT permit 10 match community 10 continue 20 ! route-map TEST-OUT permit 20 set metric 222 set as-path prepend 111 111 111 ! The bgp neighbor receive all prefixes, but community matched are still without prepends and med. Is it correct behaviour? P.S. Tested in 12.2S on 7200 According to FN you need 12.2SRC or 12.4T for outbound route-map continue support. Regards, 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/ ___ 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] route-map continue
Christian Koch wrote: i was thinking the problem was 'outbound' maps, but then when double checking i saw this Restrictions for BGP Route-Map Continue •Continue clauses are supported in outbound route maps only in Cisco IOS Release 12.0(31)S and subsequent releases. http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/cs_brmcs.html Don't (totally) believe the feature guides. 12.0(32)S is the minimum safe release, due to the following bug that bit me hard: CSCsc36517 Symptoms: A router reloads unexpectedly when a continue statement is used in an outbound route map. Conditions: This symptom is observed on a Cisco router that is configured for BGP. Workaround: There is no workaround. On 7507s and 12008s, the outbound continue was 100% dangerous every time I used it, no matter how simple the route-map. pt ___ 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] VRF Lite Route Propagation
Can you do a show run int Ethernet0/0.555 and show ip bgp vpnv4 vrf I1? -Luan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Griffin Sent: Thursday, August 14, 2008 12:27 PM To: Jeff Kell Cc: cisco-nsp Subject: Re: [c-nsp] VRF Lite Route Propagation I must be missing something, see below: C1#sh ip route vrf I1 Gateway of last resort is 1.1.111.1 to network 0.0.0.0 1.0.0.0/24 is subnetted, 1 subnets C 1.1.111.0 is directly connected, Ethernet0/0.111 3.0.0.0/24 is subnetted, 1 subnets B 3.3.3.0 is directly connected, 02:26:01, Ethernet0/0.333 5.0.0.0/24 is subnetted, 1 subnets B 5.5.5.0 is directly connected, 02:26:01, Ethernet0/0.555 Want this in I1 Vrf on R1 O*E2 0.0.0.0/0 [110/1] via 1.1.111.1, 02:26:01, Ethernet0/0.111 C1# router eigrp 1 no auto-summary ! address-family ipv4 vrf VRF3 network 3.3.3.1 0.0.0.0 no auto-summary autonomous-system 1 exit-address-family ! router ospf 1 vrf I1 log-adjacency-changes redistribute static metric 1 subnets redistribute bgp 1 metric 5 subnets --- Do this you said network 1.1.111.2 0.0.0.0 area 0 ! router bgp 1 no synchronization bgp router-id 3.3.3.3 bgp log-neighbor-changes no auto-summary ! address-family ipv4 vrf VRF5 redistribute connected no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf VRF3 redistribute connected no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf I1 redistribute connected redistribute ospf 1 vrf I1 metric 5 match internal external 1 external 2 default-information originate no auto-summary no synchronization exit-address-family R1#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 1.1.111.2 1 FULL/DR 00:00:331.1.111.2 FastEthernet0/0.111 R1#sh ip route vrf I1 Gateway of last resort is 1.1.11.254 to network 0.0.0.0 1.0.0.0/24 is subnetted, 2 subnets C 1.1.11.0 is directly connected, FastEthernet0/0.11 C 1.1.111.0 is directly connected, FastEthernet0/0.111 2.0.0.0/24 is subnetted, 1 subnets S 2.2.2.0 [1/0] via 1.1.12.2 3.0.0.0/24 is subnetted, 1 subnets S 3.3.3.0 [1/0] via 1.1.111.2 S* 0.0.0.0/0 [1/0] via 1.1.11.254 R1#sh ip ospf database OSPF Router with ID (1.1.111.1) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 1.1.111.1 1.1.111.1 15240x8028 0x0072CB 1 1.1.111.2 1.1.111.2 14730x8028 0x00131F 1 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 1.1.111.2 1.1.111.2 14730x8027 0x000F38 Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 0.0.0.0 1.1.111.1 15240x8027 0x00CB4E 1 3.3.3.0 1.1.111.2 141 0x8001 0x000A57 3489660929 5.5.5.0 1.1.111.2 141 0x8001 0x00C199 3489660929 R1# On Thu, Aug 14, 2008 at 10:39 AM, Jeff Kell [EMAIL PROTECTED] wrote: Nick Griffin wrote: I've figured out how to exchange routes between VRF's with the bgp address family configuration coupled with redistribute static|connected, etc however I'm trying to propagate this information and I'm having problems getting it to work as desired. I'll take a guess at your problem... If you have everything centralized into one PE doing your intra-VRF iBGP, and also providing VRF-specific routing processes... The intra-VRF routes are propagated locally via iBGP and the vrf route-target import/export specifications. To redistributed learned routes from the VRF-specific routing processes into the iBGP mesh, you must 'redistribute [protocol]' in the BGP address-family ipv4 vrf specification. To redistributed learned routes from the iBGP import/export process back into the VRF-specific routing processes, you must 'redistribute bgp [asn]' in the routing process vrf specification. 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] Cisco authentication login page
I'm trying to customize the default login page that the Cisco router uses for authentication proxy ( to autenticate users ). Can someone tell me how to do that ? I've tried to search in the Cisco web site, but it seems that there is no documentation about it. Looking at the default page, i see this strange string: FORM ACTION=/ method=POST target=pxywindow1INPUT TYPE=hidden NAME=au_pxytimetag VALUE=13502936 I think that the au_pxytimetag value shound be different for every message, but i don't know how to do that. When I played with this a while back I couldn't find a way to customise the bit of HTML you have there - it is produced by IOS. I'm not sure why you'd want to modify the au_pxytimetag value - it seems to work fine for me with multiple users without having to change that. I wrote a bit of custom HTML that the router then serves up before the FORM part of the HTML page is sent back to the client. The only limitation was that the HTML I provided had to be under 8k (may have been 4k) so because the disclaimer we had was so large I embedded an IFRAME which sourced the disclaimer from another web server. Documentation: http://www.cisco.com/en/US/partner/products/sw/secursw/ps1018/products_confi guration_example09186a0080094655.shtml B. ___ 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] Cisco Security Advisory: Vulnerability in Cisco WebEx Meeting Manager ActiveX Control
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Vulnerability in Cisco WebEx Meeting Manager ActiveX Control Advisory ID: cisco-sa-20080814-webex Revision 1.0 For Public Release 2008 August 14 2230 UTC (GMT) +- Summary === An ActiveX control (atucfobj.dll) that is used by the Cisco WebEx Meeting Manager contains a buffer overflow vulnerability that may result in a denial of service or remote code execution. The WebEx Meeting Manager is a client-side program that is provided by the Cisco WebEx meeting service. The Cisco WebEx meeting service automatically downloads, installs, and configures Meeting Manager the first time a user begins or joins a meeting. When users connect to the WebEx meeting service, the WebEx Meeting Manager is automatically upgraded to the latest version. There is a manual workaround available for users who are not able to connect to the WebEx meeting service. Cisco WebEx is in the process of upgrading the meeting service infrastructure with fixed versions of the affected file. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20080814-webex.shtml Affected Products = Vulnerable Products +-- The WebEx Meeting Manager downloads several components to meeting participants before they join a WebEx meeting. The vulnerability in this Security Advisory affects the atucfobj.dll library. Products Confirmed Not Vulnerable + No other Cisco products are currently known to be affected by this vulnerability. Details === The WebEx meeting service is a hosted multimedia conferencing solution that is managed by and maintained by Cisco WebEx. When a meeting participant connects to the WebEx meeting service through a web browser, the WebEx meeting service installs several components of the WebEx Meeting Manager browser plugin on the meeting participant's system. WebEx Meeting Manager includes atucfobj.dll, a DLL that allows meeting participants to view Unicode fonts. This library contains a buffer overflow vulnerability that could allow an attacker to execute arbitrary code. The WebEx meeting service currently maintains three different versions of software. WebEx meeting service servers run one of the following versions: WBS 23, WBS 25, or WBS 26. This vulnerability is documented in WebEx Bug IDs 292551 for WBS 26 and 306639 for WBS 25. This vulnerability has been assigned Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-2737. Identifying WebEx Meeting Service Version + The following procedure allows meeting participants to identify the version of client software that is provided by a WebEx server. The procedure varies slightly depending on the version of the WebEx server software. The URL in all the following examples is provided to meeting participants as part of the WebEx meeting invite. Client build numbers adhere to the format of XX.YY.ZZ.. The first number indicates the major version number of the software build. For example, a client build number of 26.49.9.2838 indicates a WBS 26-based software version. For the WBS 26 version: 1. Browse to the WebEx meeting server at https://servername.webex.com/. 2. Select Support from the left side of the web page. 3. Select Downloads from the left side of the web page. 4. The version of the client software that is provided by the server is listed next to Client build. For WebEx servers that are running WBS 26, the first fixed version is 26.49.9.2838. Client build versions prior to 26.49.9.2838 are vulnerable. For the WBS 25 version: 1. Browse to the WebEx meeting server at https://servername.webex.com/. 2. Select Assistant on the left side of the page. 3. Select the Support link. 4. Select the Version link, which is displayed on the right side of the top of the page. 5. The Client Build version is displayed in a pop-up window. There is currently no fixed version for the WBS 25-based WebEx meeting service. This section of the Security Advisory will be updated when fixed version information is available. For the WBS 23 version: Servers that run WBS 23-based WebEx meeting service display version information using the following URL format: https://servername.webex.com/version/wbxversionlist.do?siteurl=servername On the redisplayed page the Client versions in files field will indicate the Client Build. For example: The 'T23' in WBXclient-T23L10NSP33EP13-1092.txt indicates a WBS 23-based system. Cisco WebEx is not planning to repair WBS 23-based software. Affected WBS 23-based servers will be upgraded to fixed WBS 25 or WBS 26-based software. Attack Vector Details + This Security Advisory addresses a vulnerable ActiveX control (atucfobj.dll). If atucfobj.dll is present on a client's computer, it may be possible
[c-nsp] best way to load share adsl
Hello, I would like to setup load sharing on a 2621 for three adsl lines. Currently each of the adsl connections has a modem/router combo which is doing nat. All I need for the cisco router to do is load sharing or load balancing. What would be the best way to do this and could anyone recommend some documentation or a config? Thanks, Dan. ___ 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] 3560 ACL performance?
Hi So the marketing machine tells me 3650s do ACLs in hardware and zero performance hit blah blah. Anyone had any real world experience with high loads of packets on every interface under a simple ACL? Thanks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 ACL performance?
On Thu, Aug 14, 2008, Christian MacNevin wrote: Hi So the marketing machine tells me 3650s do ACLs in hardware and zero performance hit blah blah. Anyone had any real world experience with high loads of packets on every interface under a simple ACL? they perform like the 3550's - It Just Works. Just make sure simple ACL translates to is 100% programmed in hardware. (I've done this on 3550, 3560, 3750, 10/100/1000 ports.) Adrian ___ 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] 3560 ACL performance?
How do I know what's programmed in hardware? We're using basic ip lists blocking netbios ports. On Aug 14, 2008, at 9:40 PM, Adrian Chadd wrote: On Thu, Aug 14, 2008, Christian MacNevin wrote: Hi So the marketing machine tells me 3650s do ACLs in hardware and zero performance hit blah blah. Anyone had any real world experience with high loads of packets on every interface under a simple ACL? they perform like the 3550's - It Just Works. Just make sure simple ACL translates to is 100% programmed in hardware. (I've done this on 3550, 3560, 3750, 10/100/1000 ports.) Adrian ___ 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] best way to load share adsl
Dan, Take a look at this one: http://www.cisco.com/en/US/docs/ios/oer/configuration/guide/12_4t/oer_12 _4t_book.html Arie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Letkeman Sent: Friday, August 15, 2008 06:33 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] best way to load share adsl Hello, I would like to setup load sharing on a 2621 for three adsl lines. Currently each of the adsl connections has a modem/router combo which is doing nat. All I need for the cisco router to do is load sharing or load balancing. What would be the best way to do this and could anyone recommend some documentation or a config? Thanks, Dan. ___ 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/
