Re: how to properly verify a broadcast to multicast-helper?

From: Narbik Kocharians <narbikk_at_gmail.com>
Date: Mon, 25 May 2009 15:07:59 -0700

Man try this lab.

*Lab topology:*

* *

*R1 is connected to R2 via F0/0 *

*R2 is connected to R3 via P2P Frame-relay*

*R3 is connected to R4 via Frame-relay P2P connection*

*R4 is connected to R5 via F0/0*

* *

*IP addressing:*

R1 - F0/0 = 10.1.12.1 /24, Lo0 = 1.1.1.1 /8

R2  F0/0 = 10.1.12.2 /24, S0/0.23 = 10.1.23.2 /24, Lo0 = 2.2.2.2 /8

R3  S0/0.32 = 10.1.23.3 /24, S0/0.34 = 10.1.34.3 /24, Lo0 = 3.3.3.3 /8

R4  S0/0.43 = 10.1.34.4 /24, F0/0 = 10.1.45.4 /24, Lo0 = 4.4.4.4 /8

R5  F0/0 = 10.1.45.5 /24

*Task 1*

* *

Configure OSPF Area 0 on *all frame-relay links* and the loopback interfaces
of R2, R3, and R4

* *

*On R2*

R2(config)#router ospf 1

R2(config-router)#netw 10.1.23.2 0.0.0.0 area 0

R2(config-router)#netw 2.2.2.2 0.0.0.0 area 0

* *

*On R3*

R3(config)#router ospf 1

R3(config-router)#netw 0.0.0.0 0.0.0.0 area 0

*On R4*

R4(config)#router ospf 1

R4(config-router)#netw 4.4.4.4 0.0.0.0 area 0

R4(config-router)#netw 10.1.34.4 0.0.0.0 area 0

*To verify the configuration:*

* *

*On R2*

* *

*R2#Show ip route ospf | Inc O*

* *

O 3.3.3.3 [110/65] via 10.1.23.3, 00:00:54, Serial0/0.23

O 4.4.4.4 [110/129] via 10.1.23.3, 00:00:54, Serial0/0.23

O 10.1.34.0 [110/128] via 10.1.23.3, 00:00:54, Serial0/0.23

*On R4*

*R4#Show ip route ospf | Inc O*

* *

* *

O 2.2.2.2 [110/129] via 10.1.34.3, 00:01:37, Serial0/0.43

O 3.3.3.3 [110/65] via 10.1.34.3, 00:01:37, Serial0/0.43

O 10.1.23.0 [110/128] via 10.1.34.3, 00:01:37, Serial0/0.43

* *

* *

*Task 2*

Configure *RIPv2 on the F0/0 and loopback 0* interfaces of R1 and R5.
Disable the auto-summarization on both of these routers.

* *

* *

*On R1 *

* *

R1(config)#router rip

R1(config-router)#no au

R1(config-router)#ver 2

R1(config-router)#Netw 10.0.0.0

R1(config-router)#Netw 1.0.0.0

*On R5 *

* *

R5(config)#router rip

R5(config-router)#no au

R5(config-router)#ver 2

R5(config-router)#Netw 10.0.0.0

R5(config-router)#Netw 5.0.0.0

* *

* *

*Task 3*

Configure Multicasting on the appropriate routers such that R5 receives all
the *RIPv2* routes from R1.

R2 should be configured as the RP and BSR router, this router should use
its loopback interface as the source of all its BSR messages. You MUST use
224.1.1.1 to accomplish this task.

*This task calls for helper-map configuration, as follows:*

* *

*Step One:*

* *

*In the first step of this configuration, R1 is configured to send RIPv2
updates to a broadcast destination so R2 can map them to a Multicast address
of 224.1.1.1.*

R1(config)#int f0/0

R1(config-if)#*ip rip v2-broadcast*

*Step two:*

* *

*In this step IP multicast-routing should be enabled on all transit routers
(R2, R3 and R4). *

*On R2, R3 and R4*

(config)#*ip multicast-routing*

* *

*Step Three:*

* *

*Pim sparse mode should be enabled on R2s F0/0, S0/0.23 and its loopback 0
interface, on R3s S0/0.32 and S0/0.34, on R4s S0/0.43 and its Loopback 0
interface:*

