RE: NAT with printer [7:38781]
What does your access list look like that controls what gets NAT'd to the 192.168.8.0 pool? Is the printer excluded from this NAT list? What is the default gateway of the printer? Arjen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: March 19, 2002 9:44 AM To: [EMAIL PROTECTED] Subject: RE: NAT with printer [7:38781] Yes. This is a network printer with a card. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38790&t=38781 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: NAT with printer [7:38781]
The ACL is backwards. Is the server running a routing engine? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: March 19, 2002 10:16 AM To: [EMAIL PROTECTED] Subject: RE: NAT with printer [7:38781] Hi, I have excluded the printer from the NAT pool through access-list only. Here is what I have for the configuration: ip nat pool ippool 192.168.8.1 192.168.8.254 netmask 255.255.255.0 ip nat inside source list 7 pool ippool access-list 7 permit 192.168.3.0 0.0.0.255 access-list 7 deny host 192.168.3.252 The gateway on the printer points to a server which has the routing to the other network. Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38795&t=38781 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: NAT with printer [7:38781]
Yes, change the default gateway of the printer to be router2. And before you go too far with this NAT/printer thing, make sure that you can ping the printer from its local network. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: March 19, 2002 10:34 AM To: [EMAIL PROTECTED] Subject: RE: NAT with printer [7:38781] What do you mean by routing engine? I can ping the server from the other network. The server has routing information. Do I have to change the gateway on the printer to point the router? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38806&t=38781 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: 3015 VPN Concentrator & MTU's [7:39010]
This sounds somewhat like this link: The quick summary is that the payload size can be a maximum of 1492 over PPPoE. This is due to the PPPoE header size + a PPP ID. One would think though that the Netopia box has been designed to take this into account. Is the 3015 negotiating packet sizes greater than 1492? Hope it helps. Arjen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Armstrong Sent: March 21, 2002 1:31 PM To: [EMAIL PROTECTED] Subject: Re: 3015 VPN Concentrator & MTU's [7:39010] Unfortunately the Netopia's MTU size can't be changed so nothing is an option. I'm interested in your thought on which side needs changing though. Packets larger than (somewhere around) 1400 bits can't traverse the Netoia R9100 but can traverse the 3015 VPN Concentrator. To me that would seem to mean that the size of the packets sent from the 3015 to the Netopia are too large for the Netopia. Increasing the Netopia's MTU would allow it to see larger frames and therefore not fragment them as they come across. Since I'm able to sit on the Netopia and send packets across the 3015 into our network but am unable to send them from inside the Netopia's network across to the 3015 it seems that the problem is stemming from too small MTU size on the Netopia (packet comes to the inside interface of the Netopia R9100, is encapsulated and framed with an IPSec header added to the frame for encryption then sent to the outside interface of the Netopia. The outside interface fragments frames greater than 1500 bits and thus sends fragments out the DSL modem into the Internet - I think). I could be thinking in the wrong direction though and if I am would like to get thinking in the right. Currently it doesn't appear that I can decrease or increase MTU size on either device which leaves me thinking that my options are two: get a router to replace the Netopia that allows changes to MTU or change the settings for IPSec to decerase the size of the header it adds to the packet when the frame is created. I'm focusing on the second now. I need to get a better understanding of the components of IPSec first though. Thanks for you input, David Armstrong ""Daniel Cotts"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Seems that you need to decrease the MTU on the client (Netopia) side rather > than increase it. > > > -Original Message- > > From: David Armstrong [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, March 20, 2002 11:17 PM > > To: [EMAIL PROTECTED] > > Subject: 3015 VPN Concentrator & MTU's [7:39010] > > > > > > We have a 3015 VPN concentrator that I've connected to a > > vendor who has a > > Netopia R9100 router with a DSL (PPOE) connection to the Internet. The > > tunnel is fine but anything larger than ICMP dies. From > > talking to Netopia's > > tech support the problem is that the Netoia R9100 with PPOE > > supports MTU's > > of 1500 bits and can't be increased. I've sent pings with larger data > > packets and, sure enough, they died too. Given the vendor's > > equipment the > > solution appears to be to decrease MTU size on the 3015; > > however, I can't > > find a way to do this. > > > > Does anyone have any suggestions? > > > > Thanks, > > > > David Armstrong Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39091&t=39010 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: 3015 VPN Concentrator & MTU's [7:39010]
Sorry - the link is rather missing! cisco.com/warp/customer/794/pppoe_arch.html Arjen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Arjen Dragt Sent: March 21, 2002 4:54 PM To: [EMAIL PROTECTED] Subject: RE: 3015 VPN Concentrator & MTU's [7:39010] This sounds somewhat like this link: The quick summary is that the payload size can be a maximum of 1492 over PPPoE. This is due to the PPPoE header size + a PPP ID. One would think though that the Netopia box has been designed to take this into account. Is the 3015 negotiating packet sizes greater than 1492? Hope it helps. Arjen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Armstrong Sent: March 21, 2002 1:31 PM To: [EMAIL PROTECTED] Subject: Re: 3015 VPN Concentrator & MTU's [7:39010] Unfortunately the Netopia's MTU size can't be changed so nothing is an option. I'm interested in your thought on which side needs changing though. Packets larger than (somewhere around) 1400 bits can't traverse the Netoia R9100 but can traverse the 3015 VPN Concentrator. To me that would seem to mean that the size of the packets sent from the 3015 to the Netopia are too large for the Netopia. Increasing the Netopia's MTU would allow it to see larger frames and therefore not fragment them as they come across. Since I'm able to sit on the Netopia and send packets across the 3015 into our network but am unable to send them from inside the Netopia's network across to the 3015 it seems that the problem is stemming from too small MTU size on the Netopia (packet comes to the inside interface of the Netopia R9100, is encapsulated and framed with an IPSec header added to the frame for encryption then sent to the outside interface of the Netopia. The outside interface fragments frames greater than 1500 bits and thus sends fragments out the DSL modem into the Internet - I think). I could be thinking in the wrong direction though and if I am would like to get thinking in the right. Currently it doesn't appear that I can decrease or increase MTU size on either device which leaves me thinking that my options are two: get a router to replace the Netopia that allows changes to MTU or change the settings for IPSec to decerase the size of the header it adds to the packet when the frame is created. I'm focusing on the second now. I need to get a better understanding of the components of IPSec first though. Thanks for you input, David Armstrong ""Daniel Cotts"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Seems that you need to decrease the MTU on the client (Netopia) side rather > than increase it. > > > -Original Message- > > From: David Armstrong [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, March 20, 2002 11:17 PM > > To: [EMAIL PROTECTED] > > Subject: 3015 VPN Concentrator & MTU's [7:39010] > > > > > > We have a 3015 VPN concentrator that I've connected to a > > vendor who has a > > Netopia R9100 router with a DSL (PPOE) connection to the Internet. The > > tunnel is fine but anything larger than ICMP dies. From > > talking to Netopia's > > tech support the problem is that the Netoia R9100 with PPOE > > supports MTU's > > of 1500 bits and can't be increased. I've sent pings with larger data > > packets and, sure enough, they died too. Given the vendor's > > equipment the > > solution appears to be to decrease MTU size on the 3015; > > however, I can't > > find a way to do this. > > > > Does anyone have any suggestions? > > > > Thanks, > > > > David Armstrong Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39093&t=39010 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: VTP Servers [7:39083]
Careful about the "...configure it as a VTP client and the world will be a safe place." statement. From CCO (all the following text is from CCO - no comments needed): Link (watch wrap): cisco.com/warp/public/473/21.html#How%20a%20newly%20inserted%20switch%20can% 20mess%20up%20a%20network%20? How a Recently-Inserted Switch Can Cause Network Problems This problem occurs when you have a large switched domain, which is all in the same VTP domain, and you want to add one switch in the network. This switch was previously used in the lab and a good VTP domain name was entered. It was configured as a VTP client, and connected to the rest of the network. Then, the ISL link was brought up to the rest of the network. In just a few seconds, the whole network is down. What could have happened? The configuration revision of the switch you inserted was higher than the configuration revision of the VTP domain. Therefore, your recently-introduced switch, with almost no configured VLANs, has erased all VLANs through the VTP domain. This will happen whether the switch is a VTP client or a VTP server. A VTP client can erase VLAN information on a VTP server. You will know that this has happened when many of the ports in your network go into inactive state, but continue to be assigned to a non-existing VLAN. Cheers! Arjen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Ford Sent: March 21, 2002 4:38 PM To: [EMAIL PROTECTED] Subject: RE: VTP Servers [7:39083] Almost right. If both servers are in the same VTP domain, the one whose configuration counter is highest will propogate it's VLANs. This means that if you add a server that's been sitting in your lab and it has a higher configuration counter, you will lose the VLANs on your current switch. If the switch is not going to be a core switch, configure it as a VTP client and the world will be a safe place. If it does have a higher configuration counter, change it's VTP domain to a different name and then change it back. It's counter will go back to zero. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeffrey Reed Sent: Thursday, March 21, 2002 2:27 PM To: [EMAIL PROTECTED] Subject: VTP Servers [7:39083] If I have an existing VTP domain server with many VLANs configured and then add another VTP server does the first server update the new server? No chance of the new server updating the old server and wiping out the VTP database, right? Thanks!! Jeff Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39095&t=39083 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: More VTP Questions [7:39131]
Jeff, If you are going to (must) use VLANs, they should never extend beyond the distribution layer. That is, a VLAN may exist in the access layer (possibly across more than one A/L switch) but should terminate at the D/L. Beyond the D/L into the core, the network is to be purely routed/switched with no VLAN activity (there are exceptions to this with a switched core in which you may want to set up VLANs - routed core is often preferred. Even in this exception case, these "core VLANs are different VLANs than in the A/L). Whether any trunking is needed is probably a more important question: It sounds (from your wording) that this is a fresh design - if you do not have to trunk VLANs (with "have to=must" being the operative words), then the best design going these days is to put one VLAN per A/L switch; each VLAN corresponds directly to a separate subnet. On the D/L switches, there are multiple routed interfaces (subinterfaces) each performing routing for the individual subnets corresponding to the A/L switches. In this manner, your entire network is essentially routed (hosts connecting down to their D/L switch are switched, yes, but they are only in their own subnet) and you don't have to worry about anything to do with VTP or STP. So, here is a one line summary: If you don't absolutely need to use VLANs, don't: route. Cheers, Arjen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeffrey Reed Sent: March 22, 2002 5:26 AM To: [EMAIL PROTECTED] Subject: More VTP Questions [7:39131] Thanks to everyone who helped clarify the VTP Domain process and I have more questions. I am working on a textbook Cisco network design. We have two 6509s in the core, four 6509s in the distribution layer and about 30 6509s at the access layer. We also have two Server Farm 6509s hanging off the core switches. The core and distribution will route and well switch to the server farm and the access layers. Well have about 4-5 VLANs in each access layer, so well over 100 VLANs total. Hence my strong interest in VTP. Reading through the VTP stuff today, I saw where the VTP communication occurs through VLAN1. The reseller who sold the design said we would have multi-path layer3 connectivity between core and distribution and layer 2 out to access 6509s. Assuming we only had routed links between the core and distribution layers, then how would the VTP updates get through to the distribution layer from the core? Can we effectively have both a routed link and a bridged VLAN1 link throughout the network? Does that make sense? Any suggestions on how this is accomplished with one VTP domain or a better way would be appreciated. Jeff Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39152&t=39131 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
