BGP Path Attributes


Path Attributes as the name suggests are the characteristics of an advertised BGP Route. BGP routing policy is set and communicated using the path attributes.

Path Attributes fall into one of the two categories
1. Well-known Path Attributes
2. Optional Path Attributes

Well-known: Meaning these attributes must be recognized by all the BGP implementations.

Well- Known BGP Path Attributes fall into two sub-categories known as
1. Mandatory (Called as Well-known Mandatory)
2. Discretionary (Called as Well-Known Discretionary)

Mandatory: This means the attribute must be always included and carried in all BGP update messages to peers. The BGP implementation has to recognize the attribute, accept it and also advertise it to its peers.

Discretionary: Meaning these are recognized by the BGP implementation but may or may not be sent in a specific Update message. Its up to the discretion of BGP Implementation to send or not to send these attributes in the update messages to the peers.

Optional: Meaning these attributes may or may not be supported by the BGP implementations.

Optional BGP Path attributes also fall into two sub-categories
1. Transitive (Called as Optional Transitive)
2. Non-transitive (Called as Optional Non-transitive)

Transitive: BGP process has to accept the path in which it is included and should pass it on to other peers even if these attributes are not supported. Meaning if any optional attribute is not recognized by a BGP implementation, then BGP looks to check if the transitive flag is set. If the transitive flag is set then BGP implementation should accept the attribute and advertise it to its other BGP Peers.

Non-transitive: If the BGP process does not recognize the attribute then it can ignore the update and not advertise the path to its peers. If the transitive  flag is not set then BGP implementation can quietly ignore the attribute, it does not have to accept and advertise this attribute to its other peers.

To Summarize the BGP Path Attribute Categories

  1. Well-known Mandatory: Recognized and Included in all BGP Update messages.
    2. Well-known Discretionary: Recognized and May or May not include in BGP Update messages
    3. Optional Transitive: Even if Not Supported it Still need to accept and Send in Update Message.
    4. Optional Non-transitive: Can be ignored and not advertise to peers.
LIST OF BGP PATH ATTRIBUTES
Attribute Name Category / Class
ORIGIN Well-Known Mandatory
AS_PATH Well-Known Mandatory
NEXT_HOP Well-Known Mandatory
LOCAL_PREF Well-Known Discretionary
ATOMIC_AGGREGATE Well-Known Discretionary
AGGREGATOR Optional Transitive
COMMUNITY Optional Transitive
MULTI_EXIT_DISC (MED) Optional Non-Transitive
ORIGINATOR_ID Optional Non-Transitive
CLUSTER LIST Optional Non-Transitive
MULTIPROTOCOL Reachable NLRI Optional Non-Transitive
MULTIPROTOCOL Unreachable NLRI Optional Non-Transitive

 

Python Tutorial: Python Network Programming – Build 7 Apps

ORIGIN ATTRIBUTE:
As the name suggests the ORIGIN attribute specifies the origin of the routing update. This is a Well-known Mandatory BGP Attribute and hence has to be recognized and sent to peers by all BGP implementations. The Origin attribute can contain one of these three values
1. IGP
2. EGP
3. Incomplete

If BGP has multiple routes then ORIGIN is one of the factor in determining the preferred route. IGP is the highest preferred ORIGIN value followed by EGP and Incomplete ORIGIN Attribute is the lowest preferred ORIGIN value of the three.

IGP: It means that the NLRI was learnt from an internal routing protocol of the originating AS.
EGP: This ORIGIN code specifies that the NLRI was learnt from EGP.
Incomplete: Usually misunderstood, this value means that the NLRI was learnt from some other means, it does not mean that the route is faulty, it only specifies that the information to determine the ORIGIN is not complete. All redistributed routes into BGP have an Incomplete ORIGIN attribute, since the origin of these routes cannot be determined.

AS_PATH ATTRIBUTE:

AS_Path describes the inter-AS path taken to reach a destination. It gives a list of AS Numbers traversed when reaching to a destination. Every BGP speaker when advertising a route to a peer will include its own AS number in the NLRI. The subsequent BGP speakers who advertise this route will add their own AS number to the AS_Path, the subsequent AS numbers get prepended to the list. The end result is the AS_Path attribute is able to describe all the autonomous systems it has traversed, beginning with the most recent AS and ending with the originating AS.

AS_Path is a well-known attribute, so if a BGP speaker advertises the route to a destination then it has to include its AS number in the advertisement if its originating the NLRI or if its advertising a received NLRI to other peers then it has to prepend its AS number to the existing list of autonomous systems in the AS_path attribute.

For an example below:

Lets assume AS-100 is advertising 1.1.1.0/22 to AS-200 Since AS-100 is originating the NLRI the advertisement will be [ 1.1.1.0/22 100]
AS-200 will receive this NLRI and advertise it to its peers AS-300 and AS-400, the NLRI  advertisement will look like  [ 1.1.1.0/22 200,100] – specifying that to reach the network 1.1.1.0/22 you have a path where you can to traverse AS-200 then AS-100.

The subsequent autonomous systems AS-300, AS-400 and others do the same. In the end AS-600 receives two routes to reach the network 1.1.1.0/22. To reach any host in network 1.1.1.0/22 it can either reach through AS-500 or from AS-400, since BGP is a path vector protocol by default AS-600 will choose the path from AS-400 since its shorter (less number of Autonomous Systems to traverse). Also note by default EBGP will not load balance across the two paths and will select only one best path, but it can be configured to load balance.

Also, BGP Speaker will add its AS number to the AS_Path only when an Update message is being sent to the neighbor which means only when BGP is advertising the route to the peer it will prepend its AS number to the AS_Path attribute.

AS_Path Prepend to Prefer one route over another:

In BGP the outgoing route advertisements directly influence the incoming traffic. In the example lets assume the link between AS-200 and AS-400 is a T1 and AS-200 does not want to prefer this route. Since the outgoing advertisements directly influence the incoming traffic in BGP, and AS-200 wants to prefer AS-300 assuming this is a high speed Gig link, AS-200 will prepend its AS number is the advertisements to AS-400 so that it makes it less preferable, the new BGP path ratio is reflected in the example diagram . AS-600 will now prefer the path from AS-500 and will follow the path 500-300-200-100 to reach 1.1.1.0/22 since this one becomes the shorter path.

AS_Path prepending is one of the way to influence how the BGP advertisements and the incoming traffic is handled.

AS_Path Attribute also makes sure that there is no routing loop, if an NLRI advertisement is received from a BGP peer and the receiving AS sees its own AS number in the AS_Path list of the destination route which is received, then the receiving BGP speaker knows that there is a loop and will not accept the advertisement.

AS_Path can be shown by issuing the command “sh ip bgp” on a cisco router.

NEXT_HOP ATTRIBUTE:

NEXT_HOP Attribute specifies the next hop IP address to reach the destination advertised in the NLRI.  NEXT_HOP is a well-known mandatory attribute and it has some set of rules to be followed for different BGP scenarios.

  1. If the BGP Peers are in different Autonomous Systems then the NEXT_HOP IP address that will be sent in the update message will be the IP address of the advertising router.
  2. If the BGP peers are in the same AS (IBGP Peers), and the destination network being advertised in the update message is also in the same AS, then the NEXT_HOP IP address that will be sent in the update message will be the IP address of the advertising router.
  3. If the BGP peers are in the same AS (IBGP Peers), and the destination network being advertised in the update message is in an external AS, then the NEXT_HOP IP address that will be sent in the update message will be the IP address of the external peer router which sent the advertisement to this AS.

Below are some examples for each of these scenarios.

NEXT_HOP BGP UPDATE Between Different Autonomous Systems:

In this example, the EBGP update is pretty straight forward. As the rule states If the BGP Peers are in different Autonomous Systems then the NEXT_HOP IP address that will be sent in the update message will be the IP address of the advertising router.

NEXT_HOP will always be advertised by the router which is sending an update to the BGP peer on how to reach a particular network.

The router in AS-200 sends in its update that network 2.2.2.0/24 is reachable via its IP address of 192.168.100.2

The router in AS-100 when needs to reach the network 2.2.2.0/24, it will always use the next hop ip address of 192.168.100.2 which is advertised by the router in AS-100 as a NEXT_HOP Attribute to reach this network.

Since NEXT_HOP is a well-known Mandatory Attribute, the router in AS-100 will have to accept and honor this value.

In this scenario where there are two routers in different AS and have formed the EBGP relationship, the NEXT_HOP attribute is pretty simple and straight forward.

The command “show ip bgp neighbor 192.168.100.1 advertised-routes” when executed on the router in AS-200 will show the network prefix it is advertising and the NEXT_HOP it is advertising. Both these values will be network: 2.2.2.0/24 and the NEXT_HOP as 192.168.100.2

NEXT_HOP BGP UPDATE Within Peers in Same Autonomous System:

NEXT_HOP address for the BGP peers in the same Autonomous Systems  is the address of the advertising router which in this case is RTR-A. Both RTR-A and RTR-C are IBGP Peers, When RTR-A sends an update message indicating the reachabilty information for network 10.10.10.0/24, it puts its own IP address in the NEXT_HOP. For RTR-C to reach the network 10.10.10.0/24, it will have the NEXT_HOP IP address of RTR-A and not RTR-B to which it is directly connected.

Also, this applies to the routers on the same shared IP segment, the NEXT_HOP will always be the IP address of the advertising router.

NEXT_HOP BGP UPDATE For Different AS:

In this scenario, the router is AS-100 is advertising the network 172.16.30.0/24 and specifies the next hop ip address of its own as 172.16.10.1, the router in AS-200 receives this update and has the next hop to reach this network as the IP address of the router which advertised the network which is the router in AS-100.

Within AS-200 now RTR-A advertises this network to its IBGP peers and advertises the NEXT_HOP as the IP address of the router in AS-100.

RTR-C which is the IBGP peer of RTR-A, now knows to reach the network 172.16.30.0/24 it has to use the next hop ip address of 172.16.10.1 (which is the ip address on router in AS-100).

This could cause an issue because RTR-C does not know how to reach the address 172.16.10.1 and the packets for the destination in 172.16.20.0/24 are dropped.  The route 172.16.30.0/24 is installed in BGP table but it is not installed in the IGP as the next hop IP address specified is not reachable and is considered as an invalid address. This issue can be resolved in one of the three ways.
1. Use static routes to link external addresses to internal routers, not a very feasible solution to use.
2. Run IGP is passive mode on the external interfaces.
3. BGP implementation gives a more practical solution called as “Next_Hop_Self” this when configured on the local RTR-A it will cause RTR-A to set its own IP address in the NEXT_HOP attribute.  The internal peers RTR-B and RTR-C will now have a NEXT_HOP IP address of 192.168.10.1 to reach the network 172.16.30.0/24 in AS-100. Since the internal routers already have the RTR-A’s address in IGP they know how to reach the external network through RTR-A.

 

Local Preference (LOCAL_PREF):

LOCAL_PREF is only used in updates sent to the IBGP Peers. This is a well-known discretionary attribute and as the name suggests it is used locally within an AS to update the internal BGP peers. It is not passed on to the BGP peers in other autonomous systems.

LOCAL_PREF specifies the BGP Speaker’s degree of preference for an advertised route.
The higher the value of Local Preference attribute the more preferred the route is.
Remember: For Local Preference : Higher Value = More Preference

Note that the Local Preference will only affect the traffic leaving the AS.

For an example on how LOCAL_PREF influences BGP routing, take a look at the diagram below.

In this example, the customer is peering with two ISPs to get the internet routing table, assuming that the connection to ISP-1 is a Gig connection and the connection to ISP-2 is only a T1, the customer wants to use ISP-1 and keep ISP-2 as a backup in case the link to ISP-1 fails.

From the diagram, RTR-A is connected to ISP-1 and it advertises the routes received from ISP-1 with a local preference of 200 to other internal BGP peers.

RTR-B is connected to ISP-2 and is advertising the routes received from ISP-2 with a local preference value of 100 (which is the default value of LOCAL_PREF).

Assuming that both the ISPs are advertising the same destination routes then RTR-C, the internal BGP Peer receives the routes from both RTR-A and RTR-B and will select RTR-A because the LOCAL_PREF value is higher on the routes advertised by RTR-A.

Also note that RTR-B will also prefer the routes advertised by ISP-1 connected to RTR-A. that is all internal routers within the customer AS in the diagram will now prefer Routes received from ISP-1.

LOCAL_PREF affects the traffic leaving the AS, the traffic leaving the Customer-AS in this example will prefer the routes from ISP1 to reach the destination networks. If there are any destination routes that ISP2 is advertising which are not being advertised on ISP1 for some reason, then traffic destined for those routes which are missing in ISP1’s advertisements will leave from RTR-B to ISP2 in order to reach those destinations network prefixes.

ATOMIC_AGGREGATE and AGGREGATOR:

ATOMIC_AGGREGATOR path attribute does  route aggregation on the routes that are non identical but point to the same destination. In effect if summarizes the routes when advertising them to the BGP peer.

When a router receives routes for the same destination, it makes the best path decision by selecting the more specific path. When aggregation is performed the BGP Speaker starts advertising the less specific routes to its peers but the path detail information is lost in this process. Anytime a BGP speaker does this aggregation by summarizing more specific routes into a less specific route it has to inform its down stream BGP peers that aggregation has been done, this is done by attaching the ATOMIC_AGGREGATE attribute to the update message.

When the downstream BGP speakers receive the route with ATOMIC_AGGREGATE attribute set, then they cannot advertise the more specific routes for this aggregated route, and they will have to keep the ATOMIC_AGGREGATE attribute attached when advertising this route to their BGP peers.

In some instances not all routes in a  network can be aggregated, and in others  all of them can be aggregated but still there might be an need to advertise both aggregate-address and the more-specific routes. In both the cases the router can advertise both the more specific routes as well as the aggregate address. Aggregation is done by the command “aggregate-address <network-prefix> <mask> and individual network statements” if the same command is used with the keyword “summary-only” then only the aggregate address is advertised and not the more-specific prefixes.

ATOMIC_AGGREGATE is a well-known discretionary attribute and informs its down stream routers that a loss of path information has occurred.

AGGREGATOR:

when the ATOMIC_AGGREGATE attribute is set, the BGP speaker has an option of attaching the AGGREGATOR attribute. AGGREGATOR i optional transitive attribute and gives information on where the aggregation was performed by including the AS number and the IP address of the router that originated the aggregate route. Cisco uses the Router ID as the the address of AGGREGATOR.

AS_SET:

When aggregation is done on the BGP route, the AS_Path information is lost. One of the purposes why AS_Path is used is to avoid any loops, and if the BGP speaker does not see its own AS number in the AS_Path, it will accept the route and can create a potential loop in the routing.

AS_SET is used to avoid this, AS_SET gives an unordered list of AS numbers when aggregation is done.

When a BGP speaker does aggregation for an NLRI leant from other autonomous systems, it can include all the AS numbers in the AS_Path as AS_SET,  including AS_SET will still give a list of AS numbers, though unordered it will still let the BGP speaker know if its own AS number was there somewhere in the path and it can reject the NLRI if its own AS number was seen for this NLRI advertisement.

MULTI_EXIT_DISC ATTRIBUTE: (MED)

MED is an optional non-transitive attribute and it is used to influence how the incoming traffic comes into an AS.

MED allows the AS  to inform its immediate neighbor AS of its preferred entry points. MED is also called as metric and the lowest value of MED is the most preferred one.
Note that MED Is not passed beyond the receiving AS. It is only used to influence traffic between two directly connected autonomous systems. Also MEDS are never compared when the routes to the same destination are received from two or more different AS. MED only applies to the routes advertised by a single AS.

In this example, AS-100 advertises the route from two different entry points with the MED value of 50 0n one router and a value of 100 on another. The Preferred entry point will be the router which is advertising the routes with the MED value of 50, since this is the lower value. Also notice that AS-200 will not advertise the AS-100 MED values to AS-300 in its outgoing route advertisements, since MED is an optional non-transitive attribute.

Also in this example the MED attribute will only take affect if AS-200’s BGP implementation recognizes the MED attribute, or else setting these MED attribute values on the routes for a preferred entry point into AS will not have any affect.

Note: By default MED values are not compared for routes to the same destination received from tw0 or more different autonomous systems. There is however a way for enabling this by using the command “bgp-always-comapre-med”. when this command is used, MED values on the received routes for same destination from different autonomous systems are compared. If this command is configured then it needs to be configured on every BGP router in the AS.

COMMUNITY ATTRIBUTE:

COMMUNITY attribute allows to share a common policy across multiple BGP peers who can be identified to be in a same group.

This is an optional transitive attribute so it needs to be passed on to other BGP peers. This attribute simplifies the policy enforcement by grouping a set of BGP peers with common properties to share a common set of policy.

An AS can set a COMMUNITY attribute for some of its BGP peer routes, and set the LOCAL_PREF and MED attributes based on the COMMUNITY rather than setting these values individually for each of these Peers. This helps in simplifying the process of policy enforcement.

Community attribute is always represented in Hex Format and is a set of 4 Octets.
As per RFC 1997 the first 2 octets are AS-number and the last two octets are an administratively defined identifier , resulting in the format of  AA:NN
The default Cisco format is the reverse of this as NN:AA, but this can be changed by the command “ip bgp-community new-format”

Community values in these ranges are reserved
0 – 65535 [Hex: 0x00000000-0x0000FFFF] and
4294901760 – 4294967295 [Hex: 0xFFFF0000-0xFFFFFFFF]
some of the well-known communities fall into these reserved ranges, as below.

  1. INTERNET:The internet community is the default community, it has no value. All routes by default to belong to this community and all of the routes in this category are advertised freely.
  2. NO_EXPORT:Routes received carrying this value cannot be advertised to EBGP Peers.  That is these routes must not be advertised outside the AS. The value is  0xFFFFFF01. If there is a confederation defined and this value is received then the routes cannot be advertised outside the confederation.
  3. NO_ADVERTISE:Routes received carrying this value cannot be advertised at all, that is they cannot be advertised to IBGP or EBGP peers. The value is 0xFFFFFF02.
  4. LOCAL_AS:Routes received carrying this value cannot be advertised to EBGP peers and peers in other AS within a confederation. The value is 0xFFFFFF03. As per RFC 1997 this attribute is called as NO_EXPORT_SUBCONFD.

Apart from these well-known community attributes, private community attributes can also be defined for certain uses, but these private community attributes will only be significant to the AS that has defined it in context to its BGP peers.

A route can carry more than one community attribute, and the BGP peer that receives such a route with multiple community attributes  can act based on one, some or all of the community attributes. A router can also add or modify the community attributes before passing them to other BGP peers.

Administrative Weight: (Cisco Only Parameter)

This is a Cisco Specific attribute that is applied to a route within a router. it is not communicated to other routers. The value of admin weight ranges between 0 to 65.535 and the route with higher value is more preferred.
By default all routes leant from a BGP peer have a value of 0 and all routes generated by the local router have a value of 32,768.

In this example, the router RTR-C prefers route  1.1.1.0/24  from RTR-B in AS-200, because the admin weight assigned is higher on the route received from RTR-B. Administrative weight is the first parameter which Cisco routers use for deciding the best BGP route when multiple routes to the same destination are available.

Source: http://netcerts.net/bgp-path-attributes-and-the-decision-process/

Advertisements

dB vs. dBm


Decibel (dB) and dB relative to a milliwatt (dBm) represent two different but related concepts.

A dB is a shorthand way to express the ratio of two values. As a unit for the strength of a signal, dB expresses the ratio between two power levels. To be exact, dB = log (P1/P2).

Using the decibel allows us to contrast greatly differing power levels (a common predicament in radio link design) with a simple two- or three-digit number instead of a more burdensome nine- or 10-digit one.

For instance, instead of characterizing the difference in two power levels as 1,000,000,000 to 1, it’s much simpler to use the decibel representation as 10*log (1,000,000,000/1), or 90 dB. The same goes for very small numbers: The ratio of 0.000000001 to 1 can be characterized as -90 dB. This makes keeping track of signal levels much simpler.

The unit dBm denotes an absolute power level measured in decibels and referenced to 1 milliwatt (mW). To convert from absolute power “P” (in watts) to dBm, use the formula dBm = 10*log (P/1 mW). This equation looks almost the same as that for the dB. However, now the power level “P” has been referenced to 1 mW. It turns out that in the practical radio world, 1 mW is a convenient reference point from which to measure power.

Use dB when expressing the ratio between two power values. Use dBm when expressing an absolute value of power.

– See more at: https://www.isa.org/standards-publications/isa-publications/intech-magazine/2002/november/db-vs-dbm/#sthash.U0xobENS.dpuf

Source: https://www.isa.org/standards-publications/isa-publications/intech-magazine/2002/november/db-vs-dbm/

Free CCIE Voice Lectures from INE.COM


CCIE Voice – Deep Dive Module 1 ($99 Value)

1.0 – Introduction and Basic Theory

http://ieclass.internetworkexpert.com/p49924175/

1.1 – Net Infrastructure Hands-On: VLANs, NTP, DHCP

http://ieclass.internetworkexpert.com/p85573473/

1.2 – Net Infrastructure Hands-On: DHCP, TFTP

http://ieclass.internetworkexpert.com/p41558071/

1.3 – QoS Advanced Theory

http://ieclass.internetworkexpert.com/p44458827/

1.4 – QoS Advanced Theory cont’d

http://ieclass.internetworkexpert.com/p71682550/

1.5 – QoS LAN Hands-On

http://ieclass.internetworkexpert.com/p31037485/

CCIE Voice Specific Q&A Follow-Up Discussion

http://ieclass.internetworkexpert.com/p27856701/

Why you don’t want to lose a CCIE from your staff?


According to Cisco these are the answers:

  • The risk to operations is significant with the loss of a qualified IT expert. The remaining staff must compensate to avoid disruptions that impact customer satisfaction, reduce productivity or inflict economic loss.
  • Return on investment in an employee is disrupted with turnover. Employers invest in certified staff through training courses, books and technical materials, practice equipment, time off for study and exams, and the cost of the exam itself.
  • It takes time to achieve certification. The typical CCIE will spend at least 18 months completing the process and take the lab exam more than once before passing.
  • The benefits of Gold or Silver Channel Partner status are only available to companies who maintain the required number of certified staff.

CCIE Employer Information


Cisco introduced CCIE in 1993 to help individuals, companies, industries and countries succeed in the networked world, by distinguishing the top echelon of internetworking experts.

Today the CCIE program sets the standard for internetworking expertise and evolves with the industry. The CCIE program is committed to valid, fair and high quality exams.

What CCIE certification stands for:

  • CCIE identifies experts with the skills and experience to handle the most challenging assignments in their field. CCIE exams are constantly updated and revised to evolve with the industry, focusing on current technologies and real-world applications.
  • CCIE is recognized worldwide as the most respected high-level certification in the industry (see Awards & Recognitions). The program continually updates and revises its testing tools and methodologies to ensure unparalleled program quality, relevance and value.
  • CCIE is an objective way to compare individuals, or job candidates, with different experience and backgrounds.
  • Preferred status is given to Cisco partners who employ CCIEs (find out more at Cisco Channel Programs).

Why you should hire a CCIE:

  • Maintenance of your network is fundamental to protect assets and to ensure seamless operations. The environment is growing more complex with operations conducted over VPNs, wireless, remote access and the Internet. You need proven experts to choose, implement and maintain the solutions required.
  • Having certified staff can increase the confidence of your customers, investors and business partners, and thereby boost your organization’s credibility, reputation and value.
  • Certified CCIEs are a highly-select group. Less than 3% of all Cisco certified individuals make it to the CCIE level, a tiny fraction of IT professionals worldwide.
  • Passing the exams is not easy. Earning your CCIE requires passing a lab exam in a time pressured environment. Hands-on experience is the only way to prepare for the lab.
  • CCIEs have invested a lot to expand their knowledge and further their careers. The average candidate spends thousands of their own dollars and at least 18 months pursuing certification. He or she will attempt the lab exam more than once before passing.
  • CCIEs are committed to maintaining their expert skills. Keeping their status active requires passing a recertification exam every two years.

Why you don’t want to lose a CCIE from your staff:

  • The risk to operations is significant with the loss of a qualified IT expert. The remaining staff must compensate to avoid disruptions that impact customer satisfaction, reduce productivity or inflict economic loss.
  • Return on investment in an employee is disrupted with turnover. Employers invest in certified staff through training courses, books and technical materials, practice equipment, time off for study and exams, and the cost of the exam itself.
  • It takes time to achieve certification. The typical CCIE will spend at least 18 months completing the process and take the lab exam more than once before passing.
  • The benefits of Gold or Silver Channel Partner status are only available to companies who maintain the required number of certified staff.

Source:  http://www.cisco.com/web/learning/le3/ccie/employers/index.html

CCIE4.0-IPv6 Multicast – Multicast Listener Discovery (MLD)


IPv6 multicast renames IGMP to the Multicast Listener Discovery Protocol (MLP). Version 1 of MLD is similar to IGMP Version 2, while Version 2 of MLD is similar to Version 3 IGMP. As such, MLD Version 2 Source Specific Multicast (SSM) for IPv6 environments.

Using MLD, hosts can indicate they want to receive multicast transmissions for select groups. Routers (queriers) can control the flow of multicast in the network through the use of MLD.

MLD uses the Internet Control Message Protocol (ICMP) to carry its messages. All such messages are link-local in scope, and they all have the router alert option set.

MLD uses three types of messages – Query, Report, and Done. The Done message is like the Leave message in IGMP version 2. It indicates a host no longer wants to receive the multicast transmission. This triggers a Query to check for any more receivers on the segment.

Configuration options for MLD will be very similar to configuration tasks we needed to master for IGMP. You can limit the number of receivers with the ipv6 mld limit command. If you want the interface to “permanently” subscribe, you can use the ipv6 mld join-group command. Also, like in IGMP, there are several timers you may manipulate for the protocol’s mechanics.

Configuring IPv6 multicast-routing with the global configuration command ipv6 multicast-routing, automatically configures Protocol Independent Multicast (PIM) an all active interfaces. This also includes the automatic configuration of MLD. Here are verifications:

R0#show ipv6 pim interface
Interface          PIM  Nbr   Hello  DR
 Count Intvl  Prior

Tunnel0            off  0     30     1     
 Address: FE80::C000:2FF:FE97:0
 DR     : not elected
VoIP-Null0         off  0     30     1     
 Address: ::
 DR     : not elected
FastEthernet0/0    on   0     30     1     
 Address: FE80::C000:2FF:FE97:0
 DR     : this system
FastEthernet0/1    off  0     30     1     
 Address: ::
 DR     : not elected

Notice the PIM is indeed enabled on the Fa0/0 we have configured in this scenario. Now for the verification of MLD:

R0#show ipv6 mld interface
Tunnel0 is up, line protocol is up
 Internet address is FE80::C000:2FF:FE97:0/10
 MLD is disabled on interface
VoIP-Null0 is up, line protocol is up
 Internet address is ::/0
 MLD is disabled on interface
FastEthernet0/0 is up, line protocol is up
 Internet address is FE80::C000:2FF:FE97:0/10
 MLD is enabled on interface
 Current MLD version is 2
 MLD query interval is 125 seconds
 MLD querier timeout is 255 seconds
 MLD max query response time is 10 seconds
 Last member query response interval is 1 seconds
 MLD activity: 5 joins, 0 leaves
 MLD querying router is FE80::C000:2FF:FE97:0 (this system)
FastEthernet0/1 is administratively down, line protocol is down
 Internet address is ::/0
 MLD is disabled on interface