im sorry to link you to something right off the bat, but it is a long subject and has been an ongoing issue and i cant type it again. if anyone can help, it would be appreciated.
this problem didnt start till we switched from ATM/IMA connection for backbone, to a DS3 connection. it isnt the Cisco router, persay, but could be a configuration that i am not able to figure out.
Thats a lot of reading. I skimmed through it. Can you provide a little character string diagram of the components involved and where you were sniffing.
Personally I would snif at the router that is supplying the DHCP response. If you could plug the router into a 100M switch and span the port to your sniffer you could see exactly what is happening there. If you have a duplex mismatch different equipment may get different results. Also a rule of thumb. If you hard code duplex and speed on one side you should do it on the other side as well. Or leave them both auto, and then check that they negotiated the correct settings.
I have read your post and it seems like you may need to upgrade the firmware on your Dlink. When you have such a problem you must always see if there are firmware upgrades that can fix it.
Also, try to hard code the an IP in the Dlink and see if you can ping the router.
That would assume only his modem wasn't getting an IP though, and he said both linksys and dlinks weren't getting their address.
Let's keep 'em coming guys, surely our forum can come up with a solution....
well, sniffing at the router would be the optimal, but i dont know if i can do it. maybe you can help me with this. the engineer that i talked to said i cant, but the tech support said i can. if i put my sniffer, say, between the intermediate little gigabit switch and the GigE card, can i sniff the packets-- if it is in vlan configuration. we use vlan to assign one ip block per dlc unit. so, i am not sure if sniffing the packets would result in something that i can read using ethereal or not... i am kinda new to the vlan thing. as for a diagram of how i am sniffing, well, i am working on one right now and ill post it when i get it done. appearently i am not very good at descibing it cause teh tech support i am speaking with also doesnt understand. but basically, i have a 10-baseT hub between the adsl modem and the DLink, and my laptop is plugged into that hub so that i can sniff all the packets crossing it, then i have another laptop plugged into the LAN port on the Dlink so that i can log into the Dlink via the web browser configuration page. but like williamwbishop said, this isnt just Dlinks and i have tried the firmware updates and even downgrades. Linksys, Dlink, and i will be testing 2 other companies tomarrow. ill try the sniff between the Cisco and the GigE card, cause Telstrat also wanted me to do that, so that they know if the OFFER packets are even leaving the Cisco. Telstrat says thier equipment is simply a bridge. and as long as i can see the mac of the Dlink or linksys on the bridge forwarding table, it should pass the packets to it like it does any other ethernet controller. this arose the question with me and the mac address thing, i thought i might have been onto something there, so i tried spoofing the mac of the Dlink onto my laptop and see if it would give me the same lease as it asigned the Dlink. It did, so, no help there. i thnk the main thing to do is to see if the packets are actually leaving the Cisco. but to do that i will either have to put my 10baseT hub in the mix at the Cisco end, and cause packet collisions on saturday, or i suppose that i could set up the dlink and have it request, and spoof the mac of the dlink onto my laptop and plug it into the little intermediate gigabit switch that is between the Cisco and the GigE. but again, will i see the packets on my sniffer? will they even pass by me? will the Cisco even see my mac of my laptop if i do that, cuase of the vlan.... i guess i need to google vlan and see if i can read up on it..
also, if i put a static into the dlink, it works fine. i dont have to ping our router, just open a browser. google comes up.. so what do you think... shoudl i get a prize for being able to stump everyone i know, and 2 forums... jk.. thanks alot for your posts.
The primary problem is that without the show run's and a better idea of your layout, it's hard to narrow it down.
You can troubleshoot from a show run better than from anything else besides actually being there.
So, let's break it down into sections:
You added the router and then it had problems? Or was the router working fine, but when you added the new connection it started acting flaky? Have you tried to break both ends down to 100 megabit static, thus eliminating duplexing and gigabit issues?
To me, it almost sounds like you are missing either a) an IP HELPER address, or b) you have a route to, but not back. But it could be a million things, thus we really need a sh run or something.
i am self taught and alittle behind on my readups. i am just a tech, so when you ask for the show runs, i know that is a command in Cisco, but i dont know what you are asking for. i have going to email this link to our engineer and see if he can answer you better. ill look at your suggestions tomarrow when i am at work and try them.
Don't worry, most of us are.
sh run will output the configuration of a router. Depending on the manufacuturer it may be different, but most understand a sh run to mean that we want a configuration to investigate. As the vast majority of problems are misconfigurations, it saves time.
Yes, we need the show run. Anybody who telnets to the router and issues the cmd can log the output to a file and then it can be sent, pasted or whatever. Its just text.
Second, focus on duplex mismatch issues between the switch and the router. And between any other devices in the path to the DSLAMs. If you have mismatches all kinds of wierd, hard to track down problems can occur because its a timing thing. If the offer gets a colision when it shouldn't its discarded. ie not retransmision possible as if the sender thinks its full duplex, as far as its concerned everything is good. Will the receiving device will see the conlision and discard the packet. If you put a hub in between and the devices are set for auto they should configure as half duplex and you should get very few collisions because there are only two sending devices. If you then find that your problem is gone I would not be surprised as you have change the dynamics of the network.
Regarding sniffing. If you put your sniffer on a port in the same vlan you will only see anything that is broadcast. If a packet is unicast you won't see it. All of the packets in the DHCP exchange are broadcast so you should see them. (Keep in mind that if there is a mismatch and there is a collision your sniffer will not see the packet.)
hm... that is good stuff guys. i am off to watch the boxing match tonight, and didnt get to mess with it today, but ill try to tomarrow. and ill telnet in tomarrow and log the output of sh run for you. ill also try what gacross said. that sounds like good advice. ill have to reset them to auto, as they thought they could force full and that caused problems. ill give it a look tomarrow. thanks alot and ill let you know. it is just wierd that, if it is a collision, y it is only effecting the offer packets to the Dlink and Linksys router. any other computer gets the ip no prob. but that is still a possiblity. ill try it tomarrow about noonish my time and post the results.
No problem. The easiest way to get the config file is to use hypertermial and the copy and paste. Remember to replace any passwords with hash marks and anything that is too telling also. Note that there is a strict policy acceptance on this site for people to download your config, so if you make it an attachment it might make you a little more legally secure....dunno. Don't leave the encrypted password visible though, as there are tools to decrypt it from the written text. I'm still favoring duplex issues or ip helper missing.
right, that is why i am going to play with the duplex thing tomarrow, or rather, later today. ill see about the ip helper too. when i post the config, ill remove all "personal" info, or replace it with something else, at least.