Options

Frame-relay map oddness

TheEditorTheEditor Member Posts: 7 ■□□□□□□□□□
in CCNA & CCENT
What I'd like to know is why this works. To me this shouldnt work due to the fact that all the frame-relay map statements are under s0/0.1. Seems to work fine though. I moved the 102 and 103 statements to their matching s0/0.x sections and that of course works also.

Any input is appreciated.
cut config
interface Serial0/0.101 multipoint
ip address 192.168.10.1 255.255.255.0
snmp trap link-status
frame-relay map ip 192.168.30.2 103 broadcast
frame-relay map ip 192.168.20.2 102 broadcast
frame-relay map ip 192.168.10.2 101 broadcast
!
interface Serial0/0.102 multipointso
ip address 192.168.20.1 255.255.255.0
snmp trap link-status
!
interface Serial0/0.103 multipoint
ip address 192.168.30.1 255.255.255.0
cut config

Thanks
Bruce
@The_Ed1tor
· Share on FacebookShare on Twitter

Comments

  • Options
    mallyg27mallyg27 Member Posts: 139
    I'm going to assume that under serial0/0.101 you are creating a PVC with three other routers.
    · Share on FacebookShare on Twitter
  • Options
    TheEditorTheEditor Member Posts: 7 ■□□□□□□□□□
    I am yes. All three with a single subif with the related ip and dlci. Nothing complicated here.
    Bruce
    · Share on FacebookShare on Twitter
  • Options
    kalebkspkalebksp Member Posts: 1,033 ■■■■■□□□□□
    Did you use "frame-relay interface-dlci" on the other routers? The hub may have learned the mapping via inverse ARP. Do a "show frame-relay map" and look for dynamic entries.
    · Share on FacebookShare on Twitter
  • Options
    NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    TheEditor wrote: »
    What I'd like to know is why this works.
    When you put all three frame-relay map statements under s0/0.101, in "show frame-relay pvc" you should see that all three PVCs are mapped to interface s0/0.101. The behavior, when you put one frame-relay map statement under each interface, should be quite different.

    You do not clarify what you mean by "it works". Certainly, a Cisco router should not collapse in a billow of smoke because you decide to configure your setup this way!
    The hub may have learned the mapping via inverse ARP.
    Inverse ARP only maps IPs to DLCIs. It shouldn't help with mapping DLCIs to subinterfaces.
    · Share on FacebookShare on Twitter
  • Options
    NetworkVeteranNetworkVeteran Member Posts: 2,338 ■■■■■■■■□□
    I just labbed it up. It behaves as I described above, and as expected--

    R1#show frame-relay pvc | inc INTERFACE
    DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/0.101
    DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.101
    DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.101
    DLCI = 104, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
    · Share on FacebookShare on Twitter
  • Options
    TheEditorTheEditor Member Posts: 7 ■□□□□□□□□□
    Each of the three spoke routers used a frame-relay map multipoint statement.

    As for it working I was able to ping from all spokes to hub and vice versa.

    Also inverse arp is disabled.

    I'll post excerpts when I have a second this morning.

    Thanks
    Bruce
    @The_Ed1tor
    · Share on FacebookShare on Twitter
Sign In or Register to comment.