From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Fri Sep 16 2005 - 16:39:10 GMT-3
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>
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:15 GMT-3