Subinterface configurations in Frame Relay network (pic)

rjbarlow

Hi guys,
I have some issue to understand one thing: at page 409 of the ICND Odom's book, is an example of hybrid addressing on a Frame relay network, a fully meshed part with multiple DTEs all within the same subnet and some pair of DTE who shares one subnet and one PVC.

Like in this pic (colorful lines are PVCs):



He says that IARP is enabled by default on multipoint subinterfaces while disabled on point-to-point subinterfaces. I take that for good, but when he goes to configure the multipoint subinterfaces on Router1, 2 and 3, he uses the frame-relay interface-dlci command in order to manually mapping DLCIs<--->IPaddresses.

This is the configuration he makes, I adapted it to my scenario, but I assure it is identical in the meaning:

hostname Router1
!
interface serial1/0
encapsulation frame-relay
!
interface serial 1/0.1 multipoint
ip address 129.5.6.1 255.255.255.0
frame-relay interface-dlci 60
frame-relay interface-dlci 70
!
interface serial1/0.2 point-to-point
ip address 147.8.8.1 255.255.255.0
frame-relay interface-dlci 80
!
interface serial 1/0.3 point-to-point
ip address 170.2.2.1 255.255.255.0
frame-relay interface-dlci 90
!

In the DTEs who share one only PVC, he makes one subinterface per DTE and he configure them as follows (show ocnfig of router4):

hostname Router4
!
interface serial1/0
encapsulation frame-relay
!
interface serial1/0.1 point-to-point
ip address 147.8.8.2 255.255.255.0
frame-relay interface-dlci 50

Based on the statements above, seems to me much strange that the configurations are identical on point-to-point subinterfaces and multipoint.

Anyone who wants to spend some word on this stuff would be much appreciated.

Thank You.

Netstudent

Everything looks right man. The only thing you should notice here is that the multipoint interface has 2 VC's terminating and thats why you have 2 DLCI's on the multipoint.


I-ARP is disbaled on p-t-p interfaces because discovery is not needed. There is only 2 endpoints and nowhere else for the data to go.

ALso on routers 2 and 3, you will have multipoint interfaces with 2 VC's. I-ARP will do the mappings for you on the multipoint interfaces if and only if you have your frame-relay switch configured properly. IF the routes are wrong in your switch, then your frame-relay VC state will be deleted.

dtlokee

The frame-relay interface-dlci commands on the multipoint interface aren't necessary, it is still going to use inverse arp to discover the IP addresses. The point of this is to assign the DLCIs that should be used on the interface to the interface, then rely on inverse arp for the rest.

mwgood

If you want to statically map the dlci's on the multipoint interface, then turn off inverse-arp and use the frame-relay map ip x.x.x.x dlci command.

cisco_trooper

I don't have it in front of me at the moment, but I'm pretty sure Odom doesn't use Inverse ARP in his frame relay configurations if I remember correctly. I think this explains the configuration on your multipoint interface.

rjbarlow

Netstudent wrote:

Everything looks right man. The only thing you should notice here is that the multipoint interface has 2 VC's terminating and thats why you have 2 DLCI's on the multipoint.

I-ARP is disbaled on p-t-p interfaces because discovery is not needed. There is only 2 endpoints and nowhere else for the data to go.

Hi Net, this is not always valid, take in consideration PVCs of router1 toward router4 and 5, there are two point-to-point subinterfaces and two PVCs, then router1 still must choose the right DLCI to put in the frames. I guess Odom uses the "frame-relay interface-dlci" on all p-t-p subinterfaces because IARP is already disabled by default on all p-t-p subinterfaces.

rjbarlow

dtlokee wrote:

The frame-relay interface-dlci commands on the multipoint interface aren't necessary, it is still going to use inverse arp to discover the IP addresses. The point of this is to assign the DLCIs that should be used on the interface to the interface, then rely on inverse arp for the rest.

Hi dt, but wath I would know is if these "inerface-dlci"commands issued on multipoint subinterfaces are indeed superfluous, like seems to me?
Because IARP is enalbled on these multipoint subinterfaces I don't see their necessity.
For example, takes PVC from router1 toward router2:
1) router1 know his DLCI from LMI messages (but still he don't know his IP address)
2) router1 and router2 know respectives IP addresses by means of IARP
And that's all for me: router1 can reach router2.
I mistake?

Netstudent

rjbarlow wrote:

Netstudent wrote:

Everything looks right man. The only thing you should notice here is that the multipoint interface has 2 VC's terminating and thats why you have 2 DLCI's on the multipoint.

I-ARP is disbaled on p-t-p interfaces because discovery is not needed. There is only 2 endpoints and nowhere else for the data to go.

Hi Net, this is not always valid, take in consideration PVCs of router1 toward router4 and 5, there are two point-to-point subinterfaces and two PVCs, then router1 still must choose the right DLCI to put in the frames. I guess Odom uses the "frame-relay interface-dlci" on all p-t-p subinterfaces because IARP is already disabled by default on all p-t-p subinterfaces.

i'm not sure what is invalid. Those point-to-point interfaces will have different characteristics than a multipoint. YOu said "seems to me much strange that the configurations are identical on point-to-point subinterfaces and multipoint" and I was just commenting that the single multipoint interface will have multiple virtual circuits on it. That is essentially what a multipoint interface is and that would be the only difference in configuration.

And yes you are right, you don't have to use the frame interface-dlci if using inverse-arp. That will be done automatically as long as your frame-relay routes are configured correctly in the switch.

rjbarlow

Netstudent wrote:

I'm not sure what is invalid...

I referred to the part below of Your speech, not always valid, not "always not valid", because the problem arise when there are more than one p-t-p subinterface and PVCs; the router still must decide wich DLCI to put into the frame, that is done manually or by means of IARP. The rest I agree all.

I-ARP is disbaled on p-t-p interfaces because discovery is not needed. There is only 2 endpoints and nowhere else for the data to go.

For mutipoint interfaces configurations maybe is right that said cisco_trooper that Odom makes its configurations without consideration of IARP.

dtlokee

Ok so in this example the "frame-relay interface-dlci" commands are not necessary on the multipoint interface and it will work. The DLCI to IP address resolution will be done by inverse ARP. The DLCI's assigned to the point to point subinterfaces will not be eliagable for inverse arp so there is no risk of the DLCI's being dynamically learned on the wrong subinterface.

Now lets say you had 2 multipoint sub interfaces on the same physical interface, and the frame switch is configured for 4 PVC's to remote sites. You want 2 of the PVC's to terminate on one sub interface and the other 2 on the other sub interface. You could disable inverse arp on the interfaces and go with static mappings, or simply put the "frame-relay interface-dlci" command on the multipoint sub interfaces to associate the DLCI with the correct sub-interface.

R1#sh frame map
Serial0.1 (up): ip 192.168.50.3 dlci 103(0x67,0x1870), dynamic,
              broadcast,, status defined, active
Serial0.1 (up): ip 192.168.50.2 dlci 102(0x66,0x1860), dynamic,
              broadcast,, status defined, active
Serial0.2 (up): ip 192.168.100.4 dlci 104(0x68,0x1880), dynamic,
              broadcast,, status defined, active

R1#sh run int serial 0.1

interface Serial0.1 multipoint
 ip address 192.168.50.1 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 102
 frame-relay interface-dlci 103
end

R1#sh run int serial 0.2

interface Serial0.2 multipoint
 ip address 192.168.100.1 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 104
end

R1#

rjbarlow

dtlokee wrote:

Ok so in this example the "frame-relay interface-dlci" commands are not necessary on the multipoint interface and it will work. The DLCI to IP address resolution will be done by inverse ARP. The DLCI's assigned to the point to point subinterfaces will not be eliagable for inverse arp so there is no risk of the DLCI's being dynamically learned on the wrong subinterface.

Now lets say you had 2 multipoint sub interfaces on the same physical interface, and the frame switch is configured for 4 PVC's to remote sites. You want 2 of the PVC's to terminate on one sub interface and the other 2 on the other sub interface. You could disable inverse arp on the interfaces and go with static mappings, or simply put the "frame-relay interface-dlci" command on the multipoint sub interfaces to associate the DLCI with the correct sub-interface.

R1#sh frame map
Serial0.1 (up): ip 192.168.50.3 dlci 103(0x67,0x1870), dynamic,
              broadcast,, status defined, active
Serial0.1 (up): ip 192.168.50.2 dlci 102(0x66,0x1860), dynamic,
              broadcast,, status defined, active
Serial0.2 (up): ip 192.168.100.4 dlci 104(0x68,0x1880), dynamic,
              broadcast,, status defined, active

R1#sh run int serial 0.1

interface Serial0.1 multipoint
 ip address 192.168.50.1 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 102
 frame-relay interface-dlci 103
end

R1#sh run int serial 0.2

interface Serial0.2 multipoint
 ip address 192.168.100.1 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 104
end

R1#

