The simplest way to interconnect 3 or more routers in the same broadcast domain (and the same subnet) is by attaching them to a switch (or hub) in the same vlan.

In case they’re separated by long distances, an ISP may be required to put them together. From a network access perspective, they could be interconnected in ways such as:

• ME
• PPPoE
• DMVPN
• Pseudo-wire in VPLS

A broadcast (a ping to 100.0.0.255/24 as an example) is not treated the same way among these features. We focus only on routers that are connecting via Ethernet.

PPPoE runs in a Hub and Spoke fashion. R1, R2 and R3 share the same subnet but a broadcast is sent to only the last directly attached router per the output of Cef or the first attached router per the ip routing table output.

R1#sh ip cef 100.0.0.255 100.0.0.0/24 attached to Virtual-Access2.1 attached to Virtual-Access2.2 R1#

R1#sh ip route 100.0.0.255 Routing entry for 100.0.0.0/24 Known via “connected”, distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: directly connected, via Virtual-Access2.2 Route metric is 0, traffic share count is 1 * directly connected, via Virtual-Access2.1 Route metric is 0, traffic share count is 1 R1#

R1#sh ip cef 100.0.0.255 internal 100.0.0.0/24, epoch 0, flags attached, connected, RIB[C], refcount 5, per-destination sharing Sources: RIB feature space: IPRM: 0x0003800C ifnums: Virtual-Access2.1(9) Virtual-Access2.2(11) path 6B161208, path list 6B186D18, share 1/1, type connected prefix, for IPv4 connected to Virtual-Access2.1, adjacency IP adj out of Virtual-Access2.1 69240EA0 path 6B161278, path list 6B186D18, share 1/1, type connected prefix, for IPv4 connected to Virtual-Access2.2, adjacency IP adj out of Virtual-Access2.2 69240D40 output chain: loadinfo 691FAD24, per-session, 2 choices, flags 0083, 5 locks flags: Per-session, for-rx-IPv4, 2buckets 2 hash buckets < 0 > IP adj out of Virtual-Access2.1 69240EA0 < 1 > IP adj out of Virtual-Access2.2 69240D40 Subblocks: None R1#

R1#ping 100.0.0.255 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 100.0.0.255, timeout is 2 seconds: *Nov 20 20:49:17.183: IP: s=100.0.0.1 (local), d=255.255.255.255 (Virtual-Access2.2), len 100, sending broad/multicast […] *Nov 20 20:49:17.211: IP: s=100.0.0.3 (Virtual-Access2.2), d=100.0.0.1, len 100, input feature, MCI Check(94), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Nov 20 20:49:17.215: IP: tableid=0, s=100.0.0.3 (Virtual-Access2.2), d=100.0.0.1 (Virtual-Access2.2), routed via RIB *Nov 20 20:49:17.215: IP: s=100.0.0.3 (Virtual-Access2.2), d=100.0.0.1 (Virtual-Access2.2), len 100, rcvd 3 *Nov 20 20:49:17.219: IP: s=100.0.0.3 (Virtual-Access2.2), d=100.0.0.1, len 100, stop process pak for forus packet Reply to request 0 from 100.0.0.3, 40 ms […]

We change the sharing algorithm from per-destination to per-packet but with no help:

R1#sh ip cef 100.0.0.255 de 100.0.0.0/24, epoch 0, flags attached, connected, per-packet sharing attached to Virtual-Access2.1 attached to Virtual-Access2.2 R1#

R1# R1#ping 100.0.0.255 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 100.0.0.255, timeout is 2 seconds:Reply to request 0 from 100.0.0.3, 20 ms Reply to request 1 from 100.0.0.3, 40 ms Reply to request 2 from 100.0.0.3, 16 ms Reply to request 3 from 100.0.0.3, 32 ms Reply to request 4 from 100.0.0.3, 36 ms R1#

We check that no packet is being received from R2 (with ip address: 100.0.0.2).

