Distribute, Redistribute, and just plain old filter! Can’t really believe I have missed this for so long

Distribute-lists are the main way of stating what information you wish to pass on / receive with your specific routing protocol they are available in every routing protocol. But bedo behave slightly differently at times (cause they all look the dame docent mean that they act the same).

Distribute lists require either a route-map, prefix-list or an access-list to work,

Lets look at the version with Access-lists, you can use either standard or extended however take note you can only use names with standard ACL’s and extended ones dont all work the same.

All these filters can be applied in the Inbound or the Outbound direction.

Standard ACL’s can be used to permit or deny routes X.X.X.X <wildmask>

This is simply mapped against the route address learnrd and will match the x.x.x.x address where the wildmask states which bits to compare in the route.

Extended ACL’s can match both the source of the route and the route itsself,  where permit / deny X.X.X.X<Wildercard> matches its source and Y.Y.Y.Y <wildcard> is the route you wish to match

Note: Extended ACL’s behave differently when used with BGP (or redistribution)

Alternatively you could use other methods to filter your routes

Prefix uses a prefix-list to define exactly the routes you wish to permit or deny and can also limit this to a gateway (also defined by a prefix-list)

Gateway does away with matching a network and says i dont trust you partner!!

Route-maps for all those weird and wonderful reasons you can dream of you may want to permit a route or not! eg. tagging etc

Extended ACL’s in BGP and Redistribution can also be used to permit or deny routes however these can be used to check the mask of the learned/advertised route (Just like a prefix-list)

with this we can match (Source) X.X.X.X wildcard hoewever (Dest) Y.Y.Y.Y wildcard would be used to check the advertised mask on that route enabling you to differentiate between advertised routes  10.0.0.0 /8 and 10.0.0.0 /16

DVMRP

When Pim is configured on an interface and DVMRP neighbors are discovered, interop mode will the send DVMRP report messages for directly connected networks.

Undercertain circumstances, you might want to tailor the metric used for various unicast routes. This command lets you configure the metric associated with a set of destinations for report messages sent out this interface.

You can use the access-list-number argument in conjunction with the protocol and process-id arguments to selectively list the destinations learned from a given routing protocol.

“DVMRP interoperability” is on by default in older IOS versions. “Prior to the introduction of this command, DVMRP interoperability was enabled by default and could not be effectively disabled.”

“Ip dvmrp metric” command enablesDVMRP report messages for multicast destinations that match the access list. Usually, the metric for these routes is 1.

By default, the local router will only advertise directly connected subnets in DVMRP updates. If you want to advertise more information, use the interface-level command ip dvmrp metric [list ] [protocol ] to redistribute static subnets or IGP networks to all DVMRP neighbors on the interface. If you omit the protocol specification, the command will only advertise connected routes. If you want to filter out certain updates, use the metric value of zero to remove the matching subnets from the DVMRP updates.

the above is adjust a copy from the configuration guide however I am still. Not sure I understand this. More reading necessary

Step in BSR.

BSR Election and Functionality

PIM uses the BSR to discover and announce RP-set information,

The BSR mechanism interoperates with Auto-RP on Cisco routers.

To avoid a single point of failure, you can configure several candidate BSRs in a PIM domain. A BSR is elected among the candidate BSRs automatically; they use bootstrap messages to discover which BSR has the highest priority. This router then announces to all PIM routers in the PIM domain that it is the BSR.

once a BSR has been elected, candidate RPs unicast to the BSR their willingness to be an RP.

The BSR advertises all the group-to-RP mappings its received to 224.0.0.13.

this contrats to auto RP whos Auto-RO mapping agent is responsible for selecting the best RP here in BSR it is each and every router in the BSR network that is responsible for selecting the RP.

BSR lacks the ability to scope RP advertisements; however, BSR is used when vendor interoperability or open standard adherence is a requirement.

Commands:

IP PIM RP-Candidate <INT> group-list <Std ACL>

IP PIM BSR-Candidate <randomize bits>

IP PIM BSR-Border

 Oh my why does Multicast confuse me with the different places to Accept and filter groups / sources

Accept-RP  <RP> <Std ACL auto crated for permitted groups>

Filters the Multicast groups that can register with an RP

This command was quite counter intuitive for me and i still am not sure it does what i think (or even how it does it). in a nutshell it is supposed to allow you to filter register messages.  

This works on the (*,G) joins messages 2 fold (I think), 1 to specify the RP addr allowed to register against and 2 check the group address thats trying to register

if either of 2 above fail then RP will not accept join or register messages and will respond immediately to register messages with register-stop messages

Accept-Register <list/Route Map> (Ext ACL auto created)

this command is used to prevent unauthorized sources from registering with the RP. If an unauthorized source sends a register message to the RP, the RP will immediately send back a register-stop message.

One thing to note about Auto-RP is that it needs to be run on sparese-dense networks (who has those these days) as all the distribution is done in dense mode

