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:
