BGP AS ptah Attributes

 BGP

Attribute Categories

1. Well-Known, Mandatory
2. Well-Known, Discretionary
3. Optional, Transitive
4. Optional, Non-Transitive

Well-Known, Mandatory

Well-known, Mandatory attributes must appear in every UPDATE message. It must be supported by all BGP software implementations. If a well-known, mandatory attribute is missing from an UPDATE message, a NOTIFICATION message must be sent to the peer.
Examples:

• AS_path
• ORIGIN
• NEXT_HOP

Well-Known, Discretionary

Well-Known, Discretionary attributes may or may not appear in an UPDATE message, but it must be supported by any BGP software implementation.
Examples:

• LOCAL_PREF
• ATOMIC_AGGREGATE

Optional, Transitive

Optional, Transitive attributes may or may not be supported in all BGP implementations. If it is sent in an UPDATE message, but not recognized by the receiver, it should be passed on to the next AS.
Examples:

• The Aggregator of the Route ( AGGREGATOR)
• Community String (COMMUNITY)

Optional, Non-Transitive

Optional, Non-Transitive attributes may not be supported and will not be passed on if advertised.
May or may not be supported, but if received, it is not required that the router pass it on. It may safely and quietly ignore the optional attribute.
Examples:

• Multi-Exit Discriminator (MULTI_EXIT_DISC)
• Route Originator ID (ORIGINATOR_ID)
• Route Cluster List (Cluster List)

BGP AS-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.
as W explained before:
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

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.

 

IGMP timers

IGMP timers. First, as we know, multicast routers periodically query hosts on a segment. If there are two or more routers sharing the same segment, the one with the lowest IP address is the IGMP querier (per IGMPv2 election procedure – as you remember, IGMPv1 let the multicast routing protocol define the querier).

The periodic interval is defined using the command:
ip igmp query-interval [interval in secs]
The hosts on the segment are supposed to report their group membership in response to the queries. Note that IGMPv2 defines special report suppression procedure, which allows host to suppress its own report, if it saw some other host reporting the same group. The query-interval timer is also used to define the amount of time a router will store particular IGMP state if it does not hear any reports on the group. This interval is 3xquery-time and it was the only mechanism available in IGMPv1 to expire a non-needed group. By default the interval is 60 seconds.
From what we said above follows that hosts must respond to a query during some time-window interval. This time window is specified in IGMPv2 packets using special field that defines the maximum response time. You set the value of this field using the command:
ip igmp query-max-response-time [time-in-seconds]
When a host receives the query packet, it starts counting to a random value, less that the maximum response time. When this timer expires, host replies with a report, provided that no other host has responded yet. This accomplishes two purposes:
a) Allows controlling the amount of IGMP reports sent during a time window.
b) Engages the report suppression feature, which permits a host to suppress its own report and conserve bandwidth.
Naturally, the maximum response timer could not be less than the query-interval. Note that IGMPv1 does not support the maximum response time field in its packets, and this timer is fixed to 10 seconds with version 1.
The next important timer, pertaining to IGMPv2, is last member query interval. This interval is configured using the following command:
ip igmp last-member-query-interval [interval in ms]
IGMP uses this value when router hears IGMPv2 Leave report. This means that at least one host wants to leave the group. After router receives the Leave report, it checks that the interface is not configured for IGMP Immediate Leave (single-host on the segment) and if not, it sends out an out-of-sequence query. The maximum-response-time in this query is set to last-member-query-interval which is 1000ms by default. The router sends out maximum of
ip igmp last-member-query-count [number]
messages and if no one responds during this time, the router removes the IGMP state for the group. The whole procedure controls if there are any more members left on the interface. After the last query send router waits some additional time, approximately 0,5 second to finally remove the group. So by default, after a reception of the Leave message the router waits for 2x1000ms+0,5seconds before stopping the multicast traffic flow.
If the interface is configured for immediate leave for a specific group list using the command:
ip igmp immediate-leave group-list [list]
Then the router will treat these groups as having single host member. After the reception of a Leave message, the router immediately removes the multicast forwarding state.
The last interesting timer is
ip igmp query-timeout [timeout]
This timer is used by “silent” routers, i.e. the routers that lost the IGMP querier election process. If the inactive routers did not hear any query for the 2 * [timeout] interval, they start election process again.
And in the end, a quick command to learn all default IGMP timer values:

Rack21R5#show ip igmp interface fastEthernet 0/1
FastEthernet0/1 is up, line protocol is up
  Internet address is 129.21.59.5/24
  IGMP is enabled on interface
  Current IGMP host version is 2
  Current IGMP router version is 2
 IGMP query interval is 60 seconds
  IGMP querier timeout is 120 seconds
  IGMP max query response time is 10 seconds
  Last member query count is 2
  Last member query response interval is 1000 ms
  Inbound IGMP access group is not set

PIM query interval -30 sec 

+ 60 seconds: IGMPv2 query interval or IGMPv1 query interval or IGMPv3 query interval
+ 120 seconds: IGMPv2 querier timeout 

considerations in PIM

PIM

PIM Query-Interval Tuning

The 'ip pim query-interval' controls the interval that a PIM hello packet is transmitted out each pim enabled interface.

The PIM hello packets are used to discover PIM neighbors and to determine the Designated Router (DR) on each network segment. The default interval for the PIM hello packets to be sent is 30 seconds. A PIM neighbor is considered down after 3 consecutive missed messages. Therefore, it could take 90 seconds for the DR to failover. If you lower the query interval to 1 second, then the DR failover time is reduced to 3 seconds.

The goal is not to set the query-interval too low so that there is unnecessary flapping. Cisco generally recommends a 1 second query-interval, which would give you a 3 second failover at the receiver edge. Some customers may choose to use the sub-second option. Cisco does not recommend an interval less than 500 ms. Due to queue lengths and processing delays on the switch platforms, lower intervals have been known to cause problems.

Keep in mind that a router with 30 LAN segments and a query-interval of 1 will need to send out 30 PIM hellos every second. If you turn down the query-interval to 500 ms then there will be 60 messages per second.

In the core of the network there are typically point-to-point links and not any directly connected receivers. When a link goes down on a P2P link, it is a triggered event and the PIM neighbor is immediately removed. After unicast routing reconverges, PIM join messages will be sent on the alternative path for the active multicast streams. Therefore, there is no need to turn down the query-interval in the core and it is a waste of CPU cycles and bandwidth.

In summary:

• Turn down the pim query-interval on the receiver edge to reduce DR failover time

• This only needs to be done when there are redundant edge routers and receivers

• A general recommendation is a query interval of 1 second and no less than 500ms. This should be used with care as the number of interfaces increase.