OK, this is very clear now... Thanks much dtlokee and to all have answered.

rjbarlow

Damn and blast! dtlokee, a terible doubt arise to me now:
if You put these "frame-relay interface-dlci" on that multipoint subinterface, and for example disable Inverse ARP, what DLCI the router put into the frame who wants to exit from this (sub)interface??

R1#sh frame map 
Serial0.1 (up): ip 192.168.50.3 dlci 103(0x67,0x1870), dynamic, 
              broadcast,, status defined, active 
Serial0.1 (up): ip 192.168.50.2 dlci 102(0x66,0x1860), dynamic, 
              broadcast,, status defined, active 

R1#sh run int serial 0.1 

interface Serial0.1 multipoint 
ip address 192.168.50.1 255.255.255.0 
no ip directed-broadcast 
frame-relay interface-dlci 102 
frame-relay interface-dlci 103 
end

Then newly come back the essential role of Inverse ARP (or static mapping with the command "frame-relay map") in which absence nothing would works for me even if You put those commands in these cases.
This frame-relay interface-dlci command I look good only for point to point (sub)interfaces in a no condition of confusion, put more of these commands on the same subinterface seems to me newly a contradiction in terms or at least superfluous...

Netstudent

"frame-relay interface-dlci" on that multipoint subinterface, and for example disable Inverse ARP, what DLCI the router put into the frame who wants to exit from this (sub)interface??

If you disable I-ARP, you will need static mappings with the frame-relay map command. When the router looks at the routing table to see what interface to route the packet, it will also see the next hop IP address. This next hop IP address will also be in the frame-relay map. Thats how it knows which DLCI to use in the frame. [/quote]

Are you actually configuring frame-relay or are you just reading about it and asking questions as you go? You really need to do a lot of frame-relay labs to see how it works in different ways with different topologies. Frame-relay can be a ball buster if you don't have some gear to configure and play with. ALso Boson does not do frame-relay justice.

rjbarlow

Netstudent wrote:

If you disable I-ARP, you will need static mappings with the frame-relay map command. When the router looks at the routing table to see what interface to route the packet, it will also see the next hop IP address. This next hop IP address will also be in the frame-relay map. Thats how it knows which DLCI to use in the frame.

Yes I agree, really I wrote:

rjbarlow wrote:

Then newly come back the essential role of Inverse ARP (or static mapping with the command "frame-relay map") in which absence nothing would works for me even if You put those commands in these cases.

In fact like I said I look good this command only one by one on different p-t-p subinterfaces...

Netstudent

Hmmm..I'm really trying to figure out what you are confused about and help you, but I'm having a hard time understanding your confusion.

So you tried static mappings and "I-ARP" and it wouldn't work?

Don't forget that you will need the frame-relay interface-dlci command if you are doing static mappings. On my gear I could not get frame-relay to communicate when using static mappings unless I nailed down the DLCI on the interface.

I hope you figure it out man.

rjbarlow

Netstudent wrote:

Are you actually configuring frame-relay or are you just reading about it and asking questions as you go? You really need to do a lot of frame-relay labs to see how it works in different ways with different topologies. Frame-relay can be a ball buster if you don't have some gear to configure and play with. ALso Boson does not do frame-relay justice.

Ooohhh saint words man! I know that! Thus I am exercising myself to create differents labs and ask when I have doubts, because also it is difficult to recreate various conditions about Frame Realy with real machines...! This topic it is revealing itself truly troublesome.

Netstudent

I understand...Well don't get to frustrated with it because like I said it's hard to fully understand it without the gear, and even harder without real-world experience. When you have a Frame-relay switch to create frame-relay routes, then you really start to see what a PVC is and how it relates to Inverse-Arp and LMI. keep crackin at it, good luck.

rjbarlow

Netstudent wrote:

Hmmm..I'm really trying to figure out what you are confused about and help you, but I'm having a hard time understanding your confusion.

So you tried static mappings and "I-ARP" and it wouldn't work?

Don't forget that you will need the frame-relay interface-dlci command if you are doing static mappings. On my gear I could not get frame-relay to communicate when using static mappings unless I nailed down the DLCI on the interface.

I hope you figure it out man.

Netstudent, just theoretical, I can't try sure all my F.R. labs and doubts in that simulator, because it is very uncertain and limited...
I'm trying to understand what command is more appropriate in differents situations in order to supply to the router sufficient and appropriate information to route the frames...

Netstudent wrote:

...keep crackin at it, good luck.

Thanks man, I appreciate Your share.