• When R6 sends broadcast UDP packets on port 5000, those packets
should be transported across the network and broadcast on the VLAN 37
segment.
• Use the group 239.1.1.100 to accomplish this task and use DNS
broadcasts for testing.
• You may use static mroutes if needed to accomplish this task.
------------------------------------------------------------------------
The purpose of this feature is to allow forwarding of broadcast traffic across a
multicast capable network. Generally, you need a single Layer 2 domain between
two nodes to let them hear each other’s broadcast packets. However, broadcast
UDP packets can be relayed between two subnets using a special IOS feature
known as the helper-address. There are two variations of this feature:
1) Unicast helper (ip helper-address), which converts the broadcast
destination address to the fixed unicast IP address. Most often this feature is
used with DHCP to forward requests to the server.
2) Multicast helper (ip multicast helper-map), which converts the
broadcast destination to a fixed multicast address.
The multicast helper-map feature allows scalable forwarding of broadcast traffic
between disjoined segments. This is often needed to support legacy applications
like stock tickers that use broadcast to deliver information to multiple sources
simultaneously. To configure multicast helper, follow the steps outlined below:
Step 1:
Set up a multicast network between the segments that should exchange
broadcast packets. You should select a group to deliver the broadcast packets
and decide which PIM mode to use. If you chose PIM SM, make sure the group
you chose maps to an RP. Make sure multicasting works, by joining an interface
on the egress router (closest to the broadcast receiver) to the selected group and
ping this group from the ingress router (closest to the broadcast source).
Step 2:
Enabling broadcast forwarding on the ingress router – the one directly connected
to the source. If there are multiple sources, you have to configure all respective
routers. Use the command ip forward-protocol udp <port-number> to
enable forwarding of broadcast UDP packets sent to the specified port-number.
Step 3:
Configure a multicast helper-map on the ingress routers to redirect broadcast
packets to the selected multicast address. The syntax for this interface-level
command is ip multicast helper-map broadcast <mcast-address>
<ACL>. The access-list controls which broadcast packets are eligible to be
converted into the multicast. For example, if you want to forward UDP packets
destined to port 5000 use an access-list similar to the following: access-list
100 permit udp any any eq 5000. Note that the same UDP port must be
enabled for broadcast forwarding at Step 2. All broadcast traffic received on the
configured interface that matchs the access-list is converted and sent to the
specified multicast address. If the group is in sparse mode, the ingress router will
register the source with the RP, per the usual procedure.
Step 4:
Enable broadcast forwarding on the egress router, i.e. the router directly
connected to the destination subnet. Use the same command that you used in
Step 2 ip forward-protocol udp <port-number> to accomplish this.
Next, enable multicast helper map on the egress router for all interfaces that may
receive multicast traffic. Note that you should not configure the multicast-helper
on the interface connected to the destination. Use the command ip multicast
helper-map <mcast-group> <directed-broadcast-IP> <ACL> where
mcast-group is the same group you used in Step 3 and directed-broadcast-IP is
the broadcast subnet IP address on the segment that receives the broadcast
traffic.
Step 5:
Enable directed broadcasts on the interface connected to the receiving segment
using the command ip directed-broadcast. This is needed to successfully
send broadcasts out of this segment. By default, the broadcasts are sent to the
address 255.255.255.255 irrespective of the directed-broadcast-IP
configured at Step 4. If you want to use a different address, put the command ip
broadcast-address <IP> on the same segment.
To test your configuration, you will need a broadcast packet source. You may
use the IP SLA command to generate UDP packets to a segment broadcast
address, but this might not work on some platforms/IOS versions. If that’s the
case, you may use either of the following two methods:
1) Enable DNS name resolution but do not configure a DNS server. After this, the
router will broadcast for any DNS name entered in the command line using the
address 255.255.255.255 out all interfaces. You will need to adjust the port in
your access-lists to forward this broadcast traffic.
2) Configure an extended traceroute command using parameters to trace to
the broadcast destination, starting off the port number that is covered by your
ACL.
Pitfall
There are some caveats associated with our particular scenario.
1) You need to select the proper ingress router. The group 239.1.1.100 is going
to be transported in sparse mode. Thus, the source should be registered with the
RP first. The only router allowed to register sources is the DR, which is R1. Thus,
we must configure R1 to generate the multicast packets.
2) The next issue, is that R3 is a stub multicast router. Thus, it does not
exchange any PIM messages with R5 and it won’t join group 239.1.1.100 once
you configure the multicast helper on the ingress interface. To resolve this issue,
SW1 should be configured with a static IGMP join for group 239.1.1.100 to let R5
know about that.
3) If you loaded our default configuration, then you will see that R3 has three
equal-cost routes to reach the VLAN 146 segment. This will cause RPF failures,
unless you configure ip multicast multipath on R3, allowing R3 to
perform RPF across the equal-cost paths.
4) Finally, R5 will prefer the path to the VLAN 146 segment across the Serial
connection to R4. Thus, in order to allow R5, which acts on behalf of R3, to join
the SPT towards the VLAN 146 segment, you need a static mroute on R5, to
make R1 the RPF neighbor for the VLAN 146 subnet.
Also notice that this scenario requires PIM NBMA mode to be configured on R5’s
Frame-Relay interface to work properly.
------------------------------------------------------------------------
R1:
ip forward-protocol udp 5000
!
ip access-list extended TRAFFIC
permit udp any any eq 5000
permit udp any any eq 53
!
interface FastEthernet 0/0
ip multicast helper-map broadcast 239.1.1.100 TRAFFIC
R3:
ip forward-protocol udp 5000
ip multicast multipath
!
ip access-list extended TRAFFIC
permit udp any any eq 5000
permit udp any any eq 53
!
interface FastEthernet 0/0
ip directed-broadcast
ip broadcast-address 155.1.37.255
!
interface Serial 1/0.1
ip multicast helper-map 239.1.1.100 155.1.37.255 TRAFFIC
R5:
ip mroute 155.1.146.0 255.255.255.0 155.1.0.1
SW1:
interface FastEthernet0/3
ip igmp join-group 239.1.1.100
------------------------------------------------------------------------
For verification we are going to use DNS broadcasts sent from R6. Configure R6
to resolve DNS names, but do not provide any DNS server:
R6:
ip domain lookup
Enable debugging and start a traffic flow on R6:
Rack1R1#debug ip mpacket
Rack1R1#conf t
Rack1R1(config)#access-list 100 permit udp any any eq 53
Rack1R1#debug ip packet detail 100
Rack1R3#debug ip mpacket
Rack1R3#conf t
Rack1R3(config)#access-list 100 permit udp any any eq 53
Rack1R3#debug ip packet detail 100
Rack1R6#dddd
Translating "dddd"...domain server (255.255.255.255)
R1 accepts the broadcasts and converts them to multicast packets. Initially, the
SPT is not built and some packets are lost, and the OIL for the (S,G) is empty.
When the SPT is finally finished, everything will work smoothly.
*Mar 2 18:19:21.937: IP: s=155.1.146.6 (FastEthernet0/0), d=255.255.255.255, len 51, rcvd 2
*Mar 2 18:19:21.941: IP(0): s=155.1.146.6 (FastEthernet0/0) d=239.1.1.100 id=2, ttl=254, prot=17, len=65(51), mroute olist null
*Mar 2 18:19:40.597: IP: s=155.1.146.6 (FastEthernet0/0), d=255.255.255.255, len 50, rcvd 2
*Mar 2 18:19:40.601: IP(0): s=155.1.146.6 (FastEthernet0/0) d=239.1.1.100 (Serial0/0.1) id=0, ttl=254, prot=17, len=50(50), mforward
Rack1R1#
*Mar 2 17:52:51.621: IP(0): s=155.1.146.6 (Serial1/0.1) d=239.1.1.100 (FastEthernet0/0) id=1, ttl=252, prot=17, len=50(50), mforward
Rack1R3#
*Mar 2 17:52:54.909: IP: tableid=0, s=155.1.146.6 (Serial1/0.1), d=155.1.37.255 (FastEthernet0/0), routed via RIB
Check the mroute states on R1, R3 and R5 to ensure the traffic follows the SPT.
Rack1R1#show ip mroute 239.1.1.100
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.100), 00:05:27/stopped, RP 150.1.8.8, flags: SPF
Incoming interface: Serial0/0.1, RPF nbr 155.1.0.5
Outgoing interface list: Null
(155.1.146.6, 239.1.1.100), 00:00:11/00:03:28, flags: FT
Incoming interface: FastEthernet0/0, RPF nbr 155.1.146.6
Outgoing interface list:
Serial0/0.1, Forward/Sparse, 00:00:11/00:03:18
Rack1R1#
Rack1R5#show ip mroute 239.1.1.100
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.100), 00:22:24/stopped, RP 150.1.8.8, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 155.1.58.8
Outgoing interface list:
Serial0/0, 155.1.0.3, Forward/Sparse, 00:22:24/00:02:39
(155.1.146.6, 239.1.1.100), 00:00:58/00:02:29, flags: T
Incoming interface: Serial0/0, RPF nbr 155.1.0.1, Mroute
Outgoing interface list:
Serial0/0, 155.1.0.3, Forward/Sparse, 00:00:59/00:02:37
Rack1R5#
Rack1R3#show ip mroute 239.1.1.100
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.100), 00:07:15/stopped, RP 150.1.8.8, flags: SJCL
Incoming interface: FastEthernet0/0, RPF nbr 155.1.37.7
Outgoing interface list:
Serial1/0.1, Forward/Dense, 00:07:15/00:00:00
(155.1.146.6, 239.1.1.100), 00:01:54/00:01:30, flags: LJT
Incoming interface: Serial1/0.1, RPF nbr 155.1.0.5
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:01:54/00:00:00
Rack1R3#
----------------------------------------------------------------
By default, the ip helper-address command will forward these 8 UDP ports:
UDP PORT
|
Common Name.
|
69
|
TFTP
|
67
|
BOOTP Client
|
68
|
BOOTP Server
|
37
|
Time Protocol
|
49
|
TACACS
|
53
|
DNS
|
137
|
NetBios
|
138
|
NetBios Datagram
|
----------------------------------------------------------------
Furthermore by issuing "no ip forward-protocol udp 53" , the configuration appears in running config which verifies it is default behaviour.
Rack1R1(config)#no ip forward-protocol udp 53
Rack1R1(config)#
Rack1R1(config)#do sh run
...
no ip forward-protocol udp domain
沒有留言:
張貼留言