Multicast Sparse Mode

  • RFC 4601
  • Uses ‘Pull’ model or explicit join.
  • Uses two tree types:
    • RPT – Shared tree
    • SPT – Shortest Path tree
    • NOTE
      • Dense mode uses only SPT
  • More scalable and usually better design choice then Dense mode.
    • Dense mode basically legacy.
  • Multicast tree determines how traffic is routed from sender to receiverS.
  • Source based tree
    • Uses shortest path from sender to receiver.
    • Dense mode or sparse mode
  • Shared trees
    • Uses shortest path from sender Rendezvous Point, then shortest path from RP to receiver.
    • Sparse mode only
    • Used for the following:
      • Eliminate flooding
      • Eliminate pruning
      • Making routing table more scalable.
  • Sparse Mode Operations:
    • Discover PIM neighbors and elect Designated Router.
    • Discover RP
    • Tell RP about sources.
    • Tell RP about receivers.
    • Build Shared Tree from Sender to Receivers through RP.
    • Join shortest path tree.
    • Leave shared tree.
    • Multicast Table Maintenance.
  • Rendezvous Point:
    • Used as reference point for root of shared tree.
    • Learns about sources from Unicast PIM Register messages.
      • Register message gives PIM an (S,G)
    • Learns about receivers through PIM Join messages.
      • Join message tells RP to add interface to OIL for (*,G)
    • Used to merge the two trees together.
    • Without RP, there will be zero registers and joins in PIM sparse mode.
    • As Root of all shared trees, RP must know all sources.
    • More operations:
      • When first hop router connected to sender hears traffic, a unicast Register is sent to RP.
        • Only DR sends register if multiple multicast routers available.
      • If RP accepts, it acknowledges with Register Stop and inserts (S,G) into Multicast table.
        • At this point only DR and RP know (S,G) mapping.
      • PIM Join
        • When last hop router receives IGMP Report, a PIM Join is generated up reverse path (tree) to RP.
        • All routers in reverse path install (*,G) and forward the Join hop-by-hop to the RP.
        • At this point all downstream routers toward receiver know (*,G).
      • Merging Trees
        • Once RP knows (S,G) from sender and (*,G) from receivers, RP sends PIM Join up reverse path to source.
        • All routers in between RP and source install (*,G) with outbound interface list pointing towards RP.
        • Once (S,G) begins, tree is built end to end through RP.
      • SPT
        • Shared tree is made of two Shortest Path Trees.
          • SPT from RP to sender
          • SPT from receiver to RP
          • SPT from receiver to sender (both combined) may not be same as shared tree.
            • result is shared tree not optimal.
            • Fix
              • Last hop router joins SPT to source with (S,G) Join.
              • Leaves RPT by sending (*,G) Prune to RP
            • Can be modified with ‘ip pim spt-threshold’.
  • Routing Table Maintenance:
    • PIM Dense and PIM Sparse use State Refresh to ensure feeds to not timeout.
      • (*,G) join sent to RP or up SPT to refresh the OIL.
    • Sparse Prune message can be used to speed up state information timeout if IGMP Leave is heard from end point.

Multicast General Info

How it works:

  • Source app sends UDP multicast traffic to group destination address.
  • Interested receivers join group address by signaling to routers on local area network.
  • Routers communicate to build loop free path (tree) from sender to receivers.
  • Portion of network without receivers will not receive that traffic for the group.
    • Saving resources – Advantage of multicast.

Use cases:

  • IPTV
  • Videoconferencing
  • VoIP On hold music.
  • Large scale data center replication.
  • Real time applications like stock tickers.

Group Addressing:
– Layer 3 and Layer 2 addressing

Control Plane:
– IGMP
– PIM
– MSDP
– MBGP

Data Plane
– Reverse Path Forwarding (RPF)
– Multicast Routing Table (MRIB/MFIB)

Multicast Group:

  • Address agreed upon by sender and receiver.
    • Source sends to destination address (group address)
    • Receivers are listening for traffic heading to that group.
  • Traffic always sent to a group, not group to sender.
  • Groups use layer 2 and layer 3 addressing.