With DMVPN, the situation is better as per now:

R1#sh ip cef 101.0.0.255 101.0.0.255/32 receive for Tunnel0 R1#

R1#ping 101.0.0.255 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 101.0.0.255, timeout is 2 seconds:Reply to request 0 from 101.0.0.2, 28 ms Reply to request 0 from 101.0.0.3, 28 ms Reply to request 1 from 101.0.0.3, 60 ms Reply to request 1 from 101.0.0.2, 60 ms Reply to request 2 from 101.0.0.3, 28 ms Reply to request 2 from 101.0.0.2, 28 ms Reply to request 3 from 101.0.0.3, 28 ms Reply to request 3 from 101.0.0.2, 28 ms Reply to request 4 from 101.0.0.3, 28 ms Reply to request 4 from 101.0.0.2, 28 ms R1#

R1#sh run inter tun 0 Building configuration…Current configuration : 192 bytes ! interface Tunnel0 ip address 101.0.0.1 255.255.255.0 no ip redirects ip nhrp map multicast dynamic ip nhrp network-id 101 tunnel source FastEthernet0/0 tunnel mode gre multipoint endR1#

Still that with DMPVN Phase 1, only R1 responds to R2:

R2#ping 101.0.0.255 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 101.0.0.255, timeout is 2 seconds:Reply to request 0 from 101.0.0.1, 60 ms Reply to request 1 from 101.0.0.1, 44 ms Reply to request 2 from 101.0.0.1, 12 ms Reply to request 3 from 101.0.0.1, 32 ms Reply to request 4 from 101.0.0.1, 40 ms R2#

R2#sh run inter tun 0 Building configuration…Current configuration : 235 bytes ! interface Tunnel0 ip address 101.0.0.2 255.255.255.0 ip nhrp map 101.0.0.1 1.0.0.101 ip nhrp map multicast 1.0.0.101 ip nhrp network-id 101 ip nhrp nhs 101.0.0.1 tunnel source FastEthernet0/0 tunnel destination 1.0.0.101 endR2#

With DMVPN Phase 3, two enchancements are added to the first and second phases:

• GRE Multipoint at Spoke which allows Spoke to Spoke tunnels
• And NHRP redirect at Hub that hints Spoke to direct upcoming packets toward target Spoke
• Cef shortcuts at Spoke enables local optimzation of Cef operation upon reception of NHRP redirects.

Now we could ping the broadcast address from the hub. To obtain the same result from R2 as an example, it is sufficient to add a new NHRP multicast map pointing towards R3:

R2#ping 101.0.0.255 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 101.0.0.255, timeout is 2 seconds:Reply to request 0 from 101.0.0.1, 32 ms Reply to request 0 from 101.0.0.3, 60 ms Reply to request 1 from 101.0.0.1, 60 ms Reply to request 1 from 101.0.0.3, 76 ms Reply to request 2 from 101.0.0.1, 32 ms Reply to request 2 from 101.0.0.3, 48 ms Reply to request 3 from 101.0.0.1, 40 ms Reply to request 3 from 101.0.0.3, 60 ms Reply to request 4 from 101.0.0.1, 28 ms Reply to request 4 from 101.0.0.3, 48 ms R2#

R2#sh run inter tun 0 Building configuration…Current configuration : 334 bytes ! interface Tunnel0 ip address 101.0.0.2 255.255.255.0 no ip redirects ip nhrp map 101.0.0.1 1.0.0.101 ip nhrp map 101.0.0.3 1.0.0.103 ip nhrp map multicast 1.0.0.101 ip nhrp map multicast 1.0.0.103 ip nhrp network-id 101 ip nhrp nhs 101.0.0.1 ip nhrp shortcut tunnel source FastEthernet0/0 tunnel mode gre multipoint endR2#

At the end, DMPVN is very flexible when it comes to the handling of broadcast domains of 3 or more routers as we compare to classical Ethernet, PPPoE, etc.