Right now is.
Yes, my my edges of these are different sites.
Right.
I'll wait.
The sites are talking to each other.
But that's not the point.
What do I want to do?
Think I want to make sure that my private IPS communicate to each other.
How will they do that?
How did I do it in run a routing protocol?
With since the routs that are behind me, I ran a routing protocol.
But there is going to be a small little issue in here.
Let's check what that is if you remember from your routing switching days.
Do you remember this R1, R2, R3, R4, R5.
They're all connected together now through, let's say, a switch.
The address is, say, 192 168 .1.0 slash 24.
This network.
By default, OSPF considers to be an n b a non-broadcast multiaccess network.
In case of IP, this is a simple network.
The problem is not going to be a problem.
The problem is that between R1 and R3 and R2, the mappings that you have there, what dynamic?
Every two hours they'll go down.
That means your neighbor relationship will also go.
Is that feasible?
That's not feasible.
What do I want to do?
I wish to have a static, stable neighbor relationship between all the pairs.
How can I do it?
I'll create neighbors.
All of them will have you as the neighbor because they have a static relationship with.
Right?
Right.
They have a static relationship.
With whom?
So they can create neighbor relationship with R1, which will not go down.
Today the every spoke has a static entry in the addressed to mapping private to public mapping which
says where the R1 where R1 is and then you can send traffic to that guy.
The only one issue is IP sends traffic multicast traffic will be sent out.
192 168.1. let's say from R3 1.3.
What is the destination of this packet going to be?
It's a yellow packet is going to be on 224.
That's okay.
The thing is, on top of this, apply On top of this, I will also apply what sources?
How will you know the destination is exactly.
The problem is earlier when it was 1.1 here, you would go to the table and see 1.1.
The public address is this.
Now, the inside address is, what, 220 400 ten?
It doesn't know what the next hop to reach that guy is from the spoke side.
They don't know what the next hop is to go to 220 400 ten.
I have to manually specify it.
For which I will have to go to the spokes, just like the spooks right now know that the map to go to
192 168 1.1 is 151 dot 16 dot one.
I will also tell him listen and map if you have any multicast address, send it to the public address
of.
Now this will be done on all the spokes so that when it runs it knows where to send the hellos to.
They will all send their hellos.
To whom?
So I'll copy this command and paste this on all the spokes.
Let's go to spoke number three.
Interface Tunnel zero spoke number four.
Finally are two interface channel zero and.
Right now it's VPN until 11.
Then
the summer because they don't have space outside.
Right?
So they came here.
Yeah.
So.
You think that's going to be like that?
Yeah.
All multicast.
Multicast.
You can also write something like this.
You can also say IP.
Yes.
The question is, can I do something like this?
IP Nrhp map 220 400 ten and then specify 151 dot 16 dot one.
Absolutely can.
It should work.
But the problem is you will only be supporting IP.
What if tomorrow you want to run OSPF?
Then you'll have to do 005006.
What if you want to do Rip?
You'll have to.
So we just say multicast because we know they're not going to communicate to each other using multicast.
We just tell them all multicast.
Just go up there to the hub.
Again, another little small little issue on the up side is how does the hub deal with it?
I'm fine.
Yes, I sent from these guys.
I'm sending it to the hub.
The hub needs to reply to all of them.
Who does it send it to?
Who does the hub send it to first?
There is two challenges in this one.
First of all, the addresses are dynamic.
Tomorrow, another hub can come in with a different address.
So I cannot have statically yes, all of them will be pointing to the hub, but the hub has to point
towards everyone.
Everybody else.
Right on the hub.
I'll use this command.
Check this out.
This is very interesting.
I'll go to the hub interface, Channel zero IP and map multicast.
My multicast, the hubs multicast should go to the all people, everybody who has registered to me dynamically.
People who have come up and registered to me dynamically, which are who if you check your IP and all
these addresses, my multicast will be sent all of them separately.
Making sure that from the spokes each of them sends their multicast to the hub.
The hub, in turn, does what sends to all the dynamically learned peers, which is to all of them.
Now you can run your.
How would you.
Not individual Hello packets are not individual.
Same hellos go everywhere.
Hello.
Packet has what information autonomous system number and k values.
That's all right.
Returned to a broadcast multicast address 220 400 ten.
Yes.
So the reply to be to the one who generated the packet, right?
Not.
Yeah, it would be.
It goes to all four.
Who are they replying to if are to generated.
Yeah.
His R2 packet goes where to hop in a normal situation goes in a normal situation if which normal situation.
If there is a switch in the middle you have R1, R2.
Yeah.
I want packet, it goes to the multicast.
Yeah.
And the reply is also a multicast.
R2 is ideally supposed to go.
Not really like that.
What if you have a switch in the middle?
Who's talking?
Question What if you have a switch in the middle and you're running?
We will still send out that one hello, which will be multicast and go to both of them.
It doesn't have to be a reply, right.
So multicast is like a broadcast.
It goes to the switch, it broadcasts out to everybody else.
It's the same way here.
Now here is a little better than that.
Why?
Because the hub will send it to all the dynamic peers.
The dynamic peers will individually reply.
To whom?
To them individually.
Reply back to the hub point to point network goes to to the not to the other.
Not to the other updates go direct updates.
They reply acknowledgement to the what updates is sending.
The acknowledgement is are unicast.
So how would that work Unicast They know already what the mappings are to the hub and he knows what
the mappings are to all the spokes.
That is exactly why I only create the neighbor relationship between the hub and the spokes not spoke
to spoke.
Because the mappings between the hubs and the spokes are resolved.
I will create the neighbors from up to the spokes from one half to all the spokes.
Correct.
Let's run the network.
192168.1.0.
No Auto Summary.
Network.
Ten 000.
Right.
Copy this.
Everywhere.
Same network, right?
Everybody has the same network on 92 168.1..
Network, ten 000, no auto, copy it and paste it on all the guys.
Let's go to R2.
Then neighbor up.
We'll see.
The neighbor is only up from one side, not the others
neighbors.
That's because when you paste, when you are running it, the he sends it from the other one side.
The other guy receives the hello.
He's not sending his own.
Hello.
There is a conflict.
It happens every time you configure it.
It will happen.
The way for it to work is you shut down the tunnel.
From where?
From the hub.
Then on all the spokes.
Correct.
Bring it back from the Hub.
Starting from the hub.
Bring back the tunnel.
So now when someone will register, it will know that he is supposed to send the multicast to him.
It doesn't work before because they have already registered.
So they are already registered.
I don't want them to now.
I want them to register because now I know where to send my dynamic entries to.
Right.
So I'll go here.
I'll say no and I'll wait for them to come here and register.
No, shut.
River relationships will come up on all of them.
Zap.
Zap enables.
So happy neighbor.
Our is not yet.
R4 is R5.
Yes.
Except for R2 because it came up too quickly.
Shut it.
And no, Shut again.
Wait for it.
The registered register itself again.
I have a conflict.
I have two statements saying the same thing.
You could either that one or this one.
Okay, one neighbor is up.
So if you see our one right now, show IP route ten, one, ten, two, ten, three, ten, four, ten,
five.
We'll do this until now.
There is still a small little problem.
Let's do that too.
I have to.
Couple of minutes.
If you check R2 right now and you check your route, you only receive 10.1.
You don't deceive the others.
Why?
The neighbors with are one.
Why is that?
This is from your Ccnp days.
You guys should know this.
Yes, yes, yes, that's it.
Just don't say it.
I want others to see it.
I know you got it.
I have a neighbor with this.
I'm a neighbor with this.
Whatever information I give him, he's supposed to forward to R3.
Whatever information R4 gives him is supposed to forward to R3 and vice versa.
The problem with this part is what they're getting all this information not from different interfaces,
but from the same interface.
They are receiving all the information from the same interface.
What does Split Horizon say?
It says if you receive an update from the same interface, you are not supposed to forward it out back
from the same interface.
So when R1 is receiving the update from R2, he is not forwarding it to R3, but ten .1.1.0 is behind
R1 and it is not receiving it, so he is giving it out to R2, R3 and R4.
So when you go to R2, R3, R4, you will see our 10.1, but you will not see the other updates.
How do I fix it?
Go to Interface Channel zero.
No.
Split Horizon.
Wait for it to sync again.
Sings again.
You go to the Piers Show IP route.
Everything is here.
If you go ten, three, three, three with a source of ten.
Two, two, two.
Done spoke to spoke communication.
This is dmvpn phase one.
Why is it phase one?
Like you know obviously with IPsec is phase one to apply IPsec just apply copy the protection and paste
it everywhere.
It's phase one because the next hop is always what
it will be.
R1 because everybody is learning the routes from R1, so the next hop will always be R1.
That means the traffic will all go through where.
Move back to move back traffic.
It doesn't mean I can still go to 192 168 1.3.
I can still go to 1.4, but I will when I go to 10.1.
10.2.
10.3.
10.4.
Since I learned those addresses from our one, my next stop will always be our one to go to those networks.
So all my traffic will always flow through our one and go to R2.
R3, r4 Dmvpn.
Yes.
Spoke two spoke.
Communication is possible, but everything is going through the hub.
So phase one.
There is to is scope to scope, direct communication.
We'll do that tomorrow and we'll have a small recap of this too.
This was too quick.
Yes.
Yeah.
No, no, no.
That's just the first time.
Just the first time.
If another guy comes in, he registers himself.
It's fine.
Why do you have to shut the tunnel and bring it back up again?
See, when you run for the first time.
Right?
Tries to do what?
Send out multicast addresses.
But the thing is, he already has those people registered.
Could you be more specific?
I to all these public IPS, R2, R3, R4, R5 are registered in the table, right in the table.
So when you run that command, it's difficult for him to go back to the old table and he should have
fresh entries for what is the map multicast command.
Send your multicast traffic to all the dynamically run players, but to the new dynamically learned
players, not the old ones.
It's supposed to work.
It should, but it doesn't.
That's a flaw we already have.
But those are old entries which are before the command.
Either you use the command first and then enter and then let them register, or if you already have
them registered and you're using the command later, then you'll have to make them freshly register
themselves once they're registered.
It should work.
By theory it should, but it doesn't.
There's a design flaw.
Whoever has made it.
He couldn't fix the two communications.
So for it to work, it has to be fresh registrations.
It's not a problem because now if someone else registered, if someone else registers will come.
And this we have an IP we have to run.