Still struggling to set up this EVPL. Can someone help?

tdean

Still having strange problems at both sites. At the main site, where all the AD servers etc are. Do i need to add anything to the router config for dns, netbios, wins or anything? I am using the router as default gateway, but we have a seperate DNS/WINS/DHCP servers there. People are having trouble sending mail in Outlook and the error points to a potential DNS/WINS issue.

it_consultant

I would look to make sure that on the routers passing connections over the tunnels you have an "allow any any" statement on your last ACL as opposed to the standard "deny any any". All that being true the Exchange server may not be set up correctly.

tdean

it_consultant wrote: »

I would look to make sure that on the routers passing connections over the tunnels you have an "allow any any" statement on your last ACL as opposed to the standard "deny any any". All that being true the Exchange server may not be set up correctly.

its POP... i think i found the problem. when i telnet into my smtp mail i get 220******* back. i think this will fix it. i will let you know.

To turn off the Mailguard feature of the PIX or ASA firewall:

1. Log on to the PIX or ASA firewall by establishing a telnet session or by using the console.
2. Type enable, and then press ENTER.
3. When you are prompted for your password, type your password, and then press ENTER.
4. Type configure terminal, and then press ENTER.
5. Type no fixup protocol smtp 25, and then press ENTER.
6. Type write memory, and then press ENTER.
7. Restart or reload the PIX or ASA firewall.

tdean

Seems esmtp was causing the issue. I did this and mail is working now:

>> yourfirewall# show running-config policy-map
>>
>> If there's anything about esmtp in there, you can disable it with:
>>
>> yourfirewall# configure terminal
>> yourfirewall(config)# policy-map global_policy
>> yourfirewall(config-pmap)# class inspection_default
>> yourfirewall(config-pmap-c)# no inspect esmtp

tdean

hmmm, now the remote site users are complaing that they are getting an error today that reads " Your IP address lease has expired. DHCP was unable to renew your lease." but they click ok and they are able to login just fine. Any ideas why this would be popping up? This is a nightmare.

it_consultant

I haven't had to run a "no fixup" command in a long while. It sounds like it is possible that the clients at the remote site actually got DHCP leases from the other side of the EVPL tunnel and when they went to renew, they were unable to renew for one reason or another. They found another DHCP server and were off to the races. Without really inspecting your environment it would be hard for us to figure out what is going on with these other issues that are coming up.

tdean

it_consultant wrote: »

I haven't had to run a "no fixup" command in a long while. It sounds like it is possible that the clients at the remote site actually got DHCP leases from the other side of the EVPL tunnel and when they went to renew, they were unable to renew for one reason or another. They found another DHCP server and were off to the races. Without really inspecting your environment it would be hard for us to figure out what is going on with these other issues that are coming up.

Hmmm... yeah. maybe still running on their old IP lease.... I know its hard. I appologize. I do the best i can, we have 3 locations and i'm the only one trying to keep everything running. I can only go by what the managers send me in email, and its rarely accurate.

it_consultant

tdean wrote: »

Hmmm... yeah. maybe still running on their old IP lease.... I know its hard. I appologize. I do the best i can, we have 3 locations and i'm the only one trying to keep everything running. I can only go by what the managers send me in email, and its rarely accurate.

Believe me, nothing I EVER get from users is accurate. This has been a challenging implementation, but you are learning. We get these stupid little issues that pop up that we need to solve. In my metro ethernet implementation, there was a bug we found in the software of our ISP's equipment that causes their devices to hold MAC addresses in their CPE for 2 - 2.5 hours. When someone goes from office to office (if they were on the same back end core switch) when they arrive a the new office their traffic would be suppressed by the CPE to prevent a broadcast storm. The manufacturer released a fix which broke SNMP reporting. This is what we get paid the big bucks for!

it_consultant

Oh, and we recently nailed in another point on our metro ethernet connection. After that happened our networks got all screwy, devices right next to each other and on the same switch couldn't ping each other. Turns out a device at the colo we nailed in was responding to all ARPs. It took me three weeks to convince them there was a problem and 10 minutes to issue a "no proxy arp" command on the router I identified for them!

tdean

it_consultant wrote: »

Believe me, nothing I EVER get from users is accurate. This has been a challenging implementation, but you are learning. We get these stupid little issues that pop up that we need to solve. In my metro ethernet implementation, there was a bug we found in the software of our ISP's equipment that causes their devices to hold MAC addresses in their CPE for 2 - 2.5 hours. When someone goes from office to office (if they were on the same back end core switch) when they arrive a the new office their traffic would be suppressed by the CPE to prevent a broadcast storm. The manufacturer released a fix which broke SNMP reporting. This is what we get paid the big bucks for!

and i though my stupid point to point was confusing!

tdean

it_consultant wrote: »

Oh, and we recently nailed in another point on our metro ethernet connection. After that happened our networks got all screwy, devices right next to each other and on the same switch couldn't ping each other. Turns out a device at the colo we nailed in was responding to all ARPs. It took me three weeks to convince them there was a problem and 10 minutes to issue a "no proxy arp" command on the router I identified for them!

that must have been a pleasant 3 weeks. lol. good call though.

tdean

Heres a perfect example of what i have to deal with... The practice MGR at the other site emails me (and cc's the CEO) every single night to tell me the "network is down" and asking me "what are you doing??" b/c she is getting disconnected from home while on the SSL VPN. as it turns out, she was leaving it open at home and getting disconnected due to inactivity.

it_consultant

Is this a medical office? The non-doctors and nurses at medical offices can be the worst to deal with. Physicians can be demanding A$$es but they are at least intelligent enough to sit though an explanation without getting frustrated.

tdean

it_consultant wrote: »

Is this a medical office? The non-doctors and nurses at medical offices can be the worst to deal with. Physicians can be demanding A$$es but they are at least intelligent enough to sit though an explanation without getting frustrated.

yeah, a cardio vascular practice. 3 sites, (~250 people at each main site and 50 at the smaller one) affiliated with 2 major hospitals. there was absolutely no documantation here when i took over, so its been quite the learning expereince. we use so many med related apps here that when one crashes or if someone cant login.... "The network is down!!!"

the Dr's are a strange group... brilliant in one area....but man, not so good at computers. lol.