Data Center:Network:Cisco:Nexus:Multicast

[Music] okay so now let's look at this with in the case of layer three right now we had the the case where the sender and the receiver were both in the same layer two segments so over here we had server three and over here we have server one okay right now currently they're both in VLAN 10 okay what we're going to do now is to move the sender which is server 3 we're going to move this into VLAN 20 so this will be 20 0 0 30 / 24 the receiver is still saying this the same it's 1000 10 / 24 so first thing we need to do is is to go to the land segment that is connected to the connected to the sender which in this case is a pork channel now it's port channel 30 and I'm going to change the port channel so that it is in switchboard access VLAN 20 then on the server itself I'm going to need to change its IP configuration because it's moving to a new subnet here so it's moving to 2000 30 and we'll say the Gateway is 2000 254 okay we'll still use the same feed we have 225 555 if we take a look at the receiver let's stop and start the traffic feed okay we're not actually receiving anything yet because I have not enabled him on the VLAN 20 segment it was only enabled on VLAN 10 which was allowing us to do basically just the the layer 2 multicast switching within the individual VLAN so let's now go to the VLAN 20 interface where again this is where our HS are P is also running our first hop redundancy so on VLAN 20 IP PM in sparse mode P then 20 I PP M in sparse mode and since we are now routing the traffic and we are running Tim in sparse mode it means that we're gonna have to have a rendezvous point so actually what I'm going to do here is change the design a little bit further so we're gonna have multiple layer 3 hops that we need to go through so we can see what happens when the receiver is behind the VPC member ports and the sender is somewhere remote like in the core or vice versa where the sender is behind the VPC member ports and then the receiver is somewhere in the core upstream so let's take a look back at our topology and I'm gonna make some some changes to this here where server 3 is now going to be up here at the top ok it's going to 5 k2 and 5 k2 is then gonna go upstream to some of the the layer 3 devices so let's actually take a look at our physical topology and I'm gonna show kind of from a high-level overview what we're what we're gonna be doing ok so we have these two other VDCs here 7 k 1 3 and 7 k 1 4 and we're going to be using these as layer 3 hops in the network but if we look above them you can see that they also have f1 ports which are the blue ports there they also have f1 ports that are going to the the five K's okay so the the sender is going to be server three which is up here it's actually attached to the fax where the FEC's is associated to this 5k so we're now going to be using these ports here a1 12 to 13 and to get the layer 2 multicast traffic to 7k 1 4 then we're going to be routing the traffic over layer 3 to 7 K 1 3 then we're going to be routing the traffic down to the V PC peers so there's multiple layer three hops once it gets down to 7 k12 and 7 k-11 they're then going to decide how do we forward this does it need to go down to the V PC members in order to get to where the receiver is so the receiver is actually down here server 1 or are we going to get the traffic in this direction so a couple different options for the traffic flow we're going to see and this is going to have some behavioral differences versus regular multicast forwarding and this is why we need to look at it at layer 3 with multiple hops away ok so from our our logical diagram here we're then have server 3 which is going to go over to 5 K to the 5 K 2 is then going to 7 K 1 4 7 K 1 4 is going to go to 7 K 1 3 then from here we're going down to both of the V PC peers so 7 K 1 1 7 k 1 2 they're then going down to 5 K 1 ok so this is the V PC here and then this is where the final receiver is server 1 so what this picture doesn't show here is what the fabric extenders are but from a logical point of view we really don't need to deal with those because they're just the the line cards of the of the five K's so let me go ahead and mark up what the ports are gonna be here so on 5 k - this is poor Channel 30 that's going down to server 3 so that's actually the two physical links from 5k - up to 7k 1 4 this is going to be e 1 / 12 to 13 then on the remote side this is going to be e 127 or X to the e 2 - 27 - 28 okay so that's going to be a layer 2 channel then we're starting to go across the layer 3 routed Network so let's say the routing here is in blue this is going to be the m1 ports so on 7k 1 4 this is going to be e 1/25 on the remote side that is e 1 17 then continuing to route down we're going to go to 7 k 1 1 via e e 119 on this side this is e 127 which remotely is going to be 1/3 that's 20 actually the e 120 and e 112 on the room outside okay now also what this is going to demonstrate is some of the basic layer 3 routing capabilities of Nexus we haven't really gone through much of the syntax yet of the OSPF routing or ERP routing we are going to be talking about that later also within the scope of OTV how we can use the layer 3 routing over the data center interconnect and then use that to tunnel layer 2 over OTV over layer 3 over the DCI but for this case we're going to do let's say we'll do some basic OSPF routing just to see some of the syntax differences as well from Nexus to the to the regular routers ok so first let's start on the the layer 3 segment so let's go up to 7 k14 I have a couple more windows I need to open here 7 K 1 4 & 3 and seven k14 this is going to be where our layer 2 receiver is now so let's say on interface is e 2 slash 27 to 28 this is going to be a channel group so we'll say channel group 52 actually I think we're using 52 in another portion let's say anything 3 3 3 okay really as long as this is documented that is going to be the big point so this will say is port channel 4 channel 3 3 3 now within the scope at the CCI lab exam this is going to be one of the big hurdles that you're gonna have to deal with is just using the or figuring out the large topology if you're giving a physical wiring diagram and then figuring out how the logical VDCs are gonna fit in and then what would be the layer 2 topology versus the layer 3 topology and just to keep track of all these different link numbers that we're going to have to deal with so here this is going to be a channel group this is also going to be a layer 2 trunk so on let's say no shut down there on interface 4 channel 3 3 3 we'll say switch port mode trunk switch porch us or the spanning tree port type is network and thus a terminal monitor okay this is now going to be where my VLAN 20 is changing to so on 7k 1 & 2 they're no longer gonna have you than 20 hey additionally they're no longer going to have that VPC that's going up or that's going down to the second 5k they only have the V PC that's going to the first one now so no interface port channel 52 you know interphase port channel 52 okay from 5k to that that was port channel 7 you know interface port channel 7 and let's just let me just shut these ports down let's say interface II won 8 to 11 is shut down okay instead what this is now going to be is e1 12 to 13 channel group 333 mode active poor channel 333 is a switch port mode trunk spanning tree poor type network now on 7k for this is where the layer 2 layer 3dmark is going to be for the multicast sender so this is now where interface VLAN 20 is going to be so when you feature interface VLAN will say interface VLAN 20 IP address is 2000 254 / 24 so that's what the default gateway of the server is previously this was an HS RP address in this case I'm just going to use it as the the regular primary primary IP address that is assigned on that link so if we look at now and also let's configure view then 20 so we create it and then let's look at the show spanning tree for view then 20 so if this is working we should see for channel 3 3 3 that's forwarding downstream 5k 2 if we look at the show spanning tree VLAN 20 we should see the host port which is the port channel 30 and then we should see the upstream port channel 3 3 3 so this is actually the wrong output from spanning tree okay anytime we see on one side that we have the port Channel but on the other side we have the Member links and from the perspective of spanning tree this means that there was some error in the formation of the port Channel and we should be able to further verify this if we look at the show port channel summary it's gonna tell us that port channel 3 3 3 has independent member ports this capital I means that these links have not channeled together so there's something wrong in the config here let's look at the show run interface II 1 2 12 to 13 and show run interface port channel 333 and then compare this what's on compare this with what's on the other side if we show port channel summary show run interface port channel 3 3 3 and show run interface e - 27 - 28 ok what did I miss here does anybody catch it one side is using LACP for negotiation the other side is using no negotiation that is the reason why when we look at the show port channel summary on 7k 4 it says that the channel is up even though the other side does not agree with that now this again is one of the reasons why you do want to use LACP for all of your layer 2 or layer 3 channels it's going to prevent the case or on one side we configure the channel properly and then on the other side we miss configure it what if the channel is on and is using no negotiation it has no way to catch that so basically what I've done here has formed a layer 2 spanning tree loop so if I send any packets out that interface they're gonna loop right back to me ok so what I need to do is to go to these member ports e2 / 27 - 28 and say that the channel group 3 through three is mode active or passive not mode on and you can see here I don't have LEC P on so that may have been the issue before so Channel group 3 3 3 mode active says adding active mode port to an on mode port channel is not compatible ok now we have an order of operations issue that the channel was not properly initialized to start so basically we have to roll back a couple steps so let's now delete the port channel go to the member ports channel group 3 3 3 mode active and if we show run on the poor channel we still need to go to the port channel and say the spanning-tree port type is network okay now on the 5k we should see that the links are channeled if we show spanning-tree VLAN 20 now they're going upstream via 333 which is what we want to see okay if we go to the 7 k 7'k 4 which is now the layer 3 gateway of that server we should ideally be able to ping we show IP interface brief and let's bring up the VLAN no shutdown we should be able to ping a 2000 30 which is the server's address because again I always want to test my basic layer to reach ability in layer 3 reach ability within the layer 2 segment like the VLAN before we move to any routing so I don't want to waste time troubleshooting multicast when I didn't even know within that VLAN do I have reach ability from the end host to its gateway then do I have my basic routing protocols configured do I have unicast reach ability then we can look at the the multicast routing ok so now we have the first portion of the segment bill which is the the top portion up here so I have connectivity from server 3 to its gateway okay this is where VLAN 10 or excuse me VLAN 20 has the address 2000 254 slash 24 ok so now we're going into the rest of the layer 3 routing domain so let's now say that these addresses let's use something unique that's not out of use let's say 150 150 . 1 actually let's say 150 and dot 70 3.74 so it's between 7 k 3 and 7 k 4 and this will be 0 slash 24 I'll use the host addresses that's 73 and 74 so we know which particular host that we're dealing with or which particular end of the link that we're dealing with ok so on the first port this is going to be e 125 we're remember the default mode for these is no switchboard these m1 and modules are going to be layer three automatically so on the link let's say the address is 150 73 74 and I am seven 4/24 on the remote end interface II one seventeen no switch port that's actually the default again IP address 150 73 74 dot 73 slash 24 okay so now I want to test do I have this basic IP rich ability between these hosts no route to host this just most likely means that my link is down because just like in regular iOS or catalyst iOS we cannot install a prefix in the routing table if the link is down so on 7k for I didn't say no shut down once I do that I now should have layer 3 reach ability ok next step is we're gonna enable routing so let's say feature OSPF again basically everything is is licensed and enabled individually so you have to say feature for whatever you want feature OSPF feature erp feature BGP etc ok next step is we need to define the process globally router OSPF 1 ok nx-os you have a little bit different process tag here for the process identifier you could use alphanumeric characters you could say router OSPF ABCD efg in this case I'm just saying router OSPF 1 ok just like in regular iOS it's a locally significant process number you can't have multiple processes you just need to make sure keep track of what are the names or numbers because once we apply it on the link to add the link to the OSPF database I need to make sure it's running the correct process ok so two steps so far is that feature OSPF then router OSPF one globally then at the link level where we have IP IP router OSPF one area 0 so a little bit different syntax than regular iOS but spend an hour or so with it and it's pretty self-explanatory how the process works okay I also want to say the same thing on my view then 20 I want to advertise that into the layer 3 routing domain ok let's look at the show IP ospf neighbors the Qiu a state here means that I have sent them my hellos and they have acknowledged me by putting my router ID in their response so I know that we have bi-directional communication here so we should should see here shortly once we form the adjacency that this is going to go into the full state one of them is going to be the designated router one of them is going to be the backup designated router ok normally from a regular layer 3 routing design point of view I would then want to take this one step further and go to this layer 3 interconnect change it to OSPF Network point-to-point so I don't need to have the additional OSPF LSA 2 in the database because if I'm only using point-to-point Ethernet segments it doesn't make sense that I need that extra link state advertisement for the designated router so I can change it to point-to-point and make the the control plane look up on the back end a little bit more efficient ok but in this case as long as we have basic reach ability that's all that we that we really care about so we could skip that step ok on 7 k3 now let's look at the show IP route OSPF we see we have the 20 segment so I should now be able to ping 2000 30 okay so just basic OSPF routing there's nothing really too complicated about the other syntax here okay so now on 7 k3 I need to continue this downstream so this is going to be on e 119 this is going to be going to 7k 1-1 will say no switch port IP address 150 they are 71 I'm 73 my host address is 73 / 24 IP router OSPF one area 0 ok then likewise interphase 20 this is 2 7 k12 IP address 150 72 73 73 / 24 IP router OSPF one area 0 whoops and now it's shutdown okay additionally on this router in the middle or the switch in the middle 7 K 1-3 I'm also going to advertise a loopback interface let's say 1 1 1 73 / 32 IP router OSPF one area 0 we're gonna be using this for rpm rendezvous point so 7 cave 1 - 3 that's gonna be this the route of the shared a tree so for the star comma G when we have the receiver send the InP report saying I want to receive traffic for this particular group it means that we're gonna build the shared a tree or the RPT up to this router when we then look at the show ipm route we should see that it is the route of the star comma G with the outgoing interface list or the Oh il pointing down towards the V PC peers that are ultimately going to go to the other receiver so same normal multicast routing logic same normal normal multicast layer 2 switching logic really the only thing that's going to change we'll see here is when we go across the V PC okay so let's continue down then to the V PC peers feature OSPF feature Ichiro SPF okay next we have e 112 that has the address 150 72 73 72 IP router OSPF one area zero no shutdown and then for my VLAN 10 I'm gonna advertise this as well IP router OSPF one area zero now I do need to make sure that I still initialize the global process unless you actually turn the global process on the interface level commands are not going to do that for you okay this is a behavioral change from regular iOS or catalyst iOS that once you initialize the OSPF process at the link level it will automatically start the global process and nx-os it does not so you just have one additional come and start the process globally okay if we then look at the show IP ospf neighbors based simply on the fact that i see this output it means that i have basic layer 3 connectivity to them so i'm sending them multicast going to the to 2400 5 from 4 OSPF they're responding we're in the 2-way state we should see that one of us is going to be elected to designate a router 1 is going to be elected the backup des native router ok same thing is going to happen on 7k 1 and so let's say router OSPF one interface v13 IP address 150 71 73 71 IP router OSPF one area 0 you know shut down and then i need to advertise the VLAN as well now here since I'm running OSPF on the VLAN that the the V PC peers are sharing it also means that I'm going to have a routing adjacency there and the routing adjacency should be exchanged over the V PC peer link now since that's considered the control plane that should be fine but I do want to avoid the case where I would be routing my normal layer 3 traffic over the V PC peer link so if we look at here the show IP ospf neighbors I see that for 1000 72 this adjacency has occurred over VLAN 10 but where does VLAN 10 actually exist if we look at the show spanning tree for VLAN 10 VLAN 10 exists on the VPC peer link so from a layer 3 routing point of view you generally would not want to use the VPC peer link I should either have some upstream layer 3 that goes to the core that I route out and then come back or I could have another layer 3 link directly between the neighbors ok but in general your distribution switches probably don't need to be routing to each other because they're already on the same local layer to land segments so what actually may be more appropriate in this case would be to go to the OSPF process of these routers and say that those links are going to be passive so let's go I believe this may be under the direct link level let's say on V then 10 IP ospf passive interface ok so as opposed to regular iOS and catalyst iOS that's under the global process the case of nx-os most of this is at the link level IP ospf passive interface so now when I show IP ospf neighbors I should not have the adjacency to my EPC peer over the peer length because I don't want to use that for data plane I only want to use the V PC peer link for control plane and here in the case of multicast it's kind of a necessary evil that traffic is going to be flowing over the the V PC peer link okay now let's look at the final result of the the routing domain if we look at the 7k at the top which is going to be the sender's default gateway let's say show IP route OSPF I should be learning the VLAN 10 segment okay really this is the only route that I care about in this case the the interconnections between them the addressing on those are arbitrary it could be using link local addresses I technically could be using a number for them really I just want to make sure that I have the the the destination final land segment so if I peeing 10000 10 yeah I want to have reach ability there if we look between router 2 and router 3 we should now have reach ability between 2 & 3 show run interface cake zero zero and I believe what the problem is here is those static Arps that I had in before let me remove those the static ARP is no longer gonna work because my gateway changed physically my gateway changed okay so right artoo and router 3 do you have reach ability if we were to do a trace route between them we can see now that they're multiple layer 3 hops away so they go first to the default gateway so router 2 is forwarding this to 7k 1-4 then it's routing the traffic to 7k 3 then it's being load balanced with equal cost multi path or ecmp based on our just normal regular unicast routing logic is going to both of the VPC peers then the VPC peers are sending this down to router 3 so normal unicast routing rules apply there's nothing really special about this this design ok now let's look at this within the scope of the multicast routing next step we need to do is basically enable pim everywhere so it's going to be on all three of or excuse me all four of these seven KS we need to enable PIM on the layer 3 links so this is going to be on the SVI uh VLANs 10 and 20 we also need to specify what is the rendezvous point so we could do this statically we could use some of the dynamic mechanisms Nexus also does have a specific any test our key implementation that is different than the MSTP based anycast RP that is in regular iOS but most of multi guest is going to be very similar okay there's also a documentation segment that you would want to take a look at here and let me open this up on my web browser which is going to be the let's just search for Nexus 7000 wiki it is on the Sisqo wiki here if you look for the 7k documents so categories Nexus 7000 series switches the nx-os and iOS comparison tech notes so I would definitely recommend to bookmark this and read through all of these sections okay most of them are very quick that you could go through them in our case were specifically concerned about multicast routing here so it talks about what are some of the caveats that are different with nx-os versus regular iOS first one the IP multicast routing command does not exist you don't need to use that ok the only thing you need to do is say feature pim that's kind of the replacement of it ok also MSTP is a separate license feature so you would say feature MSTP says an IP snooping courier is configured under a layer 2 VLAN with the IP igmp snooping Quarrier CLI in iowa software and igmp snooping Quarriers configured under the layer 3 interface so you see there are some minor caveats here I should be snooping as a layer 3 lookup as opposed to a layer 2 Mac look up what I really want to see is just what is some of the comparisons of the commands so if you scroll down you'll see this is the iOS command this is the equivalent nexus command ok what I would want to see for the rendezvous points are going to be what does the auto RP syntax look like what does the bootstrap router or the BSR syntax look like so I could say that my loopback is going to be the bootstrap router candidate I'm gonna be also the rendezvous point candidate this is the particular groups or group range then I'm going to be servicing so you send me registers for those you send me PM joins for those it's normal multicast PM routing logic except the syntax is a little bit different ok so again the only thing I did here was just if you just search for Nexus 7000 wiki it's on the Cisco wiki and then you want to go to the the the nx-os and iOS comparison tech notes okay so let's go back to 7k 4 and we're gonna go to global config turn feature p.m. on my PM rendezvous point address is 1 1 173 so that's gonna be the switch in the middle then on the layer 3 links IP PM sparse and the point-to-point link IP p.m. sparse we show IP p.m. interfaces and I believe we can say show IP interface brief is well here so this just tells me what are the particular links that I'm running the process if this was a PM a border interface that would be for filtering like the BSR or the auto RP advertisements to make sure that we're not advertising our control plane information out to some remote multicast segments then we have next in the middle on 7k 3 we basically just need to do this on all of the interfaces that are running OSPF so if we show IP ospf interface brief will say feature pim IPP MRP address is me so 1 1 1 73 on e 117 pim is running in sparse and on e 119 220 now for the V PC peers they're already running PIM on their VLAN interfaces the only additional change I need to make is just to configure it on the upstream ports towards the core so IP pim sparse ok also I need to know what's the rendezvous point IP p mr v address 1 1 173 I pee Tim sparse IPP m RP address 1/1 173 okay so now let's look at our pm adjacencies if we look at the show IP pm neighbors says I have an adjacency over the VLAN okay over the the layer 3 interface that's going over the peer link I have an adjacency the over the point-to-point layer 3 routed interface that's going up towards the core then likewise on 7k 1 if we show I ppm neighbors if we go up to 7k 3 in the middle show I ppm neighbors we have our three neighbors then likewise on 7k 4 so really there's nothing special about this config it's it's standard multicast logic we need unicast routing on that's gonna allow us to do our reverse path forwarding lookup we need to turn pim on we need to turn PIM sparse specifically at the interface level then since we are doing any source multicast ASM not SSM means we either have to have a rendezvous point statically through auto RP or through VSR or through any caste and that round of a point also could be bi-directional if we want to do only star comma G in the multicast routing table as opposed to shared trees and shortest path trees or source trees ok the default is going to be that we're running both we have share trees and shortest path trees now we should be able to see the final result of this which is going to be that the sender server 3 is actually able to get its traffic to the destination yeah we're still sending the feed and let's actually let's do this to a new address to make sure that we have the brand-new control plane that's going to be built so let's say that this is 220 3 3 3 3 so we have the hundred Meg UDP feed going to 223 3 3 3 now if the multicast routing domain is working the first thing that I should be able to verify here is that the rendezvous point which is seven k13 has the s comma G for the server because with the normal pin operations we have the pin designated router that is gonna send the rendezvous point the register message saying I know about this source I know about its group that it's sending to you need to install that in your multicast routing table then if you receive a star comma G join so a pim share tree join you know that I have the receiver and you could build the shortest path tree back to me so here if we go to 7k one three and look at the show ipm route we should see that we have the sender which we do 2000 30/30 to going to 225 actually now that's the old group okay let's say clear IP m route star and it's show IP to IP m route it we should see this for 223 we may just be converging here let me make sure that the the server is actually sending the packets so it's sending - let's try another group two twenty three three three four let's say okay it's sending them out 2000 thirty two two twenty three three three four so if we show ipm route to two twenty three three three four say for any source shared tree okay what this means is that the registration didn't get from the designated router up to the rendezvous point so we actually need to go one hop back now towards the sender and see if there was any communication problem from it to the rendezvous point so let's look at on seven k14 did i configure show IPP m RP says one one 173 is the round of a point for all group ranges to 2400 0 / 4 can I reach one one 173 I can on the 7k did I turn him on the interface no so this is probably the issue if we were to look at the debug IP PM we should see the registration going but the rendezvous point is not going to accept it unless it actually knows that it is the rendezvous point and that link is running pin so likewise if we show IPP m RP mapping or to show IPP m RP in this case okay we are the rendezvous point this asterisks means that this is me and let's try to register a new group so let's stop the feed let's say two twenty four four four four now this is also relevant that we're talking about multicast routing here as well because we're going to need to cover this in more detail again when we get to overlay transport virtualization because it does require by default that the core of the data center interconnect network is layer three multicast aware so we're going to look at cases where we are using multicast in the core for OTV and then we're also going to look at the adjacency server feature that is used for tunneling over unicast okay next let's look at the show ipm route again on the ground of a point we should be able to see this group address okay we have this on the first hop receiver says my incoming interface is V then xx my outgoing interface is null the reverse path forwarding neighbor is 2000 330 so it means it's my directly connected link so let's show IP route 2000 30 ok that's directly connected via the VLAN which is correct the VLAN should be running pim which it is if we then show IP pim interface brief we should have him on the other link as well okay basically at this case we need to debug we need to see what's going on with the registration I should see packets coming in the data plane on the first top designated router I should see a generating a unicast register to the rendezvous point rendezvous point should be replying back to me with register stop if I can't get the rendezvous point to know about the server or the source of the multicast then the receiver is never going to be able to join the tree so just like any other protocol you need to know what are the individual building blocks of it in order to get a fully functional design okay so now let's look at the debug IP PM let's say data register send and receive let's all say it also say null registers and join perón so there's no just debug IP pim you have to choose the specific ones can't we're log into the console there let's say the same thing on the rendezvous point so debug IP pim data register receive and send no registers and then just general join prunes terminal monitor now one thing we didn't actually mention this up to this point yet the way that we're connecting to these boxes is with telnet over the management 0 ports so this means that if i want to log messages like debug messages to the to the vty ports i simply need to say terminal monitor and i can say that i'm logging to the monitor at level seven this means that i'm getting basically everything up to severity seven for debugging when you come in on the console of nexus it doesn't allow you to send severity seven messages by default it doesn't allow you to debug to the console what you actually need to do if we look at the show run line con here where let's say show run begin con co n i'll actually let's just go it down to the bottom what you actually have to do to allow this to work and this actually would only show up in the default VDC so let's go to the first nexus show run you have to bump up the speed at the console to 384 so 9600 which is normally the default for console is not high enough to allow you to send debug messages to it so the workaround in our case here is just we're tell knitting into the management port and you can send severity 70 to that so it's not a problem but if you were locally connected in the console and you did want to do a debug you need to set the speed to 38 for and it will tell you that in a log message if you try to say logging console 7 this is not gonna let you do that it says you need to change the speed up to 384 ok so next let's go ahead and send a register so let's go to the server let's stop what we're sending let's try a new group let's say to 27 777 what we should see is that the first top router the dr saw that ice I know about the source 227 777 ok I'm going to send to the rendezvous point 1 1 173 the register message ok I'm trying to tell them that I now know about the new sender the rendezvous point should be receiving this register message says I received the register for that s comma G 2000 254 so that was the designated routers address it sent me the registration for the server 2000 30/30 2 comma 2 27 777 / 32 says that the RPF for the m route is successful so there's no reverse path forwarding failures says i'm creating the routes and i'm adding it to the multicast routing information base TM rib I should then reply back with register stop this is my acknowledgement to them saying I know about the sender we should now see that this is inserted into the routing table it's possible I may actually be using the wrong show command to verify this then let's look at the show IP do I need to say M fib here let's say show IP m route let's say show IP m route detail no now it is appearing so actually didn't change anything welcome to the lovely world of nx-os okay so eventually eventually it sorts itself out there so there was actually nothing wrong in the routing okay so now the rendezvous point knows about the the sender and the receiver okay the outcome the outgoing interface list is null which is expected because we don't have any receivers yet so we only know about the sender we don't know about the receiver but this is the first major milestone and the multicast routing we have built the shortest path tree excuse me would not we have not built the shortest path tree yet but we know from the rendezvous points perspective we know about the sender okay that's because the designated router told the rendezvous point that yeah there's a couple questions here let me field some of these before we continue does it need to have the I ppm command under the loopback yes it does 223 is not in the multicast range someone said that would actually makes sense why it wasn't working so the multi s train starts at 224 but previously even the 224 444 wasn't showing up so it may have been just convergence but that's right 223 is not a multicast address there's a question I thought the RP interface had to have p.m. on it which it did just to clarify do you suggest that dynamic routing neighbor adjacencies are not necessary between the distribution layer and 7k switches do they need to pass routing updates between each other at the distribution layer it really depends on your design you could do it that way you don't necessarily need to it depends on what type of routing you need to do between the devices so basically let's look back at the the physical topology here and essentially what's happening is that these two switches okay these again are the V PC peers and these are the demarcation point for the layer 3 network which is happening up here and then the layer 2 network which is down here so we have these VLAN interfaces we have VLAN 10 on both of the 7 KS and B then 10 is also running HSR P okay we're running HSR P over the V PC so we have that special behavior which means that we can forward even if we're not the active router so we have the basically the active active for HSR P not the active standby but we need to think about in what case would we need to route traffic between these two neighbors now one of the cases could be that on the access layer switches we have hosts that are in different VLANs so we need to do normal inter VLAN routing so if I were to have VLAN 10 down here and VLAN 30 over here means that these switches are going to have to do the layer 2 packet rewrites so they're gonna have to change the packet between broadcast domains by changing the MAC address leaving the layer 3 header alone and doing our normal routing but in order to do that we don't necessarily need to have a routing adjacency and the reason why is that these VLANs would normally be directly connected interfaces regardless on them so whether we are doing the layer 3 routing directly between our local SV is or maybe there is a case where the traffic goes across the peer link and then is routed and then to the destination we still wouldn't need a layer 3 adjacency in order to accomplish this now the potential the potential problem we can run into then is that if we do not have a routing adjacency between them there are certain failure situations that could cause one of the VPC members not to be able to forward traffic up towards the core but they would be able to receive layer 2 switch traffic and basically kind of isolate portions of the network so let's say that we don't have OSPF on the the VLAN tanning interface between them so I set that to be a passive interface okay this is the layer 3 network up here we have multiple up links to different neighbors so we have multiple layer 3 routing adjacencies now if one of these neighbors one of the VPC peers let's assume it loses all of its layer 3 up links ok maybe they're on the same line card the line card fails where we lost all of our up links to the core this neighbor is still a VP see here losing our layer 3 up links doesn't necessarily cause the peer link to go down and that's actually the design that that document was talking about of doing the enhanced object tracking with the VPC domain to say that if I have only one m1 module that's facing up to the core and across to the peer link what I should do is track the core facing links and if these go down I'm going to force the peer link to go down which means that I'm going to lose my primary role because in this particular case if I don't have a routing adjacency here between the or over the layer to peer link and the core phasing links go down I cannot reroute my traffic that way so layer 3 reach abilities to the core is lost but I still am going to be receiving layer to traffic in from my BBC member ports so basically it means I would be receiving layer 2 traffic that I cannot forward at layer 3 so in that case you may want to routing adjacency over or between the SV is between them it's probably a better idea to have a dedicated separate set of links so to m1 cards on one chassis to n1 cards and another chassis so you have two links that are going between the four cards you can figure this as a twenty gig port channel make it a layer 3 interface configure your routing adjacency over that which is then going to prevent the case that native layer 3 routed traffic would not have to go across the V PC peer link because remember the V PC peer link we want to try to keep this only in the control plane none of the data playing ok the more data traffic that's going to go across that the more likelihood that we're going to have a failure of the entire V PC domain because we can't do the basic synchronization of like the Cisco fabric services options ok there's a question oh there any hacks to redistribute dense M routes into sparse since Nexus doesn't support dense basically what you would have to do is just use another router have it run sparse on one interface and dense on the other and then you could merge the two trees together so you technically can interoperate both of them you're really not supposed to but it will technically work if you do that so the reason why is that Nexus doesn't support dense but it only supports pods bar spoke up him ok so let's go back to our let's go back to our servers now so we we have server 3 sending the packets in the data plane ok they're going to 227 777 we saw the rendezvous point knows about this knows about the sender and the receiver we do not have an outgoing interface here because we don't have a receiver yet so now we're gonna go to the other server and tell it we want to join this group so 227 777 we're not yet receiving the multi guest feed in so it means the tree is not yet built in to end okay so let's look at what happened when the join was sent the joint should now be coming from server one server one should be sending to join or not the join technically it's an IG MP report so the IGP report is going to 5k1 5k1 should know about this from igmp snooping so if we say show IP igmp snooping groups we know that out port channel 10 there is a neighbor that's trying to receive that feed okay we then need to see on the upstream layer three peers on the 7ks do they know about that group so let's say show IP IP snooping groups I do know about the receiver show IP igmp snooping groups okay let's see what the multicast routing table says did I start to build the shared tree now show IPM route for 2:27 well let's just show IP route for everything okay we do have the shared trees start to be built but which peer are we going to build it on are we going to build it on the secondary or the primary of the VPC peers this is another design consideration we need to think about of multicast interoperability with the VPC so in 7k 1-2 if we look at the show VP see this is the VP see secondary let's look at the VP see primary show VPC role and see if there's any change here let's say show IBM route four to twenty seven seven seven seven I've joined the share to tree but I have not yet joined the shortest path tree or the RPG or as gonna be the SBT hey the incoming interface is e 1 3 with the RPF neighbor of seven k3 ok that is correct because they are the rendezvous point for that particular group if we show IPP MRP says all groups to 2400 0/4 are serviced by the rendezvous point 1 1 173 if we look at 7 k 1-3 let's show IBM route says now the outgoing interface list is e 120 and e 119 so it looks like the tree should actually have been built but why then is the traffic not forwarding downstream towards the V PC peers okay there's a couple useful commands that we may want to use here let me bring up the slide for this okay the one that I've been looking at so far as show IP igmp snooping groups this is gonna show us from the layer two IGMP report messages that the end hosts are using to say I want to get on a specific feed I want to join a particular group then the nx-os at layer two is going to receive this for this to the layer three process and say that layer two port it's trying to receive traffic for that group okay this will tell us that the receivers are properly sending their other joins we have show IBM route that's gonna look at just the basic layer 3 multicast forwarding table we have the show IBM route summary software forwarded ok this would be the equivalent of the show IBM route count in iOS so let's take a look at this what this should show us is what is the total counters of the packets being forwarded for the group so if we show IBM route show IP m route 227 777 summary software forwarded it says the outgoing interface list is two interfaces but there it is not actually forwarding the packets let's check the sending application make sure it's actually still running and I may actually have actually there's a problem in the testing application is what it is the time deliver these packets is one so let's stop this let me bump up the TTL let's say sixteen and send it again so it wasn't a problem with the tree it was actually a problem with the sender so let's come back to that counter in a minute let's check is the the receiving application getting the packets now okay now it is okay so even multiple layer three hops away if we look at the jitter it's still pretty low it's point zero five milliseconds point zero three milliseconds so it's still pretty fast even though we're having to go over layer 3 routing so this count this counter is not going to be real-time here it's going to update eventually I'm not sure exactly what the interval is we may have to there we go because the multicast traffic is not being processed switched it's being switched down at the line card so the statistics are our sample but they're not sampled in real-time okay eventually this bit rate is gonna go up somewhere around a hundred bag okay but now let's look at what's that what's the final forwarding result where if we look back at the topology and let me clean this up a little bit let's let's redraw this diagram okay we can take the five case kind of out of the picture because they're just used for layer 2 so we have switch three that is on the layer tool and that has n7k 1-4 as the default gateway so this is the 2000 0/24 segment okay we're then going over to n7k 1-3 who is going down to the V PC peers n7k 1-1 and n7k 1-2 okay this is where we have the V PC peer link between them we have to keep alive and then we have our V PC member that's going down to 5k one which ultimately goes down to the receiver switch one okay switch ones on the ten network 10000 / 24 so we're seeing now that the the sender was sending the packets the pim designated router sent the register to the rendezvous point the rendezvous point then inserted the s comma G saying I know about the sender okay then we have the receiving application sending the IGMP report and the report comes in it's telling the layer to switch I'm trying to get on this particular star comma G layer to switch is going to install that based on IG MP snooping it's then gonna flood the join or the report message okay because it's gonna be a basically a layer to broadcast essentially okay it's going to go up to both of the the BBC peers they now know about the star comma G where the outgoing interface list is the V PC member the incoming interface is going to be towards the round of a point so they're now getting on the shared tray they're sending the star comma G Tim join to the round of a point round of a point says I know about the sender I now also know about the receiver I need to tie these two trees together so the rendezvous point is then gonna say to the originating designated router I want to get on the SPT so it now sends the s comma G join back towards and seven k1 for now the traffic actually starts to flow okay we know at a minimum that the traffic is getting to the rendezvous point and then the rendezvous point is sending it down to both of these neighbors okay but we don't actually know what's happening once it gets down to the V PC neighbors so who of the V PC peers is actually forwarding the traffic down towards the receiver so let's look at now 7 k 1 1 & 7 k 1 2 this is where we need to basically look at our interface counters let's look at the show IP route and I basically want to see what's the incoming interface for the multicast packets okay it's going to be 1/3 if we look at the show interface II 1 3 I want to know what's the input right okay this means I'm receiving the feed ok the input rates 87 Meg's so it's definitely coming in that link hey on the other side likewise let's do the same thing if we show IP route says we have a 112 let's say show interface me 112 and I want to look at the input rate okay we are receiving the packets here as well so the VPC peers are actually received both of them are receiving the traffic ok next I want to know where is it being forwarded from them are both of them forming it downstream towards the receiver or is only one of them forwarding okay normal multicast forwarding rules would dictate that only the assert winner should forward if we have both of them forwarding it just means that the receiver is gonna get duplicate feeds it's not necessarily gonna mess up the application but it just means that it's kind of an inefficient battle-ax flow so let's look at what would our downstream ports be then let's say show VPC the downstream VPC is 51 if we show channel group or a show port Channel show port channel 51 summary or just show port channel summary this is made up of the member links to to 213 and 214 so let's show interface e to 13 and I want to look at what is the output rate let's say that that link so 13 to 14 include output rate okay actually what I should be looking at here is additionally the the peer link as well so let's look back at the let's look at our previous diagram that had the the V PC the packets are now coming in from upstream okay so the multi guys is being received from the layer three core it's coming in this way and it's coming in this way seven k12 is the V PC secondary seven k-11 is the V PC primary so one the feed is received in the secondary do we send it out the peer link or do we send it out the member ports down to the receivers so I should actually be checking interfaces to nine through 14 and let's say include also Ethernet - so which of these links are we forwarding on then I'll put right here is pretty low that one's pretty low low low low low we're actually not forwarding on any of them okay let's look at the other side let's look at the the V PC primary these are links eetu 1 - 2 - 3 - 4 + 2 5 - 6 and let's use that same show command syntax that's interfaces e 2 1 - 6 ok the output rate of the first link is high this is where the multicast flow is going ok it's also going out e 2 3 e 2 3 is one of the member ports this is actually how it's getting down to the receiver ok this is good and this is what we would want because we don't want the multicast flow being replicated down more than one VPC member port because ultimately the UDP flow is going to be a it's going to be a single flow from the purpose of load balancing ok so we have the unidirectional multicast feed when it gets to the ether channel load balancing regardless of whether it's looking at the layer 2 3 or 4 information for load balancing the entire flow should land on just one member link ok when it does I want to make sure that it doesn't go out additional VPC member links because the the destination we don't want to receive duplicate packets ok so it's going out the downstream e - 3 link but it is also going out the peer link so it's going across to the secondary the secondary is getting it but the secondary is not actually doing anything with it and the reason why again is based on the V PC check so it's saying packets are coming in on the peer link my remote V PC peer has active members of the V PC so packets that are coming in the peer link they cannot go out my local members those are normal layer three loop prevention over the V PC now there are some additional changes beyond this for V PC that other than forwarding over the the peer link and then we could continue to forward out orphan ports if we had those locally but we're not going to forward out the the the downstream links but one other thing that is different here when we look at the show IP m route for the V PC secondary ok notice that the V PC secondary has joined the shortest path tree under normal cases the assert winner is the only one that is going to be joining the shortest path tree the reason why is that we don't want additional flows of multicast going on links that aren't altom utley going to be used ok and this is actually an optimization of V PC that you normally would want what essentially is happening is the let's go let's go back a couple steps here in the in the workflow so we have the IGMP report message come in ok the InP report goes to goes from the server that's trying to receive the traffic it goes to the layer 2 switch layer to switch with igmp snooping now knows what the port it's located on it continues to flood the iamp message because the item P is a is a link-local multicast that's going to go across the entire land entire local LAN now one of these devices normally should be elected the PIM designated router so we could have designated router one or designated router 2 but normally not both of them specifically within the scope of V PC that's where this dual dr or the proxy dr is coming in so even though in reality one of them is the dr the other is not and the one that becomes the proxy dr does automatically join the PM shortest path tree for the receivers so the final result is actually we have duplicate multicast feeds so we go from the sender the first stop switch first up switch over layer three to the round of a point we should normally go down just to whoever is going to forward the traffic like the assert winner but in this case we're also going in this direction these packets that come in here they are not being forward downstream we saw that based on the counters but what this is going to allow us to do is to have faster convergence of the multicast control plane indicates that the V PC roles need to change so let's say for example that on seven k-11 it's V PC member port fails so it no longer has connectivity down to the receivers okay in the case of normal forwarding what would happen is that the receiver would have to send its IGMP report message again and so it does periodically refresh that based on the InP query interval but the the receiver says I still want to get the feed whoever is the other router on the land who would be the new assert winner then would then have to join the shortest path tree in order to get the multicast traffic to flow down to the receiver so the problem though is that there's going to be extra latency that's involved of joining the tree so we have to send the pim join messages on a hop by hop basis before the traffic can actually flow back down so if we actually look at this from a failure point of view let's look at our receiving application okay we see that we're still receiving the packets in the the jitter between them is fairly low now what I want to do is go to the first 7k and we're going to shut down the member ports of the V PC when we do this over the peer link with the CFS OE protocol the cisco fabric services protocol we are going to tell from the V PC primary to the V PC second area my member ports are down okay that means that your forwarding loop prevention now has to change packets that get to you from the peer link those need to go down the member because I now have orphan ports or more specifically you have orphan ports because we're no longer dual attached down to the other VPC members so if we show VP see here this is VP c-51 let's go to this link and shut it down and see what happens with the multicast traffic okay there was a packet that was received out of order but there was no disruption in the flow so we can see that the the jitter there was still less than one millisecond so point zero six milliseconds between the packets under normal multicast reconvergence this is going to take a couple seconds that we would have to figure out that there was a failure the next hop router who can now complete the forwarding path is gonna have to rejoin the shortest path tree everyone is gonna have to acknowledge this back and forth because it goes on hop-by-hop basis then the traffic finally can forward down to the to the destination okay but here now if we continue to receive the traffic let's look at these statistics again on 7k 1-2 we are now going to see on the output now the VP see member ports are being used here okay notice the input for the peer link the input is 86 87 megabits per second okay let's also actually include the the m1 port so what's the m1 port upstream here show IP route the m1 port is e1 12 a 1 12 has an input rate of 90 Meg's same as the V PC peer link so it is an inefficient flow in the data plane but it is at the expense of low latency for the reconvergence and that's really the main reason that we're using the V PC peer link not only to be able to service the orphan ports that could be on the remote V PC peer but if there is a failure of your V PC membership downstream or if there is a failure of your upstream links you're always guaranteed that the flow is still e coming in bidirectionally it's coming in from the layer 3 core it's coming across the vbc peer link once you receive that then you can continue to forward it down towards the the member ports and this is actually the default behavior here so I believe that you can change this so let's say I ppm in global pre-build SBT so if we show let's show I ppm show I ppm interfaces and let's see where can we tell if this feature is on or not let's say let's configure it i ppm rebuild SPT show run include PIM this is another optimization of the of the reception so again the the goal here is that we're trying to join the shortest path tree even if we don't have receivers yet so that if there is a failure if there's a change in the roles of the VPC peers we can continue to forward the traffic without having to rejoin which is going to cause the extra latency so as you can see it configuration wise there's really not much that goes along with it other than just your normal layer 3 multicast routing so we said feature PIM we said IP p.m. sparse mode at the interface level we said IPP MRP address the rendezvous points loopback I needed to make sure that Tim was actually on there for it to accept the registration messages but beyond that the behavior of the V PC basically everything is taking care of us taking care for us behind the scenes yeah but the big design change here we need to keep in mind is that the VP CP R link is used in the data plane for multicast so depending on the amount of streams that you have you would have to add up the aggregate bandwidth of all streams and then take that into account of the sizing of the bandwidth of the VP CP R link okay we have a couple questions here why do I keep using the 5k 4-layer through to only 5k can do layer 3 right is this to facilitate VPC and fabric path easier the reason why is just that we don't have the layer 3 daughter cards installed so if they did have the layer 3 modules you could use those as the as your layer 3 gateway but in this case without the the module then it's not going to it's not gonna be able to route there's a question can we disabled this peer link multicast behavior example if I do some if I designed V PC with no orphan ports I don't believe that you can disable it but what you may actually be able to do is to stop it in the data plane so it's possible you may be able to apply a filter I haven't tried that oh I'll have to check it out because normally you wouldn't want to apply a filter to the peer link because it's used for synchronizing the control plane and then that additional necessary data plane but theoretically you could say I want to make this the multicast boundary for anything that is not link-local multicast so I could say allow to 2400 / 24 but then to disallow anything beyond that which would be your normal data plane multicast and then that would stop the replication of it over it whether you would want to do that probably not because the the design of it by default is to try to protect against the failures and then to be able to service the other orphan ports so if there is a failure in one of your V PC members becomes an orphan port basically means that you would not be able to receive the the multicast traffic okay any other questions on anything that we've talked about today up until this point there's a question here without an EM card is it possible to create an S VI interface yes you can create one but you can't actually route traffic because there's no a6 in order to actually do the proxy routing on your behalf so I think it will allow you to create it but then you can't actually do anything in the in the data plane you [Music]

Channel: IT-TALK IT-TALK

Views: 1,551

Keywords:

Id: 6hSa_yKEJGo

Length: 82min 5sec (4925 seconds)

Published: Thu Nov 29 2018