My point about the VPN concentrator was in a different email. I was mentioning the VPN concentrator for those taking the CSVPN test for the CSS1. Maybe I should have changed the heading, to make it politically correct. I am sure people going for the VPN test will appreciate this if they see it on their exam. I was trying to get this conversation back on what we are all here for, Cisco related products.
Your point about analyzing user requirements is mute. There was not enough detail to perform an evaluation. That would be the answer to this question. I was just taking a shot in the dark, just like everyone else. This would be a bad example to see if someone could analyze network requirements. If it was a credible question, this would apply. -----Original Message----- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 1:37 PM To: [EMAIL PROTECTED] Subject: RE: Cisco PIX & Novell [7:51303] Brian Zeitz wrote: > > He may need to encapsulate the IPX into TCP/IP. Cisco only > supports IP > on the VPN3000 concentrator. Maybe a good test question for us > taking > the CSS1 exams. The VPN 5000 will support IPX. > > It might be a good design question to see if the test-taker can analyze user requirements. He didn't say anything about having a VPN concentrator. In fact, he's not trying to do a VPN, I don't think. He's just trying to get ordinary client/server traffic to work through the PIX 525. Also, he's using IP, not IPX. On the other hand, I have to somewhat agree with some of your other message about NetWare being overly complex and requiring too much tinkering to get it working. I tried to find an answer to the actual question on the Novell Web site and the servers were excruciatingly slow to start with and there was nothing useful on the particular question (of getting NetWare client to talk to NetWare 5.1 server with IP as the preferred method across a PIX firewall). The original poster said that the client talks to a Directory Agent (DA) first. This implies that Service Location Protocol (SLP) is in use, but that multicasts are not required for finding services. A DA minimizes the requirement for multicasts. SLP user and service agents can find the DA via multicast, (if they don't hear from it first), but once they do find the DA, they can send unicasts directly to the DA. It sounds like the client is finding the DA fine and the DA is giving the client a server to use, but then the failure occurs. Is there a way for him to avoid SLP and specify the actual server? Can't he just do this with an IP address (or name assuming DNS is working?) I noticed that Chuck Church is back. (Yeah!) Maybe he can help? :-) Thanks Priscilla Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=51383&t=51303 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