IPv4 Addressing:

  • 224.0.0.0/4
  • Link Local
    • 224.0.0.0/24
  • Source Specific Multicast
    • 232.0.0.0/8
  • Administratively Scoped
    • 239.0.0.0/8

Layer 2 Addressing:

  • IPv4 address maps to MAC address which is forwarded for LAN.
  • Allows L2 switches forwarding in intelligent way.

Control Plane:

  • Who is sending traffic and to where?
  • Who is receiving traffic and for what groups?
  • How traffic should be forwarded
    • Tree
  • Built with combo of IGMP and PIM/MSDP

IGMP:

  • Used for host to signal to routers over L2/LAN.
    • Tells router that host is part of specific group.
  • Version 1
    • Message Type:
      • Host membership query
      • Host membership report
    • Report used to join group
    • Query used by router to see if members of the group still exist.
    • Replaced by version 2
  • Version 2
    • Adds
      • Querier election
        • If multiple routers on LAN segment that are running Multicast
      • Timers
        • Adds timers that speed up timeouts.
      • Group specific queries
        • Query sent to group address instead of all multicast hosts on segment.
      • Explicit Leave
        • Speeds up convergence when no hosts are part of group any longer.
    • Backwards compatible.
  • Version 3
    • Supports Source Specific Multicast
      • v1 and v2
        • (*,G)
      • v3
        • (S,G)
      • Receiver already knows the source sending multicast traffic.

Multicast Routing:

  • PIM
    • Router to router communication.
    • Builds loop free tree.
    • Versions 1 and 2
    • Sparse mode and Dense mode
  • Dense Mode
    • Implicit join
    • All traffic unless you say you don’t want it.
    • Uses Flood and Prune behavior.
  • Sparse Mode
    • Considered explicit join.
    • No traffic unless ask for it.
    • Uses Rendezvous Point to process join requests.

Multicast Data Plane:

  • Traffic begins to flow once tree is built.
  • Data Plane check prior to traffic flow
    • Reverse Path Forwarding (RPF)
      • Was traffic received on correct interface?
    • Multicast Routing Table (MRIB/MFIB)
      • What interface shuld I forward the packets out?

RPF Check:

  • PIM does not exchange topology info with routers.
    • Multicast traffic comes in, router looks at source IP address and incoming interface.
    • Normal Unicast CEF is checked for reverse path back to source.
    • Logic:
      • If incoming multicast interface == outgoing unicast interface, check has passed.
      • If incoming multicast interface DOES NOT == outgoing unicast interface, then packet is dropped because RPF failed.
    • Basically PIM uses the normal unicast topology/FIB/routing information to figure out there’s a loop free path/multicast tree.
      • Opposite of each other.

BGP Filtering Methods

  • Update filtering works on peer basis.
    • ‘neighbor <address> distribute-list [standard/extended acl]
    • ‘neighbor <address> filter-list [as-path-acl]
    • ‘neighbor <address> prefix-list [prefix-list name]
    • ‘neighbor <address> route-map
      • Using route maps avoids order of operations issues.
  • Regular Expressions
    • Used for the following:
      • Show command outputs
      • TCL/EEM scripting
      • BGP AS-Path access-lists
      • BGP Expanded Community lists
    • Info can be found in
      • IOS Terminal Services Configuration Guide
        • Appendixes
          • Regular expressions

Regex AS-Path access-list example

In the image below R1 and R4 are in ASN 200, R3 and R2 in ASN 100.

R4 and R1 have two originating routes being advertised into BGP, 4.4.4.0/24 and 1.1.1.0/24. The regular expression ‘^$’ can be used with BGP to show only routes that are originating from the local ASN. This can be used with an access-list/filter list with BGP to only advertise into BGP the locally originated, instead of passing on routes from external ASNs onto additional ASNs.

In IOS the command ‘show ip bgp regex ^$’ can be used to show only the locally originated routes being advertised.

To create an ACL to filter down in BGP, the following can be completed.

The use of ‘filter-list’ on the neighbor statement then will only advertise out locally originated prefixes through the Regex ‘^$’.

BGP Max Prefix

  • BGP defaults to full view from all peers
  • Generally all prefixes should not get pushed upstream.
  • Can filter on number of prefixes
    • ‘neighbor maximum-prefix’
    • Result can be log or shutdown peer.

BGP Outbound Route Filtering

  • Traditionally what providers will advertise out.
    • Full Table
    • Default Only
    • Default plus local (partial)
  • Outbound Route Filtering
    • Customer signals upstream what type of routes they want.
    • Results in control in customers hands vs. providers.
    • ‘neighbor ip-address capability orf prefix-list [send, receive, both]’

The ORF process can be configured with a prefix-list and then adding capability and prefix-list to a BGP neighbor statement. On R8 below we’re receiving all BGP routes from ASN 200 and 100 from R5. If we wanted to filter down to receiving one subnet from R5, 1.1.1.0/24, we specify that in the prefix list.

Now on R8’s BGP table, the local ASN prefixes and 1.1.1.0/24 are the only subnets available.

Soft Reconfiguration Inbound:

  • Saves unfiltered BGP routes received from peer in Adj-RIBs-In.
    • Adj-RIBs-In–>Loc-RIB–>Adj-RIBs-Out
    • Allows router to run ‘show ip bgp neighbor <neighor> received-routes
  • Takes up more memory because it’s saving another copy of inbound routes.
  • ‘neighbor <address> soft-reconfiguration inbound’
  • Makes troubleshooting easier.

Before:

Route Refresh Capability:

  • Negotiated capability with OPEN message
  • Can ask peer to send an update without having to hard clear session.
    • ‘clear bgp ipv4 unicast <neighbor> soft in’
    • ‘clear bgp ipv4 unicast <neighbor> in’
    • ‘clear bgp ipv4 unicast * in’
  • Does not consume memory like Soft Reconfiguration Inbound

Communities-2

Communities:

  • BGP’s way of using route tags.
  • Used to group prefixes together.
    • Advertisement Policy
    • Filtering policy
    • Best Path Selection policy
  • Optional Transitive
    • Not exchanged by default.
    • Needs the additional neighbor command ‘send-community’
  • Standard
    • 4 byte value.
    • Can be decimal or AA:NN
      • AA:NN is enabled with:
        • ‘ip bgp new-format’
        • ‘ip bgp-community new-format

Well-Known:

  • No-Export
    • Does not advertise to EBGP peers.
  • No-Advertise
    • Does not advertise to ANY peer.
  • Local-AS
    • Does not advertise to Confederation EBGP Peers
      • Sub domains.