If you dont want to run Sparse-dense mode throughout your org then you can just run ip pim autorp listener which will allow you to run just  sparse mode everywhere (it still uses dense mode to distribute the RP info using groups  224.0.1.39 & 224.0.1.40)

Next job it to volounteer to be an RP, cRP (Candidate RP’s) announce (224.0.1.239) they dont mind becomming an RP and which groups they would RP for if they were to be chosen.

who listens to these voulenteers. MA’s (Mapping Agents) listen to these announcements and build a picture of who in the network is willing to work as an RP and who wont. (these agents can be run on the same router as a volounteer or a different one)

Once all the information is in for the potential RP’s and their groups they are sorted and a winner chosen for each group (highest RP IP for matching groups) this info is then distributed to the network in discoverery messages (224.0.1.40)

These mapping agents can apply a filter to permit or deny which groups can be learned from each cRP it does need 2 standard access lists though! ip pim rp-announce-filter rp-list ACL_1 group-list ACL2

All other routers join the 224.0.1.40 network by default and listen for this mapped information, once received they populate their auto-rp cache and they are ready to rock!

Commands

IP Pim send-rp-announce <INT> scope <TTL> group-list ACL_1

IP Pim rp-announce-filter rp-list  ACL_1  group-list  ACL2

IP Pim send-rp-discovery <INT> scope <TTL>

IP multicast boundary IN/OUT Filter-Autorp 

IP Pim Autorp Listener

After speaking to somone in the know as to regards CCIE study, He pointed out the lunacy of looking at the INE workbooks and trying to figure out what config commands are required by guess work.

At best i will find myself sitting there pressing “?” for half an hour trying to figure it out an educated guess..

I should just accept the fact that i dont “Know” the answer and skip straight to the answers and learn them.

so for a new plan i intend to read the workbooks cover to cover before even switching on a piece of kit. (Saves on electricity)

then lookup the details in the configuration guides.

what could be greener or easier

Stop reading now if you think this has anything to do with David Allen, This is all about why i have failed to get to take my CCIE on so many occasions, answer i didnt have a plan! well thats a lie i did have a plan but i didnt have any dates with it.

So below is my new plan, with dates, but is it a SMART plan

Well i think so and it just goes to show why SMAR goals dont work!

So when you do a show IP Mroute you get the following header to detail what each entry is actually there for

IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

Each entry can have one or more of these Flags set here is a list of what each Flag(letter) actually means!

Flags:
D – Dense
S – Sparse
(*,G) Only, Indicating the group is a sparse mode group
B – Bidir Group
s – SSM Group
C – Connected
(*,G & S,G) Indicates a directly connected member for this group
L – Local
(*,G & S,G) Indicates that the router is actually joined to the group and proccesing the packets
P – Pruned
(*,G & S,G) Indicating the OIL is NULL and a prune will be sent to its RPF Neigbour
R – RP-bit set
(S,G) Only, Indicating the S,G entry is for the Shared tree (path to the RP)
F – Register flag
T – SPT-bit set
(S,G) Only, Indicating
J – Join SPT
M – MSDP created entry
X – Proxy Join Timer Running
A – Candidate for MSDP Advertisement
U – URD
I – Received Source Specific Host Report
Z – Multicast Tunnel
Y – Joined MDT-data group
y – Sending to MDT-data group

Outgoing interface flags:

H – Hardware switched
A – Assert winner

upon a router hearing an IGMP request for a group the router will place a (*,G) entry in its MROUTE table

the (*,G) entry is created to show there is a host interested in that multicast group and contains the exit interface to reach them.

these IGMPs are either a Query, Report, or Leave message and are sent over standard IP as below

According to the RFC once a (*,G) entry has been created on the router it should periodically send a Group Query out that interface to check there are hosts still out there wishing to receive the multicast stream, (No more than 1 a minute) upon receiving the Group Query all hosts Queue a Group Membership Report as a response and wait a random amount of time before sending it, When the first host sends its Membership Report it has a DEST address of the Multicast group thus being received by all hosts and the router listening to that group, upon the receipt of this Membership Report the hosts will stop their countdown and cancel sending their own report. (as just 1 host is enough for the router to keep sending traffic)

Thats all well and good for the RFC however in the CCIE lab the 3560 switches impliment IGMP Snooping by default, This means that as the hosts respond with their Membership Report the switch will capture the reponse and prevent it from being flooded to the other hosts, this action means every host will send their Memebership Report to the switch. the switch collates all these reports and ports and stores in an internal table before sending a single Membership Report response back to the Querying router

Also in the RFC If a host wishes to stop receiving the stream it checks to see if it was the last host to send a Membership Report response to the router, If it was the last host to respond to the Membership Query it has to send a Leave Group response (as It may be the last host listening to the stream). Now because IGMP Snooping has forced every host to respond they all think they have responded to the last query and therefore will all generate a Leave Group message when they wish to leave
Again this is intercepted by the switch

Not reverse down the path looking forwards

URPF is basically the device checking that the device that has sent the packet has not spoofed its source IP address….

heres how its goes