video – this video describes the task number 2 of this introduction to bgp multicast VPNs let's start like any other IP packet a multicast packet has a source and a destination IP address its destination IP address is multicast in other words it represents a group rather than an individual host however the source IP address of a multicast packet is not a multicast one it is the unicast IP address of the host acting as a source as you probably know unicast connectivity to the source is one of the most critical pieces of the multicast puzzle in this task there is a multicast source whose unicast IP address is represented as CS C for customer s for source this IP address belongs to a subnet that is advertised from c e1 to p e1 using external bgp you can see the bgp update and capture number 1 that is available for download and pcap format at the day 1 website like all the other captures so the e1 receives the route in a vrf called V RF 1 at this point it needs to riad ver ties the route in the context of the VPN it belongs to the resulting prefix contains the route distinguisher of v RF 1 the PE sends it via multi-protocol internal BGP to the route reflector which in turn sends the route to PE 2 P 3 and P 4 the PE is receiving this route re-advertise it to their neighboring sees using external BGP this is how ce3 learns how to reach the unicast IP address of the customer source let's see these routes in detail the 10.10 10/20 for prefix belongs to the address family inet unicast in other words a fi 1 sa fi 1 however this is only true if the SI e is using multi protocol BGP although this is a valid option in this workshop the si es are configured to use Vennela bgp which has no multi-protocol extensions so the address family identifiers are not included explicitly in the BGP update next pe1 converts the route into AI net VPN unicast format corresponding to a fi one sa fi 128 PE one as VPN context to the route by adding a route distinguisher and a VPN label to the original prefix the route distinguisher allows for the same prefix to be advertised in the context of different VPNs while remaining unique also packets arriving to PE one from the core an address to 10 10 10 / 24 subnet in vrf one should have an MPLS label equal to this VPN label when PE 3 wants to send a unicast packet to the customer source it typically needs to push 2 MPLS labels the VPN label and the transport label of the label switched path that goes from PE 3 to PE 1 y 2 PE 1 because it's the next top of the BGP route 172 16 1111 in this workshop you use LDP to signal the MPLS labels for transporting unicast traffic later in this workshop you will use a different protocol to signal the tunnels for multicast transport finally an extended community called Route target is added to influence how the route will be imported in remote Pease like pe3 more precisely in which V ahrefs it will be installed according to the import policies in the remote Pease in this scenario you're using a full mesh topology so all the unicast routes in vrf one carry the same route target regardless of which PE is advertising them you

You May Also Like