From: Javier Tomé (fjtm@tid.es)
Date: Sun Sep 18 2005 - 05:11:25 GMT-3
Hi all,
Dave and I have been discussing about this issue and we would like to
find the opinion of the experts. It would be great if some of you could
find 5 minutes to read this mail and give your comments...
Thank you in advance
Best Regards
Javi Tomi
Schulz, Dave wrote:
>Javier and I were having a side discussion on the frame-relay aspect of this
>lab setup. Please see below. I would like to get some of the input from the
>IP Expert, IE and NMC experts on the broadcast issue as it relates to the real
>lab.
>
>
>
>
>
>Dave Schulz,
>
>Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com%20>
>
>
>
>________________________________
>
>From: fjtm@tid.es [mailto:fjtm@tid.es]
>Sent: Friday, September 16, 2005 1:53 PM
>To: Schulz, Dave
>Subject: Re: Multicast issue: Auto-RP over Sparse-Dense mode
>
>
>
>Well, I have no reference at all. This is kind of a self deduction after hours
>of lab practicing. Actually I have seen both configurations on NMC labs and
>Internetwork Experts labs.
>
>When the taks specify not to send redudant information to the hub the solution
>is always to apply the broadcast keyword only on one frame-relay map
>statement. This fact, together with some debugging on multicast issues and
>other experiences made me reach to that conclusion.
>
>I don4t remember any example in which applying it to both map statements is
>required to make everything work, but I am far from being an expert. May be I
>am missing something...
>
>As you suggested we could send this issue to the forum for general dicussion,
>there are really amazing people out there...
>
>
>
>
>Schulz, Dave wrote:
>
>
>
>That is interesting, Javier. I have never heard that before. Actually, the
>solution for the frame-relay in IP Expert have this as their standard way of
>doing it. Do you have any reference material for this.
>
>
>
>I agree on the routing protocol issues that you present.
>
>
>
>
>
>Dave Schulz, CCDP, CCNP, CCSP
>Project Manager / TAC Supervisor
>Data Processing Sciences Corporation
>10810 Kenwood Road
>Cincinnati, Ohio 45242
>Phone - (513) 791-7100 ext.7411
>Fax - (513) 791-4676
>Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com%20>
>
>
>
>________________________________
>
>From: fjtm@tid.es [mailto:fjtm@tid.es]
>Sent: Friday, September 16, 2005 11:39 AM
>To: Schulz, Dave
>Subject: Re: Multicast issue: Auto-RP over Sparse-Dense mode
>
>
>
>Hi Dave,
>
>If fact on the spokes the broadcast keyword is only needed once, adding it on
>both mappings is useless (all you will get is to send unnecessarily two copies
>of each broadcast/multicast packet to the hub).
>
>Lets put an example on your topology (R2 is the hub, R3 and R4 the spokes).
>When R3 issues a ping to R4, the icmp echo request reaches R2, which in turn
>re-routes the packet to R4. That means a two-hop path.
>
>All routing protocols supporting multicast use addresses on the 224.0.0.0/24
>range (link local multicast address range). When routing packets leave the
>router their TTL is set to 1. This make it impossible for them to reach the
>other spoke (unless you stablish a tunnel interface between the spokes or
>something like that).
>
>For routing protocols to work correctly on hub and spoke networks you need to
>follow some rules:
>
>* In case you are running a distance vector protocol (i.e. RIP, EIGRP...) you
>need to make sure that split-horizont is disable on the interface of the HUB
>router.
>* On OSPF, when using broadcast, and non-broadcast multiaccess network types
>you will need to make sure that the only DR elegible router is the HUB
>router.
>* It is not possible to run ISIS on NBMA networks unless you have a full-mess
>topology. In this case you will need to use tunnel interfaces...
>
>I hope this to be clear enought. Otherwise let me know...
>
>Best Regards
>
>Javi
>
>
>Schulz, Dave wrote:
>
>
>
>
>Really, I thought that this was necessary for forwarding the routing protocols
>between the spoke-to-hub and the spoke-to-spoke, since these are for each
>site. I didn't think that they were redundant. How would you do that in a
>better way and make sure that the routing protocols are forwarded over this
>DLCI? Should we send this one out to the group for comment?
>
>Dave
>
>-----Original Message-----
>From: fjtm@tid.es
>To: Schulz, Dave
>Sent: 9/16/2005 1:41 AM
>Subject: Re: Multicast issue: Auto-RP over Sparse-Dense mode
>
>Just one thing more, I guess you have already notice, but you have
>redundant broadcast keyword (both, on R3 - PVC 302, and on R4 PVC 402)
>on your NBMA frame-relay mappings. Although not really important, in my
>opinion that is not a best practice...
>
>Regards
>
>Javi
>
>Schulz, Dave wrote:
>
>
>It was solved with the loopback being identified in the IGP. What are
>you referring to on the RPF check....I don't think I know that one.
>
>Dave
>
>-----Original Message-----
>From: fjtm@tid.es <mailto:fjtm@tid.es>
>To: Schulz, Dave
>Cc: ccielab@groupstudy.com <mailto:ccielab@groupstudy.com>
>Sent: 9/15/2005 5:35 PM
>Subject: Re: Multicast issue: Auto-RP over Sparse-Dense mode
>
>It seems like if R2 does not accept the RP announce message from R4.
>Have you done an RPF check to R4 loopback address on R2?...
>
>Schulz, Dave wrote:
>
>
>
>>Here is the situation.... I am doing multicast with Auto-RP over
>>Sparse-Dense (configs below). R2 has a DLCI to R3 and R4 (multipoint
>>subif), and, also a point-to-point subinterface on a separate dlci to
>>R5.
>>
>>R2 is announcing itself as the RP for groups 224.2.2.0
>>R4 is announcing itself as the RP for groups 224.4.4.0
>>
>>I believe the configurations are correct. However, when I do the show
>>ip pim rp map, I get the following:
>>
>>R2#sh ip pim rp map
>>PIM Group-to-RP Mappings
>>This system is an RP (Auto-RP)
>>This system is an RP-mapping agent (Serial0.2)
>>
>>Group(s) 224.2.2.0/24
>> RP 20.20.20.1 (?), v2v1
>> Info source: 20.20.20.1 (?), via Auto-RP
>> Uptime: 23:19:40, expires: 00:02:15
>>
>>R3#sh ip pim rp map
>>PIM Group-to-RP Mappings
>>
>>Group(s) 224.2.2.0/24
>> RP 20.20.20.1 (?), v2v1
>> Info source: 172.16.1.2 (?), via Auto-RP
>> Uptime: 23:18:23, expires: 00:02:39
>>R3#
>>
>>R4# sh ip pim rp map
>>PIM Group-to-RP Mappings
>>This system is an RP (Auto-RP)
>>
>>Group(s) 224.2.2.0/24
>> RP 20.20.20.1 (?), v2v1
>> Info source: 172.16.1.2 (?), via Auto-RP
>> Uptime: 00:00:05, expires: 00:02:50
>>Group(s) 224.4.4.0/24
>> RP 40.40.40.1 (?), v2v1
>> Info source: 40.40.40.1 (?), via Auto-RP
>> Uptime: 23:06:44, expires: 00:01:17
>>
>>
>>R5#sh ip pim rp map
>>PIM Group-to-RP Mappings
>>
>>Group(s) 224.2.2.0/24
>> RP 20.20.20.1 (?), v2v1
>> Info source: 172.16.1.2 (?), via Auto-RP
>> Uptime: 23:05:19, expires: 00:02:50
>>
>>Problem: for some reason, I cannot get the 224.4.40 group to be mapped
>>throughout the network. I run the same scenario under BSR and it works
>>fine. Also, running the MRM utility shows no errors. Thoughts? Here
>>are the configs......
>>
>>
>>hostname R2
>>ip multicast-routing
>>!
>>interface Loopback0
>>ip address 20.20.20.1 255.255.255.0
>>ip pim sparse-dense-mode
>>!
>>interface Serial0
>>no ip address
>>encapsulation frame-relay
>>no frame-relay inverse-arp
>>frame-relay lmi-type cisco
>>!
>>interface Serial0.1 multipoint
>>ip address 192.168.1.2 255.255.255.0
>>ip pim nbma-mode
>>ip pim sparse-mode
>>frame-relay map ip 192.168.1.2 203
>>frame-relay map ip 192.168.1.3 203 broadcast
>>frame-relay map ip 192.168.1.4 204 broadcast
>>no frame-relay inverse-arp
>>!
>>interface Serial0.2 point-to-point
>>ip address 172.16.1.2 255.255.255.0
>>ip pim sparse-dense-mode
>>ip igmp join-group 224.4.4.4
>>frame-relay interface-dlci 205
>>!
>>router eigrp 1
>>network 172.16.0.0
>>network 192.168.1.0
>>no auto-summary
>>no eigrp log-neighbor-changes
>>!
>>ip pim send-rp-announce Loopback0 scope 16 group-list 1
>>ip pim send-rp-discovery Serial0.2 scope 16
>>!
>>ip mrm manager TST
>>manager Loopback0 group 224.4.4.4
>>senders 8
>>receivers 9 sender-list 8
>>!
>>access-list 1 permit 224.2.2.0 0.0.0.255
>>access-list 8 permit 50.50.50.1
>>access-list 9 permit 40.40.40.1
>>!
>>
>>R3
>>hostname R3
>>ip multicast-routing
>>!
>>interface Loopback0
>>ip address 30.30.30.1 255.255.255.0
>>ip pim sparse-dense-mode
>>!
>>interface Serial0
>>ip address 192.168.1.3 255.255.255.0
>>ip pim sparse-dense-mode
>>encapsulation frame-relay
>>frame-relay map ip 192.168.1.2 302 broadcast
>>frame-relay map ip 192.168.1.3 302
>>frame-relay map ip 192.168.1.4 302 broadcast
>>no frame-relay inverse-arp
>>frame-relay lmi-type cisco
>>!
>>router eigrp 1
>>network 192.168.1.0
>>no auto-summary
>>no eigrp log-neighbor-changes
>>!
>>
>>R4
>>
>>hostname R4
>>ip multicast-routing
>>!
>>interface Loopback0
>>ip address 40.40.40.1 255.255.255.0
>>ip pim sparse-dense-mode
>>ip mrm test-receiver
>>!
>>interface Serial0
>>ip address 192.168.1.4 255.255.255.0
>>ip pim sparse-dense-mode
>>encapsulation frame-relay
>>frame-relay map ip 192.168.1.2 402 broadcast
>>frame-relay map ip 192.168.1.3 402 broadcast
>>frame-relay map ip 192.168.1.4 402
>>no frame-relay inverse-arp
>>frame-relay lmi-type cisco
>>!
>>router eigrp 1
>>network 192.168.1.0
>>no auto-summary
>>no eigrp log-neighbor-changes
>>!
>>ip pim send-rp-announce Loopback0 scope 16 group-list 1
>>!
>>access-list 1 permit 224.4.4.0 0.0.0.255
>>!
>>
>>
>>R5
>>hostname R5
>>ip multicast-routing
>>!
>>interface Loopback0
>>ip address 50.50.50.1 255.255.255.0
>>ip pim sparse-dense-mode
>>ip mrm test-sender
>>!
>>interface Serial0
>>ip address 172.16.1.5 255.255.255.0
>>ip pim sparse-dense-mode
>>encapsulation frame-relay
>>frame-relay interface-dlci 502
>>frame-relay lmi-type cisco
>>!
>>router eigrp 1
>>network 172.16.0.0
>>no auto-summary
>>no eigrp log-neighbor-changes
>>!
>>end
>>
>>Dave Schulz
>>Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com>
>>
>>
><mailto:dschulz@dpsciences.com
><mailto:dschulz@dpsciences.com%20%20%3Cmailto:dschulz@dpsciences.com%20> > >
>
>
>>_______________________________________________________________________
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>>
>>
><http://www.groupstudy.com/list/CCIELab.html>
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:15 GMT-3