• Tag : Multicast

 
 

IGMP Host-proxy

Interfaces on the switch can be configured to serve as IGMP host proxies. An IGMP host proxy exchanges IGMP reports (joins/leaves) between networks whose connection does not support PIM along network boundaries. Let’s take the example shown below: The customer network connects to the sender network through the edge switch’s Ethernet 1 interface, which is configured as an IGMP host proxy. PIM is enabled within the publisher and customer networks but not on the connection between the networks.   When only “ip igmp host-proxy” is configured on the interface, IGMP reports will be sent for any (*,G) or (S,G) entry...
Continue reading →

Pim SSM IPV4 Non-DR OIF Installation for Fast Failover

Description In a Mlag setup with Pim SSM, one peer becomes the DR for a layer 3 interface and is responsible for routing multicast traffic on that interface. If this DR fails, the other peer, who was originally non-DR but becomes the new DR, may need to establish  SPT trees to get the multicast traffic or at the very least, add interfaces to OIF list of many multicast routes. This can be very disruptive to multicast traffic flow if there are thousands of routes.  This feature “Pim SSM Non-DR OIF Installation” helps to reduce convergence times and decrease traffic loss...
Continue reading →

Enable source specific multicast

We currently have a querier (v3) running on VLAN 400 and it perfectly works for multicast group joins within that VLAN. However when performing a source specific group join it seems to forward traffic from other sources as well. My transmitting part is sending on group 239.211.4.99 with source address 172.216.0.25 My receiving part is subscribed to group 239.211.4.99 with source address 172.216.0.11 There is not multicast traffic to group 239.211.4.99 from source 172.216.0.11; Expected result is that no multicast packets would be received, but it receives all traffic from 172.216.0.25. What configuration is required to enable source specific multicast...
Continue reading →

Multicast forwarding using BESS (MFA)

Description The PIM routing protocol builds multicast routing state based on control packets and multicast data events. In our current implementation, we rely on the Linux kernel to notify the PIM agents regarding the multicast data events. Also, the Linux kernel forwards a multicast data packet before hardware gets programmed to do so. As an alternative to the Linux kernel, Multicast Forwarding based on BESS ( Berkeley Extensible Soft Switch ), MFA, can be used to generate multicast data events and forward multicast data packets. As the first release of MFA, it is officially supported for IPv6 PIM SSM. Although...
Continue reading →

IPv6 support for PIM source specific multicast

Description This feature adds support for PIM-SSM ( Source Specific Multicast ) for IPv6 Multicast Routing on platforms listed below. The TOI for the support in earlier versions/platforms is available here. Reference TOI for support of IPv6 Multicast Routing support is available here. Basic configuration commands can be found in the aforementioned TOI for enabling Ipv6 multicast routing Platform compatibility The following platforms are supported from software version 4.22.0 DCS-7050QX, DCS-7050SX, DCS-7050TX DCS-7050QX2, DCS-7050SX2, DCS-7050TX2 DCS-7050CX3, DCS-7050SX3 DCS-7060CX, DCS-7060CX2, DCS-7060SX2 DCS-7260CX, DCS-7260CX3, DCS-7260QX DCS-7300X, DCS-7300X3 series Show Commands The below commands can be leveraged in order to view the multicast...
Continue reading →

Introduction to IPv6 Multicast-Routing

Overview IPv6 multicast routing protocols are used to distribute ipv6 datagrams to one or more recipients. IPv6 PIM builds and maintains multicast routing using reverse path forwarding (RPF) based on unicast routing table. IPv6 PIM is protocol-independent and can use routing tables consisting of OSPFv3, IPv6 BGP or static routes, for RPF lookup. MLD is used to discover multicast hosts and maintain group membership on directly attached link. IPv6 multicast-routing has been introduced in the 4.21.0F release and is supported on 7280R and 7500R. Source-specific multicast (SSM) is currently supported on L3 routed port. PIM Sparse Mode In PIM-SM, each...
Continue reading →

Multicast in VXLAN with BGP EVPN control-plane

 Hello, We are trying to run multicast in data center overlay network. In our data centers we are using L3 leaf-spine topology with VXLAN. For the control plane BGP EVPN is used.  Leaf switches are deployed in an MLAG configuration. We want to run multicast between hosts that are on same vlan across switches in different MLAG domains. Multiple multicast receivers, as well as multiple senders are connected to different MLAG domains and are all in the same VLAN. Multicast receiver can receive m-c stream from the sender if both of them are in the same MLAG domain. But if receiver is connected to...
Continue reading →

Alert for multicast routing table overflow?

I have a customer with an Arista-DCS-7150S-52-CL-R running 4.15.9M code.  They have a fairly complex set of hosts and a large number of multicast groups.  Occasionally, one host will become deaf to a group.  A “netstat -ng” on the host indicates that the operating system still thinks it is subscribed to the group. Is there any way to determine if the routing table is overflowing and multicast routes are being trimmed?  Or if other limited multicast resources are being exhausted? I suspect the solution is to reduce the number of multicast groups being used, but we would like to determine the root...
Continue reading →

MBR (Multicast Border Router)

Intro Enabling PIM MBR on an interface (where we don’t have an upstream PIM neighbor) will allow multicast traffic from remote sources that are outside of our PIM domain to be treated as locally connected sources. We typically see this scenario when we are receiving multicast feeds from a remote Exchange and a PIM neighbourship is not established on our upstream links. In the current PIM implementation (EOS 4.14.0F and later) EOS will drop multicast traffic that is not considered to be locally connected by default and we need to configure MBR to allow this multicast data. In the interfaces...
Continue reading →

show ip mfib output – “notify”

Hi, can anyone tell me what “notify” means in the following output, does it relate to MSDP? (note MSDP not running on the device): sh ip mfib g.g.g.gActivity poll time: 60 secondsg.g.g.g s.s.s.s Vlan256 (iif) Vlan152 (notify) Vlan251 Activity 0:17:20 agog.g.g.g 0.0.0.0/0 Vlan256 (iif) Vlan251  

VXLAN to VLAN trunk port – multiple multicast-groups?

Hello everybody, I have configured the following VXLAN networks using VMware vShield which should be mapped to VLANs on a virtual Arista Switch (vEOS 4.15.OF): VNI5000 / Multicast 225.1.1.1 / Map to VLAN 500 VNI5001 / Multicast 225.1.1.2 / Map to VLAN 501 VNI5002 / Multicast 225.1.1.3 / Map to VLAN 503 But on the interface vxlan 1, I can only set one multicast-group on the interface vxlan 1. Is there the possibility to set multiple multicast-group on this interface (one multicast-group per VNI)? I also cannot create more than one VXLAN interface – is this a general limitation or...
Continue reading →

Layer 3 Leaf-Spine – Rendezvous Point Placement?

Hello everybody, I have configured a leaf-spine architecture (4 leafs, 2 spines), see attached image. L3 routing is enabled on leafs and spines and eBGP is used between them. To enable VXLAN (from VMware Hosts), multicast needs to be configured. So far, ip multicast-routing and ip pim sparse-mode is set. Where do I configure the rendezvous point (RP) and which method would I use? I would prefer to place it on the spine switches using anycast-rp, but one spine switches does not reach the other spine switch (as the route to spine1 is not announced to spine2 by the leafs...
Continue reading →

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: