MSDP


Multicast Source Discovery Protocol (MSDP) is used to interconnect multicast routing domains. It is typically run on the same router as the PIM sparse-mode rendezvous point (RP). Each MSDP router establishes adjacencies with internal and external MSDP peers similar to BGP. These peer routers inform each other about active sources within the domain. When they detect active sources, the routers can send PIM sparse-mode explicit join messages to the active source. The peer with the higher IP address passively listens to a well-known port number and waits for the side with the lower IP address to establish a TCP connection. When a PIM sparse-mode RP that is running MSDP becomes aware of a new local source, it sends source-active TLVs to its MSDP peers. When a source-active TLV is received, a check is done to make sure that this peer is toward the originating RP. If not, the source-active TLV is dropped. The MSDP peers that receive source-active TLVs can be constrained by BGP reachability information. If the AS path of the network layer reachability information (NLRI) contains the receiving peer's AS number prepended second to last, the sending peer is using the receiving peer as a next hop for this source. If the split-horizon information is not being received, the peer can be pruned from the source-active TLV distribution list. Table 9.11 lists the MSDP standards supported by the JUNOS software.

Table 9.11. MSDP Standards Supported by JUNOS Software
Standard Title
Internet draft draft-ietf-msdp-spec-13.txt Multicast Source Discovery Protocol (MSDP)
Internet draft draft-ietf-msdp-mib-06.txt Multicast Source Discovery Protocol MIB
Internet draft draft-ietf-mboned-anycast-rp-05.txt Anycast RP Mechanism using PIM and MSDP

MSDP Packets

MSDP messages are encoded in a type-length-value (TLV) format that contains the following fields:

  • TypeFormat of the value field

  • LengthLength of the complete TLV message

  • ValueActual information in the TLV message

When an RP in a PIM-SM domain first learns of a new sender, for example, by way of PIM register messages, it constructs a source-active message and sends it to its MSDP peers. Each MSDP peer forwards the message away from the RP address, thereby announcing the new sender to all its peers. In the MSDP TLV, the value field in the source-active message consists of the following fields:

  • Entry countNumber of peer entries in this TLV

  • RP addressAddress of the RP in the domain in which the source has become active

  • Sprefix lengthRoute prefix length associated with source address

  • Group address Group address to which the active source has sent data

  • Source addressIP address of the active source

Source-active request messages are used to request source-active state from an MSDP peer. If an RP in a domain receives a PIM join message for a group, it can send a source-active request message for the group to learn all its active source. In the MSDP TLV, the value field in the source-active request message consists of the group address field, which is the group address the MSDP peer is requesting.

Source-active response messages are sent in response to source-active request messages. They have the same format as the source-active message.

A keepalive message is sent to an MSDP peer if no MSDP messages have been sent to the peer within the specified keepalive period. These messages are necessary to keep the MSDP connection operation. Keepalive messages consist of only the type and length fields.

A notification message is sent when an MSDP peer detects an error condition. In the MSDP TLV, the value field consists of the following fields:

  • Open bitIndicates whether to close the MSDP connection

  • Error codeType of error notification

  • Error subcodeAdditional information about the error

  • DataThe error message or messages

Configuring MSDP

For MSDP to operate on an interface, configure it by including the following statements:

 [edit protocols ]  msdp {   disable;   export [  policy-names  ];   import [  policy-names  ];   local-address  address  ;   rib-group  group-name  ;   traceoptions {     file  name  <replace> <size  size  > <files  number  > <no-stamp>       <(world-readable  no-world-readable)>;     flag  flag  <  flag-modifier  > <disable>;   }   peer address {     disable;     export [  policy-names  ];     import [  policy-names  ];     local-address  address  ;     traceoptions {       file  name  <replace> <size  size  > <files  number  > <no-stamp>         <(world-readable  no-world-readable)>;       flag  flag  <  flag-modifier  > <disable>;     }   }   group  group-name  {     disable;     export [  policy-names  ];     import [  policy-names  ];     local-address  address  ;     mode <( mesh-group  standard )>;     traceoptions {       file  name  <replace> <size  size  > <files  number  > <no-stamp>         <(world-readable  no-world-readable)>;       flag  flag  <  flag-modifier  > <disable>;     }     peer  address  {       disable;       export [  policy-names  ];       import [  policy-names  ];       local-address  address  ;       traceoptions {         file  name  <replace> <size  size  > <files number > <no-stamp>           <(  world  -readable  no-world-readable)>;         flag flag <  flag-modifier  > <disable>;       }     }   } } 

Configuring MSDP Peers

An MSDP router must know which routers are its peers. You define the peer relationships explicitly by configuring the neighboring routers that are the MSDP peers of the local router. After peer relationships are established, the MSDP peers exchange messages to advertise active multicast sources. You must configure at least one peer for MSDP to function. To configure MSDP peers, include the peer statement:

 [edit msdp] or  [edit msdp group group-name] peer address {   export [ policy-names ];   import [ policy-names ];   local-address address;   traceoptions {     file name <replace> <size size> <files number > <no-stamp>       <(world-readable  no-world-readable)>;     flag flag <flag-modifier> <disable>;   } } 
Configuring MSDP Groups

An MSDP router must know which routers are its peers (neighbors). You define the peer relationships explicitly by configuring the neighboring routers that are the MSDP peers of the local router. After peer relationships are established, the MSDP peers exchange messages to advertise active multicast sources. You can arrange peers into different groups. Each group must contain at least one peer. Arranging peers into groups is useful if you want to block sources from some peers and accept them from others, or set tracing options on one group and not others. To configure MSDP groups, include one or more of the following statements:

 [edit protocols msdp ]  group group-name {   disable;   export [ policy-names ];   import [ policy-names ];   local-address address;   mode <( mesh-group  standard)>;   traceoptions {     file name <replace> <size size> <files number > <no-stamp>       <(world-readable  no-world-readable)>;     traceflag flag <flag-modifier> <disable>;   }   peer address; {     disable;     export [ policy-names ];     import [ policy-names ];     local-address address;     traceoptions {       file name <replace> <size size> <files number > <no-stamp>         <(world-readable  no-world-readable)>;       flag flag <flag-modifier> <disable>;   } } 
Configuring MSDP Mesh Groups

MSDP mesh groups are groups of peers configured in a full-mesh topology that limit the flooding of source-active messages to neighboring peers. Every mesh group member must have a peer connection with every other mesh group member. When a source-active message is received from a mesh group member, the source-active message is always accepted but is not flooded to other members of the same mesh group. However, the source-active message is flooded to nonmesh group peers or members of other mesh groups. By default, standard flooding rules apply if mesh-group is not specified. To configure an MSDP mesh group, define a peer group and set the mode to mesh-group :

 [edit protocols msdp]  group  group-name  {   mode  mesh-group;   local-address  address  ;   peer  address  ; } 

When configuring MSDP mesh groups, you must configure all members the same. If you do not configure a full mesh, excessive flooding of source-active messages can occur.

Figure 9.3 illustrates source-active message flooding between different mesh groups and peers within the same mesh group. Table 9.12 explains how flooding is handled by peers in this configuration.

Figure 9.3. Source-Active Message Flooding

graphics/09fig03.gif

Table 9.12. Source-Active Message Flooding Explanation
Source-Active Message Received from Source-Active Message Flooded to Source-Active Message not Flooded to
Peer 21 Peer 11, Peer 12, Peer 13, Peer 31, Peer 32 Peer 22
Peer 11 Peer 21, Peer 22, Peer 31, Peer 32 Peer 12, Peer 13
Peer 31 Peer 21, Peer 22, Peer 11, Peer 12, Peer 13, Peer 32  
Configuring MSDP Routing Policy

You can configure routing policy globally for all MSDP peers (at the [edit protocols msdp] hierarchy level), for all peers in a group (at the [edit protocols msdp group group-name ] level), or for an individual peer (at the [edit protocols msdp peer address ] or the [edit protocols msdp group group-name peer address ] level). If you configure routing policy at the group level, each individual peer in a group inherits the group's routing policy.

To apply policies to routes being imported into the routing table from MSDP, include the import statement, listing the names of one or more policy filters to be evaluated. If you specify more than one policy, they are evaluated in the order specified, from first to last, and the first matching policy is applied to the route. If no match is found, MSDP shares with the routing table only those routes that were learned from MSDP routers.

 import [  policy-names  ]; 

For more information about routing policy, see Chapter 8, "Routing Policy and Firewall Filters," on page 301.

To apply policies to routes being exported from the routing table into MSDP, include the export statement, listing the names of one or more policies to be evaluated. If you specify more than one policy, they are evaluated in the order specified, from first to last, and the first matching policy is applied to the route. If no match is found, the routing table exports into MSDP only the routes that it learned from MSDP and direct routes.

 export [  policy-names  ]; 
Configuring Multiple Rendezvous Points in a Domain

You can configure multiple rendezvous points (RPs) in a shared-tree PIM sparse-mode domain. You need to configure an MSDP local address to enable the RPs in the domain to maintain a consistent view of the active sources.

To configure a router to act as an RP in a domain with other RPs, do the following for each router in the domain that will act as an RP:

  • Create the router ID by configuring a unique IP address on the loopback interface and setting the preferred address flag.

  • Configure a nonunique unicast address on the loopback interface.

  • Use the nonunique unicast address to configure the PIM to be the local rendezvous point.

  • Configure MSDP with the unique address (router ID) as the local address of the peer.

Disabling MSDP

To disable MSDP on the router, include the disable statement:

 [edit msdp] or  [edit msdp group  group-name  ] disable; 
Tracing MSDP Protocol Traffic

To trace MSDP protocol traffic, specify MSDP-specific options by including the traceoptions statement:

 traceoptions {    file  name  <replace> <size  size  > <files  number  > <no-stamp>     <(world-readable  no-world-readable)>;   flag  flag  <  flag-modifier  > <disable>; } 

For more information about tracing and global tracing options, see the JUNOS technical documentation.

You can specify the following MSDP-specific options in the flag statement:

  • keepalive Keepalive messages

  • packets All MSDP packets

  • route MSDP changes to the routing table

  • sa Source-active packets

  • sa-request Source-active request packets

  • sa-response Source-active response packets



Juniper Networks Field Guide and Reference
Juniper Networks Field Guide and Reference
ISBN: 0321122445
EAN: 2147483647
Year: 2002
Pages: 185

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net