*On R2*

R2(config)#int F0/0

R2(config-if)#*ip pim sparse-mode*

R2(config)#int S0/0.23

R2(config-subif)#*ip pim sparse-mode*

* *

R2(config)#int lo0

R2(config-if)#*ip pim sparse-mode*

*On R3*

R3(config)#int S0/0.32

R3(config-subif)#*ip pim sparse-mode*

R3(config)#int S0/0.34

R3(config-subif)#*ip pim sparse-mode*

*On R4*

R4(config)#int S0/0.43

R4(config-subif)#*ip pim sparse-mode*

*To verify the configuration:*

* *

*On R4*

* *

*R4#Show ip pim neighbor*

PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,

      S - State Refresh Capable

Neighbor Interface Uptime/Expires Ver DR

Address
Prio/Mode

10.1.34.3 Serial0/0.43 00:01:55/00:01:18 v2 1 / S

*On R3*

*R3#Show ip pim neighbor *

PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,

      S - State Refresh Capable

Neighbor Interface Uptime/Expires Ver DR

Address
                         Prio/Mode

10.1.23.2 Serial0/0.32 00:03:43/00:01:28 v2 1 / S

10.1.34.4 Serial0/0.34 00:03:06/00:01:35 v2 1 / S

*On R2*

*R2#Show ip pim neighbor*

PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,

      S - State Refresh Capable

Neighbor Interface Uptime/Expires Ver DR

Address
                               Prio/Mode

10.1.23.3 Serial0/0.23 00:04:02/00:01:38 v2 1 / S

*Step four:*

* *

*BSR multicast routing is configured on R2; in this step R2 is configured as
the RP and the BSR using the loopback0 interface as the source of its
packets:*

*On R2*

R2(config)#*ip pim rp-candidate lo0*

R2(config)#*ip pim bsr-candidate lo0*

*To verify the configuration:*

* *

*On R3*

*R3#Show ip pim rp mapping*

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

  RP 2.2.2.2 (?), v2

     Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150

            Uptime: 00:00:09, expires: 00:02:19

*On R4*

*R4#Show ip pim rp map*

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

  RP 2.2.2.2 (?), v2

    Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150

         Uptime: 00:00:32, expires: 00:02:05

*Step five:*

* *

*In the following step an access-list is configured to identify the RIP
traffic being sent from 10.1.12.1 (R1s F0/0 interface) to a broadcast IP
address destined for RIP. *

*R2(config)#Access-list 100 permit udp host 10.1.12.1 eq rip host
255.255.255.255 eq rip*

* *

*The following command specifies the forwarding of broadcast messages
destined to UDP 520 (RIP):*

R2(config)#*ip forward-protocol udp rip*

*The following command is configured to converts the broadcast traffic
arriving at the F0/0 interface of the first hop router (The router closest
to the source) destined for UDP port 520 (RIP) to a multicast group
destination address of 224.1.1.1:*

* *

R2(config)#int F0/0

R2(config-if)#*ip multicast helper-map broadcast 224.1.1.1 100 ttl 3*

*The TTL is required or else R4 will drop the packets*

*On R4*

*On the last hop router, the traffic is once again identified using
access-list 100 and forwarding of broadcast messages destined to UDP 520
(RIP) is specified:*

R4(config)#*access-list 100 permit udp host 10.1.12.1 any eq rip*

R4(config)#*ip forward-protocol udp rip*

* *

*In the following command, the last hop router (Router closest to the group
members) is configured to convert the multicast traffic arriving at S0/0.43
interface back to broadcast at the outgoing interface of F0/0. *

* *

R4(config)#Int S0/0.43

R4(config-subif)#*ip multicast helper-map 224.1.1.1 10.1.45.255 100*

*Since the traffic will be sent to the F0/0 interface of R4 as a directed
broadcast, directed broadcast must be enabled:*

R4(config)#int f0/0

R4(config-if)#*ip directed-broadcast*

* *

*Step Six:*

*Since the RIPv2 updates will be coming from another subnet (10.1.12.0 /24)
the validation of the source IP address by RIPv2 will fail (this is called
the sanity check) therefore, RIP routes will NOT be processed by R5, in this
step the validation of source IP address of the Updates are disabled:*

*On R5*

R5(config)#router rip

R5(config-router)#*no validate-update-source*

*To verify the configuration:*

* *

*On R5*

*R5#Sh ip route rip*

* *

*R 1.0.0.0/8* [120/1] via 10.1.12.1, 00:00:05

*Note R5 receives the RIPv2 route/s advertised by R1. *

* *

On Mon, May 25, 2009 at 1:27 PM, Ryan West <rwest_at_zyedge.com> wrote:

> Hello Wouter,
>
> Check out volume1 ver5 mcast labs, it is verified using another hit in your
> ACL combined with broadcast DNS resolution. Turn back on ip domain-lookups
> and you should see the hits on both sides, the hits on the other broadcast
> to mcast helper map ACL and the debug mpacket traffic can be used to verify
> it.
>
> -ryan
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Wouter Prins
> Sent: Monday, May 25, 2009 2:49 PM
> To: Cisco certification
> Subject: how to properly verify a broadcast to multicast-helper?
>
> hey all,
>
> i was wondering how you can verify a broadcast to multicast helper-map? i
> labbed this up and i noticed that i cannot send an ip sla with a udpecho to
> the broadcast address (255.255.255.255) as this is disallowed.
>
> So i thought i would send the udpecho to the ip broadcast address of that
> subnet: 174.1.26.255 and it is properly send out:
>
> *Mar 1 02:22:52.391: UDP: Random local port generated 49538, network 1
> *Mar 1 02:22:52.395: Reserved port 49538 in Transport Port Agent for UDP
> IP
> type 1
> *Mar 1 02:22:52.395: UDP: sent src=174.1.26.6(49538),
> dst=174.1.26.255(3434), length=24
>
> Now on the router configured for the broadcast to multicast conversion i
> configured the following on the interface receiving these udpecho's:
>
> RSRack1R2#
> interface FastEthernet0/0
> description "facing ip sla router"
> ip address 174.1.26.2 255.255.255.0
> ip broadcast-address 174.1.26.255
> ip pim sparse-mode
> ip multicast helper-map broadcast 226.26.26.26 100
> no ip mroute-cache
> end
> interface Serial1/0
> description "this interface should have the converted broadcast"
> ip address 174.1.23.2 255.255.255.0
> ip pim sparse-mode
> no ip mroute-cache
> frame-relay map ip 174.1.23.3 203 broadcast
> no frame-relay inverse-arp
> end
>
> RSRack1R2#show access-list 100
> Extended IP access list 100
> 10 permit udp any any eq 3434
> RSRack1R2#show run | incl forward
> ip forward-protocol nd
> ip forward-protocol udp 3434
> RSRack1R2#show deb
> Generic IP:
> IP multicast packets debugging is on
> UDP:
> UDP packet debugging is on
> RSRack1R2#
> RSRack1R2#show ip pim rp-hash 226.26.26.26
> RP 150.1.1.1 (?), v2v1
> Info source: 150.1.3.3 (?), elected via Auto-RP
> Uptime: 01:35:23, expires: 00:02:53
> PIMv2 Hash Value (mask 0.0.0.0)
> RP 150.1.1.1, via Auto-RP
> RSRack1R2#show ip rpf 150.1.1.1
> RPF information for ? (150.1.1.1)
> RPF interface: Serial1/0
> RPF neighbor: ? (174.1.23.3)
> RPF route/mask: 150.1.1.0/24
> RPF type: unicast (ospf 1)
> RPF recursion count: 0
> Doing distance-preferred lookups across tables
> RSRack1R2#
>
> I dont see any packets being forwarded (RP-mappings are fine and no RPF
> failures occuring).
>
> Anyone who has a better idea on verifying this and perhaps why this is not
> working? :)
>
> --
> Wouter Prins
> wp_at_null0.nl
> 0x301FA912
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

--
Narbik Kocharians
CCSI#30832, CCIE# 12410 (R&S, SP, Security)
www.MicronicsTraining.com
Sr. Technical Instructor
Blogs and organic groups at http://www.ccie.net
Received on Mon May 25 2009 - 15:07:59 ART

This archive was generated by hypermail 2.2.0 : Mon Jun 01 2009 - 07:04:43 ART