From: Carlos Trujillo Jimenez (nergal888@hotmail.com)
Date: Mon Sep 10 2007 - 02:19:23 ART
>YEEEEEEEEEEEEEEEEAAAAH!!
>
>think I have the solution!! funny, Im autoresponding my own task jeje ;)
>Appreciate a lot, if ayone correct me pleae if Im wrong.
>
>well, from the only think I integrate is both commands at the same
>interface thus:
>
>>int ser 0/0
>>no frame relay inverse arp
>>frame relay map ip 192.168.1.3 100
>>frame relay map ip 192.168.1.5 200
>>frame relay interface dlci 100
>>class SHAPE-DLCI100
>>frame relay interface dlci 200
>>class SHAPE-DLCI200
>>frame relay traffic shaping
>
>Before this aggregation things started to work, there was a little
>confussion that frame-relay interface dlci command operates only with frame
>relay inverse arp, but if theres explicitly disabled frame relay inverse
>arp with the command "no frame relay inverse arp", the only use of the
>command "frame relay interface dlci 100" is for map the frame relay class
>with traffic shaping parameters, and that both commads can coexist in the
>same interface as this is the case :)
>
>the result:
>P4R3#show frame-relay map
>Serial0/0 (up): ip 154.1.0.4 dlci 304(0x130,0x4C00), static,
> CISCO, status defined, active
>Serial0/0 (up): ip 154.1.0.5 dlci 305(0x131,0x4C10), static,
> CISCO, status defined, active
>
>Cheers!
>
>
>
>
>
>
>
>
>
>
>ORIGINAL MESSAGE
>>
>>Hi all.
>>
>>Im Little confused at the labs, since looking at the beggining of all the
>>labs the task ask to disable frame relay inverse arp at the physical
>>interface and we simply create a frame relay map pointing to the next hop
>>ip address thus disabling the frame relay inverse arp, Things work with
>>successful pings from directly connected neighbors.
>>
>>Next topic of the same lab ask to enable ospf, and we change the interface
>>type based on the defined task, making the things work becoming
>>succesfully adjacent directly connected neighbors over the nbma cloud.
>>
>>Now.... at a far task, it prompts to enable frame relay traffic shaping at
>>a circuit level, mean a cir for a specified dlci, different to a cir of
>>another dlci, who both dlcis live in the same physical interface.
>>
>>Now there begins the problem, since we must configure the traffic shaping
>>characteristics (cir, bc, be) between different dlcis in the same physical
>>interface, we must change or dont know if it is better said "UNDO" some
>>configurations who are already working at the beggining tasks, for
>>example:
>>
>>config withouth the traffic shaping task (before traffic shaping):
>>
>>int ser 0/0
>>no frame relay inverse arp
>>frame relay map ip 192.168.1.3 100
>>frame relay map ip 192.168.1.5 200
>>ip ospf network point-to-multipoint nonbroadcast
>>
>>router ospf 1
>>neighbor 192.168.1.3 cost 95
>>neighbor 192.168.1.3 cost 170
>>
>>config with the traffic shaping task (after traffic shaping):
>>
>>int ser 0/0
>>no frame relay inverse arp
>>frame relay interface dlci 100
>>class SHAPE-DLCI100
>>frame relay interface dlci 200
>>class SHAPE-DLCI200
>>frame relay traffic shaping
>>ip ospf network point-to-multipoint nonbroadcast
>>
>>router ospf 1
>>neighbor 192.168.1.3 cost 95
>>neighbor 192.168.1.3 cost 170
>>
>>
>>Doing the configuration for the traffic shaping , involves changes of the
>>commands "frame relay map" resplaced with the command "frame relay
>>interface dlci", thus disabling the ospf neighbor relationship between
>>directly connected routers.
>>
>>ANY IDEAS?
>>
>>_________________________________________________________________
>>MSN Amor: busca tu = naranja http://latam.msn.com/amor/
>>
>>_______________________________________________________________________
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>
>_________________________________________________________________
>MSN Amor: busca tu = naranja http://latam.msn.com/amor/
>
This archive was generated by hypermail 2.1.4 : Sat Oct 06 2007 - 12:01:10 ART