Configuration:

  • Setup in route-maps.
  • ‘set community {community-number [additive] [well-known-community] | none’
    • Not additive, needs additive keyword.
  • Can delete community by setting as ‘none’
  • Matching communities
    • List Creation
      • Standard list matches community name or number.
        • ‘ip community-list 1 standard permit no-export’
      • Expanded matches regular expression
        • ‘ip community-list expanded AS100 permit 100:[0-9]+
      • Reference from route-map
        • ‘match community AS100’

Extended Communities:

  • Used for specific applications like MPLS L3/L2VPN, EIGRP Cost.

BGP Cost Community:

  • Custom decision process.
  • Only advertised within AS or confederations.
  • Influences BGP path selection
    • Compares before even Weight.
  • EIGRP PE/CE
    • Uses pre-bestpath cost community to encode composite metric into BGP.
  • GSHUT Community
    • Used in conjunction with Graceful Restart
    • Takes restarting peer out of data-path by modifying local preference.
      • Similar to OSPF Max Metric LSA.

BGP Auto Summary

  • Auto summarizes prefixes.
    • Requires subnet of network to be present.
    • No mask required on network/igp statement
    • Classful
  • Disabled by Default.
  • Summarization can occur anywhere, unlike OSPF and IS-IS (link state)
  • Config
    • Under router bgp ASN process, ‘aggregate-address <network><mask>’
  • config arguments
    • summary-only
      • suppress more specific routes
    • suppress-map
      • suppress subset of more specific routes
    • as-set
      • list of AS numbers and communities associated with the aggregate; inherited from more specific routes.
    • advertise-map
      • attributes of prefixes matched with advertised map are inherited in aggregate address
      • Used in conjunction with as-set
        • Prevents a specific AS from being included in AS_SET of the new aggregate.
        • Circumvents loop prevention
    • attribute-map | route-map
      • Used to modify attributes with aggregate address.
      • Used with as-set
        • Can set or remote attributes
        • E.g. remove “no-export” community, add MED.

Topology:

R8, R10 = ASN 810.1
R5, R2 and R3 = ASN 100
R1 and R4 = ASN 200

R10 is advertising subnets 172.16.10.0/24, 172.16.20.0/24, and 172.16.30.0/24 into BGP, which is seen in the route table of both ASN 200 routers.

summary-only config:
To summarize the subnets from R10 into ASN 200, we’ll have to add two commands to R2 and R3, which are the routers providing paths to ASN 200 for these IP ranges.

Now in the routing table on R1, we will only see the summary, and nothing else.

BGP Engineering – Communities

  • RFC 1998
  • Pre-stages inbound policy to
    • match on communities
    • set local pref
    • set other attributes
  • Results in outbound path selection.

The below routers are running in the following ASNs:

R1, R4 = ASN 200
R3, R2 = ASN 100

R4 is advertising its Loopback subnet of 4.4.4.0/24 into BGP. We’re going to change the Local Pref of the route 4.4.4.0 on R2 by using a community.

Configuration:

On R2 the configuration needs to first have communities setup:

These communities then need to be referenced in a Route Map, this one called ‘BGP_IN’.

This then needs to be applied to a neighbor statement. In this case with R1.

Next, we’ll add a prefix-list for R4’s loopback subnet.

Then a route-map called ‘BGP_OUT’.

This route-map will reference the Loopback subnet on R4 and set the community string to 100:110, which makes sense to R2.

Then the route-map will get applied to the neighbor statement towards R2.

Now on R2 we’re seeing that the local preference has changed in accordance with the route-map that sets values on communities.

BGP Path Selection/Engineering Cont. 2

Continuing work on below image:

Autonomous Systems:
R1, R4 – ASN 200
R3, R2, R5 – ASN 100
R8, R10 – ASN 810.1

The next traffic engineering methods used will be MED and AS-Path. These are both methods to influence traffic coming inbound towards the Autonomous System. In the example below, R4 reaching R5 will have two paths via R2 and R3. The two paths can be seen to R5’s loopback with a ‘show ip bgp 5.5.5.5’. They’re both valid routes with equal attributes, but R2 is preferred probably because of a tie breaker that the neighbor has been there longest.

Currently both paths have the same AS length to reach R5, but to modify and prefer traffic to R5 through R3, we can set AS Prepend on R2.

Configuration:

On R2 a prefix list, route-map and set to out will need to be applied. The prefix-list will match the loopback subnet of 5.5.5.0/24

The Route-map will match ip address to this prefix list.

And the route-map will then be applied outbound towards the neighbor we want to have a longer AS Path, router R1.

So again, R1 has two paths to subnet 5.5.5.0/24, one through R2 and one through R3. Adding AS-Prepend to the neighbor statement, we’re essentially saying the AS Path is now 4 Autonomous systems away instead of 1. This can be seen within a ‘show ip bgp’.

If we remove the AS-Prepend route-map we’ll see things go back to normal. The BGP table for R1 will have two even attributable routes to 2.2.2.2, but will only prefer one.

To modify inbound traffic with MED, we’ll need to go through a similar process. We’ll create a prefix list, route-map and assign to neighbor statements on both R2 and R3 toward R1. On R2 we’ll set the MED (metric) to 100, and R3 will be set to 150. Configs below, R2:

Config below, on R3:

After this config is applied and the BGP clear ‘out’ has occurred, the route metrics will show differently in R1.

The route going through the next hop 10.40.1.1 is now the most preferred because Metric now shows 100, while 10.20.1.1 shows Metric of 150.

Note:

  • Both sides advertising a MED value should have something set. By default BGP without any value will be best.
    • bgp bestpath med missing-as-worst can override the default behavior.

BGP Path Selection/Engineering Cont

In the image below there are 7 routers all running BGP.

The routers are running the following ASNs:

  • R1 and R4 – ASN 200
  • R2, R3, R5 – ASN 100
  • R8 and R10 – ASN 810.1.

R10 is advertising three Loopback networks into BGP and we’re seeing how BGP will by default choose R1’s path to R10. On R1 there are two different paths to R10s loopback IP 172.16.10.0/24.

In the bottom right the router shows the path through R2 (2.2.2.2) is the ‘best’ – ie. best path. This can be seen in the routing table:

Going down the list for path selection, the weight is set to 0 on both and the local preference are both default 100.

AS Path length and origin can be seen in the image above as well – 100, 810.1, both the same.

The routes are so evenly matched that BGP will go down to the tie breakers, ie.

  • EBGP over iBGP
  • IGP Metric to Next Hop
  • Oldest
  • Lowest RID
  • Shortest cluster list
  • Lowest Neighbor address

In this case BGP is selecting the neighbor going through R2 because it’s been exchanging routes for longer than R3.

To influence traffic outbound in BGP, we’ll need to send an advertisement inbound to R1. This will be accomplished typically with weight or local pref.

Configuration:

To modify by weight (Cisco proprietary) the first part of configuration will be a prefix-list and route map that can be applied inbound.

Next, the route-map needs to get applied inbound associated with the neighbor we want as more preferred – ie. R3 at 10.20.1.1.

The ‘clear ip bgp *’ refreshes inbound advertisements to the router. After the refresh, now we can see the route preference has changed to R3.

Weight can be seen as 12345.

Next is a Local Preference example. In the image below we have the same ASN list, but now we’re looking at R4 and R2. R4 is advertising it’s loopback subnet 4.4.4.0/24 over into ASN 100, and we want to change how traffic from R2 chooses it’s path to R4.

R2 currently has two routes to reach 4.4.4.4/24, one through it’s iBGP neighbor at R3, and one through R1 via EBGP.

R2 will install this route into it’s routing table via its eBGP neighbor because the administrative distance is shorter and EBGP will be preferred over iBGP. To modify the local preference inbound to prefer R3, we’ll need to create a prefix list, then route-map, saying change the local preference via R3. Local preference is AS specific/spread, not just locally significant.

Prefix-List:

Route-Map:

R3 is receiving this route from R1, so the route-map needs to be applied under that neighbor inbound via router bgp <asn>. R3 and R1 are connected over the transit 10.20.1.0/30.

Now in R2 we can see that the best path is through R3 because the local pref is higher. This same local pref can be seen within the Autonomous System.

Once the advertisement leaves the local AS, Local pref is set back to the default 100.

BGP Path Selection

  • Best Path Selection:
    • Default chooses single best path.
    • Best path installed in RIB/FIB
    • Advertised to other BGP peers.
    • Decision process
      • RFC 4271
  • Prerequisites:
    • Next hop must be in routing table
      • prevents route recursion failure.
    • Synchronization rule must be met or disabled.
    • AS-Path must not contain local-AS
      • Standard EBGP Loop prevention
      • Can be disabled with ‘allow-as in’
    • First ASN in path must be neighbor’s ASN
      • bgp enforce-first-as’ command.
  • Path Selection Order
    • Weight
      • Cisco proprietary
      • Locally significant
      • Higher value is preferred
    • Local Preference
      • Higher value is preferred
      • Not advertised to EBGP peers.
      • Carried through confederation EBGP.
    • Locally Originated
      • Locally originated gets weight of 32768
    • AS-Path
      • Smaller length is preferred
    • Origin
      • IGP over EBGP over Incomplete
        • IGP origination is from network statement.
        • Incomplete is from redistribution.
          • Network statement preferred over redistribution.
    • MED
      • Smaller value preferred.
      • Only compared for peerings to same provider by default.
        • Typically only used for comparing the same route from the same provider over multiple links.

Tie Breakers:

  • EBGP over iBGP
    • If learned from EBGP, it’s not your prefix.
    • EBGP always preferred.
  • IGP Metric to Next-Hop
    • Can use multi-path if all equal after this step.
    • Hidden command to allow multipath if AS_Path is not the same (has to be same length)
      • ‘bgp bestpath as-path multipath-relax’
  • Additional Tie Breakers:
    • Oldest
    • Lowest RID
    • Shortest cluster list
    • Lowest Neighbor Address
  • Exceptions:
    • ‘bgp bestpath as-path ignore’
    • ‘bgp always-compare-med’
      • Compares MED for routes locally originated in Confederation.
    • ‘bgp bestpath med missing-as-worst’
      • Assign 4,294,967,294 to NULL MED
    • ‘bgp deterministic med’
      • Compare MED against all possible paths.
    • IGP Metric
      • ‘bgp bestpath igp-metric ignore’
        • IOS-XE 3.4S
    • Router-ID
      • ‘no bgp bestpath compare-router-id’

Manipulating Best Path Selection

  • Outbound routing policy affects inbound traffic
  • Inbound routing policy affects outbound traffic
  • Longest match routing is above all
    • Affects both directions.
  • Attributes for influencing outbound path selection:
    • Weight and Local Pref
      • Set inbound
      • Affects outbound traffic
  • Attributes for influencing inbound path selection:
    • AS-Path and MED
      • Set outbound
      • Affects inbound traffic
  • Multipath Load Balancing
    • MP load balancing for external links with unequal bandwidth
      • Enabled for IPv4, IPv6, VPNv4, VRF AF
      • For iBGP, eBGP, eiBGP
    • Still only one best path advertised to peers.

BGP Conditional Route Injection

  • Originates subnets from aggregate for purpose of traffic engineering.
    • Longest prefix.

Configuration:

  • Inject Map
    • More specific subnet to advertise.
    • ‘set ip address prefix-list <list>
  • Exist Map
    • Aggregate to be originated from.
    • ‘match ip address prefix-list <list>
    • ‘match ip route-source prefix-list <list>

In the image below R2, R3 and R5 are all in ASN 100, R8 and R10 in ASN 810.1. R5 R8 and R10 are running EBGP between the two ASNs.

R5 is going to summarize ASN 100 transit links 10.30.2.0 and 10.30.3.0 into ASN 810.1.

Both R8 and R10 are now showing 10.30.0.0/16 for the transit links within ASN 100. To advertise a more specific route that falls within the summary address, a conditional route injection needs to be performed. This is a valid method of traffic engineering. Currently if R10 is trying to reach the subnet 10.30.2.0/30, it will go over the EBGP path directly to R5. This is because AD for EBGP is much lower than AD of iBGP. Injecting a more specific route into BGP originating from R8 would steer traffic from R10 to R8 first because longest prefix is always going to be more preferred.

Configuration:

  • Create Prefix Lists for Aggregate/Summary, Route neighbor/source, and more specific route.

Prefix-list AGGREGATE is the summarized route from R5.

Prefix-list ROUTE-SOURCE is the neighbor advertising the route inbound to ASN 810.1.

Prefix-list Transit_2 is the more specific prefix we want to advertise into BGP/down to R10.

  • Create Route-Maps for ‘INJECT MAP’ and ‘EXIST MAP’.

‘INJECT_MAP’ defines the more specific route, ‘Transit_2’, to be sent into BGP domain.

‘EXIST_MAP’ specifies what’s there, ie. existing Aggregate (10.30.0.0/16) and the neighbor advertising the Aggregate via EBGP.

  • BGP ASN statement

‘bgp inject-map INJECT_MAP exist-map EXIST_MAP’ defines in the global BGP process everything that’s just been discussed. Clearing BGP neighbors might be necessary in lab. The change takes a while to work.