Has anyone had any luck configuring secondary IP's on a FRame Relay P2P. I'm readdressing all our frame Links, but couldn't get this to work. It works fine on leased lines, but not frame relay. I get the meaagae FRAME-RELAY INTERFACE-DLCI command should be used on point-to-point interfaces when trying to map the IP to int s0/1.1 . Can someone give the green guy some pointers?
The 'frame-relay map ip' command is unique to multipoint interfaces. If there are no subinterfaces, the provider DCE tells the CPE about all active and inactive DLCIs via LMI. So you manually map your many destinations (IP) to the appropriate DLCI or inverse ARP take care of the problem for you. With p-t-p subinterfaces, which of course are not multipoint, you identify which DLCI should associate with it using the 'frame-relay interface-dlci xx' command. Only one per subinterface can be assigned.
The difference between this and a standard leased line is that there is a layer 2 to layer 3 association with Frame Relay, much like on a LAN. In any case, you can't use that multipoint command on a p-t-p subinterface.
By the way, I have frame relay set up in a lab environment right now. I added a secondary interface to a p-t-p subinterface and added that network to the EIGRP process. Without any manipulation of the Frame Relay setup, I was able to ping that secondary address from accross the link. Don't know if that helps in your situation or not? If you are not running a routing protocol, just add the static routes as appropriate (ip route x.x.x.x x.x.x.x s0.1).
We are trying to readdress the WAN from a single location, we have found little success and are moving on to a person at each end. On this particular link we found that the sh int shows the same thing as sh ip int. after dropping the secondaries as our tool, we still can't get this link to work after addressing. We have done others with success but not this one. Is there a way to check for a corrupt IOS? We are using c1600-y-l.113-11a.t1.bin, and booting it from flash. Is there any known bugs?
Are you saying that after just simply entering 'no ip address x.x.x.x' and 'ip address y.y.y.y' at both ends the subinterfaces go down and stay down? What, if anyting, else is being changed as part of this process?
Yes just the IP's change and it won't work (nothing else). After getting back to work tomorrow we are having a planned outage and we are going to try to clear the inverse arp cache and debug the LMI a little more. Any other suggestions? I'll give it another day or so then get our provider to debug their end while doing the changes. The time restrictions for this have come and gone, We are on our first extention.
Clearing your inarp is a good idea. I can't think of much else off hand (you did add the new network to your routing protocol, if any?). I did this in the lab and was able to get secondary addressing to work and was also able to just 'no ip address' and 'ip address' without any problems. But you know how much relevance a lab has to a real problem - minimal. Please let us all know what you eventually figure out and I will keep your problem in the back of my mind.
The network wouldn't have changed it's still the 10.0.0.0 range, We might be having a bigger problem than that. I had a leased line in St Paul that is giving us the same behavior, but I think this is more due to the access lists on the other end. Thanks for the help, I'm newly ceritified and very green at all of this. Everyone in the group is so helpfull and makes me proud to be Cisco certified. Thanks again for all your help. P.S. We will try the Frame links again in a day or two and I'll post to let you know. We are about half way through.
More problems with this link today. A question for all the pro's. How do the PVC's remap if inverse arp is dissabled on a p-t-p by default..
I'm not sure if I understand what you're trying to accomplish. I have implemented secondary IP addresses on Frame-Relay subinterfaces during WAN re-ip projects without any problem. Is that what you're talking about?
This is exactly what I'm talking about. We have had no luck with primaries or secondary on the interfaces on a hub router. Have tried both with no success. Any change of the addressing I can't even ping the local interface. I can get the secondary to input but can't ping it. The following is from the frame map after the readdressing, Serial0 (up): ip 10.100.2.x dlci 3X dynamic,broadcast,, status defined, active And the address is the old address. clear the inverse arp and nothing is displayed. Could this be the provider assigning something static on his end? I have sent an E-mail and no responce yet.
If your problem is pinging your own interface, you won't be able to with Frame-Relay. You can ping the far end subinterface, but not your own. I give you an example, I had a worldwide FR network where we had all kinds of different IP addressing on the subinterfaces. We wanted to move to 192.168.x.x on all subinterfaces. I made sure that I had modem connectivity to the remote site in Europe and Asia, or someone there to reboot the router if needed. I configured the subinterface on the far end for example, with 192.168.1.2 (secondary) then configured my side of the link with 192.168.1.1 (secondary). I made sure I could ping the other side, then added the "network 192.168.1.0" command under EIGRP config.
Also I made sure not to "wr mem" in case something went wrong I could have the person on the far end reboot the router whih would load with it's normal configuration. It shouldn't be any problem.
Hope this helps.
MICHAEL Thanks for the pointer, It was a problem with the arp over frame. I enabled the arp and readdressed the link and IT WORKED. This may have be somthing else but I was tiered(it was 11:45 P.M. saterday). I have 15 more to do before It's over so I'll get my feet wet in a wild kind of way. Thanks to all for the suggestions and giving me pointers, I'm newly certified and evryone is so helpfull. learned more in the last three weeks than in the prior year.
if I am not mistaken, this is a routing protocol based issue. If you are running EIGRP for example, it will not form adjacency using the secondary address even though it might advertise it...
I have completed the readdressing project on all interfaces without a problem (after all your suggestions). I have learned that the frame switch DID NOT update the frame map dynamically. I had the person on the other end use No frame map ip X.X.X.X dlci and this took care of this item. I also was able to readdress a few on my own if I deleted the map and applied the ip address, that in turn took the interface down and on the next LMI update cycle the link would be active. This in turn would give me time to readdress the hub router. To Everyone that has answered my questions, Thanks. Being a new CCNA and have a project like this for the first project is stressfull enough. You all have help emensely. Thanks again!!!