dokucama

User Tools

Site Tools

Trace: • storage • irr
fintech:multicast

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
fintech:multicast [2023/03/22 19:40] – jotasandokufintech:multicast [2025/05/18 10:02] (current) – jotasandoku
Line 1: Line 1:
-  * Cisco fintech architecture: MDNA [[https://www.cisco.com/c/dam/en_us/solutions/industries/docs/finance/md-arch-ext.pdf|External_Link]]+  * Multicast summary [[https://chatgpt.com/s/dr_6829afd200848191914e65c55e127de2|External_Link]]
  
 TECH NOTES: TECH NOTES:
Line 29: Line 29:
     * “BLOCK_OLD_SOURCE” Record type 6 indicating it is no longer interested to hear multicast traffic to that group from specific host.     * “BLOCK_OLD_SOURCE” Record type 6 indicating it is no longer interested to hear multicast traffic to that group from specific host.
  
-MEMBERSHIP-QUERY:\\+MEMBERSHIP-QUERY (igmp query):\\
   * Sent by the last hop router. Normally when a listener has left a group and it wants to know if there are still anybody in there interested on the group.   * Sent by the last hop router. Normally when a listener has left a group and it wants to know if there are still anybody in there interested on the group.
   * General Query – to learn complete multicast reception state of the neighboring interface. Sent to 224.0.0.1    * General Query – to learn complete multicast reception state of the neighboring interface. Sent to 224.0.0.1 
Line 71: Line 71:
 ---- ----
 **Remember: dynamic RPs are preferred to statically defined** **Remember: dynamic RPs are preferred to statically defined**
-\\ +  * __BSR__: IEEE standard  where multicast control rely entirely on the PIM packets. So no special configs required to advertise RP when yo configure network to pim sparse-mode. 
-__BSR__: IEEE standard  where multicast control rely entirely on the PIM packets. So no special configs required to advertise RP when yo configure network to pim sparse-mode. +  * __AUTO-RP__: Having multiple candidates for the role of RP and mapping agent greatly enhances the redundancy of the PIM-SM network. Redundancy reduces the risk of groups (configured in sparse-dense mode) reverting to dense mode operation if an RP cannot be located. To eliminate this risk, we recommend configuring a sink RP on every router in the network. [[https://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/rps.html#wp1038139|Link]] 
-\\ +  * __ANYCAST RP__ : In practice, anycast is preferred over bsr/auto-rp 
-__AUTO-RP__: Having multiple candidates for the role of RP and mapping agent greatly enhances the redundancy of the PIM-SM network. Redundancy reduces the risk of groups (configured in sparse-dense mode) reverting to dense mode operation if an RP cannot be located. To eliminate this risk, we recommend configuring a sink RP on every router in the network. [[https://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/rps.html#wp1038139|Link]] +    * Classical anycast: lo100 (shared loopback), msdp betweeen lo0 shared 'sa' state about sources. 
-\\ +    * PIM-based anycast (RFC 4610): lo100 (shared loopback). State is shared in the PIM messages themselves. Requires this command ''ip pim anycast-ip <lo100-IP> <member-N-IP>'' 
-__ANYCAST RP__ : In practice, anycast rp with msdp is preferred over bsr/auto-rp +  * __SSM__: Is becoming very popular. No RP, all SPT, a little less of state. Requires IGMPv3 
-\\ +  * __BIDIR__: ONLY SHARED TRESS (*,G) - central bidirectional RP which is ALWAYS in the datapath 
-__SSM__ +    * Bidir would not use source trees to better scale its routing table, so a new mechanism is required for Bidir sources to reach the rendezvous point. This new mechanism is called the designated forwarder (DF).  
-\\ +    * There’s no SPT switchover. 
-__BIDIR__: ONLY SHARED TRESS (*,G) - central bidirectional RP which is ALWAYS in the datapath +    * No RPF so traffic can go in both directions. 
-\\ +    * In absence of the above, loops are prevented by having a, fixed, DF router. 
-Bidir would not use source trees to better scale its routing table, so a new mechanism is required for Bidir sources to reach the rendezvous point. This new mechanism is called the designated forwarder (DF).  +    * DF (designated forwarder) we have one per segment (no per group so several in the way from source to the DR). Role of the DR as well as its election (remember higher IP wins for DR, lower for querier) is important. This is because the DR is the ONLY one forwarding data upstream PER SEGMENT (ie per Ethernet segment, therefore there can be several DRs from  Rest do it downstream only.
-There’s no SPT switchover. +
-\\ +
-No RPF so traffic can go in both directions. +
-\\ +
-In absence of the above, loops are prevented by having a, fixed, DF router. +
-\\ +
-DF (designated forwarder) we have one per segment (no per group so several in the way from source to the DR). Role of the DR as well as its election (remember higher IP wins for DR, lower for querier) is important. This is because the DR is the ONLY one forwarding data upstream PER SEGMENT (ie per Ethernet segment, therefore there can be several DRs from  Rest do it downstream only.+
  
  
Line 101: Line 94:
   * DESIGNATED ROUTER: Routers configured for IP multicast send PIM hello messages to determine which router will be the designated router (DR) for each LAN segment (subnet). The hello messages contain the router's IP address, and the router with the **highest IP address becomes the DR**   * DESIGNATED ROUTER: Routers configured for IP multicast send PIM hello messages to determine which router will be the designated router (DR) for each LAN segment (subnet). The hello messages contain the router's IP address, and the router with the **highest IP address becomes the DR**
     * in each LAN segment where one or more multicast enabled routers are connected to you can see the three roles of PIM DR, IGMP querier, PIM forwarder.     * in each LAN segment where one or more multicast enabled routers are connected to you can see the three roles of PIM DR, IGMP querier, PIM forwarder.
-      * **PIM DR has to represent the LAN segment/broadcast domain in the PIM tree topology so it is responsible to contact the RP in PIM SM or sparse-dense mode.**+  * PIM FORWARDER: Is different. When data can be sent to a receiver via two different routers, there's an 'ASSERT' election process to choose one of them, this becomes the pim forwarder
   * QUERIER: When a multicast-enabled router first becomes active on a subnet, it assumes that it is the Querier — the router responsible for sending all General and Group-Specific Queries to the subnet. When there are multiple routers, the rule for electing the Querier is simple: The router whose connected interface has the **lowest IP address is the Querie**. [[http://www.bscottrandall.com/5.1.3.html]]   * QUERIER: When a multicast-enabled router first becomes active on a subnet, it assumes that it is the Querier — the router responsible for sending all General and Group-Specific Queries to the subnet. When there are multiple routers, the rule for electing the Querier is simple: The router whose connected interface has the **lowest IP address is the Querie**. [[http://www.bscottrandall.com/5.1.3.html]]
 +
  
   show ip igmp snooping querier    show ip igmp snooping querier 
Line 220: Line 214:
  
 **__SERVER SIDE TOOLS (generate multicast traffic):__**\\ **__SERVER SIDE TOOLS (generate multicast traffic):__**\\
-* https://low-orbit.net/linux-how-to-join-multicast-group +If we cannot install anything (and we have pyton3 we can paste these scripts:
-* https://github.com/yantisj/multicast-test +
-  cd mtools +
-  apt install make +
-  apt install gcc +
-  make +
-  ./msend -g 224.2.2.2 -p 2222 -t 8 -text "test"+
  
-**Mausezahn is a free fast traffic generator** (very promising): +GENERATING MULTICAST TRAFFIC 
- +  #!/usr/bin/python3 
-  mz eth0 -c 0 -d 10msec -B 230.1.1.1 -t udp "dp=32000,dscp=46" -P "Multicast test packet"  # Send IP multicast packets to the multicast group 230.1.1.1 using a UDP header with destination port 32000 and set the IP DSCP field to EF (46). Send one frame every 10 msec: +  import socket 
- +  # Usage in bash : 'while true; do ./msend.py; sleep 2; done' 
-IPERF+  MCAST_GRP = '239.1.1.1' 
 +  MCAST_PORT = 5007 
 +  # regarding socket.IP_MULTICAST_TTL 
 +  # --------------------------------- 
 +  # for all packets sent, after two hops on the network the packet will not 
 +  # be re-sent/broadcast (see https://www.tldp.org/HOWTO/Multicast-HOWTO-6.html) 
 +  MULTICAST_TTL = 250 
 +  sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) 
 +  sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, MULTICAST_TTL) 
 +  # For Python 3, change next line to 'sock.sendto(b"robot", ...' to avoid the 
 +  # "bytes-like object is required" msg (https://stackoverflow.com/a/42612820) 
 +  sock.sendto(b"robot", (MCAST_GRP, MCAST_PORT)) 
 +  !  
 +  ! Execute from the cli with: 
 +  while true; do ./msend.py; sleep 2; done 
 +  
 +SUBSCRIBING TO MULTICAST STREAM  
 +  #!/usr/bin/python3 
 +  import socket 
 +  import struct 
 +  import sys 
 +  multicast_group = '239.1.1.1' 
 +  server_address = ('', 5007) 
 +  # Create the socket 
 +  sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) 
 +  # Bind to the server address 
 +  sock.bind(server_address) 
 +  # Tell the operating system to add the socket to the multicast group 
 +  # on all interfaces. 
 +  group = socket.inet_aton(multicast_group) 
 +  mreq = struct.pack('4sL', group, socket.INADDR_ANY) 
 +  sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq) 
 +  while True: 
 +      print('\nwaiting to receive message', file=sys.stderr) 
 +      data, address = sock.recvfrom(1024) 
 +   
 +      print('\nreceived ' + str(len(data)) + ' bytes from ' + ''.join(str(address)), file=sys.stderr) 
 +      print(data, file=sys.stderr) 
 +   
 + #    string = "AcK" 
 + #    string_utf = string.encode() 
 + #    print('\nsending ack to  ' + ''.join(str(address)), file=sys.stderr) 
 + #    sock.sendto(string_utf, address) 
 +       
 +       
 +If we can, install ''IPERF'':
   iperf -c 224.0.0.1 -u -B 10.1.0.54 -t 3600 -T 255 # traffic for this group from this address (needs to belong to the switch)   iperf -c 224.0.0.1 -u -B 10.1.0.54 -t 3600 -T 255 # traffic for this group from this address (needs to belong to the switch)
  
Line 245: Line 278:
   * pim cannot be enabled in loopback interfaces. Nonetheless is not required to enable RP.   * pim cannot be enabled in loopback interfaces. Nonetheless is not required to enable RP.
  
-This is for static and BSR RP:+  ! This is for static and BSR RP:
   interface Vlan100   interface Vlan100
      ip address 10.1.8.3/24      ip address 10.1.8.3/24
Line 260: Line 293:
      ipv4      ipv4
         candidate Vlan100 priority 192 hashmask 30 interval 30         candidate Vlan100 priority 192 hashmask 30 interval 30
 +
 ---- ----
 +
 MULTICAST IN IOS-XR: MULTICAST IN IOS-XR:
  
Line 268: Line 303:
     spt-threshold infinity     spt-threshold infinity
     ssm disable     ssm disable
-  # This one in the sender to generate multicast traffic +
-  echo -n ABCDEFGHIJK | NC -VZU 224.1.1.1 7777+
 ---- ----
 +__IPV6 MULTICAST__
 +  * PIM > IPv6 PIM
 +  * **IGMPv2 > MLDv1**
 +  * **IGMPv3 > MLDv2**
 +
 +  ipv6 multicast-routing
 +  show ipv6 mroute
 +  !
 +  show ipv6 pim neighbor
 +  !
 +  show ipv6 mld group
 +  show ipv6 mld interface g0/0
 +  show ipv6 mld traffic  
 +
 +
 +
 +----
 +
  
 **BIER (bit indexed explicit replication)** **BIER (bit indexed explicit replication)**
fintech/multicast.1679514048.txt.gz · Last modified: (external edit)

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki