cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2563
Views
10
Helpful
7
Replies

OSPF Multicast address

I was doing a small OSPF Lab in GNS3 with three routers in a single broadcast domain R1 (Router id 1.1.1.1 )is Drother, R2(2.2.2.2) is BDR and R3(3.3.3.3) is DR.

Now what i know is DR will lisen to Multicast IP 224.0.0.6 and will send the updates to others on Multicast IP 224.0.0.5

But my output is wierd when iam lloking in to ospf debug packets in R1 (DROTHER)

It is sending hello on 224.0.0.5 I am unable to get it. Somebody out there can u help me better understand this

R1#debug ip ospf events

R1#
*Mar  1 00:28:46.891: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#
*Mar  1 00:28:48.579: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:28:48.583: OSPF: End of hello processing
R1#
*Mar  1 00:28:53.467: OSPF: Rcv hello from 3.3.3.3 area 0 from FastEthernet0/0 132.1.1.3
*Mar  1 00:28:53.471: OSPF: End of hello processing
R1#
*Mar  1 00:28:56.103: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#
*Mar  1 00:28:58.071: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:28:58.075: OSPF: End of hello processing
R1#
*Mar  1 00:29:02.615: OSPF: Rcv hello from 3.3.3.3 area 0 from FastEthernet0/0 132.1.1.3
*Mar  1 00:29:02.619: OSPF: End of hello processing
R1#
*Mar  1 00:29:05.867: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#
*Mar  1 00:29:07.435: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:29:07.439: OSPF: End of hello processing
R1#
*Mar  1 00:29:12.267: OSPF: Rcv hello from 3.3.3.3 area 0 from FastEthernet0/0 132.1.1.3
*Mar  1 00:29:12.267: OSPF: End of hello processing
R1#
*Mar  1 00:29:15.039: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#
*Mar  1 00:29:17.371: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:29:17.375: OSPF: End of hello processing
R1#
*Mar  1 00:29:21.711: OSPF: Rcv hello from 3.3.3.3 area 0 from FastEthernet0/0 132.1.1.3
*Mar  1 00:29:21.715: OSPF: End of hello processing
R1#
*Mar  1 00:29:24.227: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#
*Mar  1 00:29:26.767: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:29:26.771: OSPF: End of hello processing
R1#
*Mar  1 00:29:31.291: OSPF: Rcv hello from 3.3.3.3 area 0 from FastEthernet0/0 132.1.1.3
*Mar  1 00:29:31.295: OSPF: End of hello processing
R1#
*Mar  1 00:29:33.563: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#
*Mar  1 00:29:35.911: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:29:35.911: OSPF: End of hello processing
R1#
*Mar  1 00:29:40.799: OSPF: Rcv hello from 3.3.3.3 area 0 from FastEthernet0/0 132.1.1.3
*Mar  1 00:29:40.803: OSPF: End of hello processing
R1#
*Mar  1 00:29:42.587: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#
*Mar  1 00:29:45.007: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:29:45.011: OSPF: End of hello processing
R1#
*Mar  1 00:29:50.411: OSPF: Rcv hello from 3.3.3.3 area 0 from FastEthernet0/0 132.1.1.3
*Mar  1 00:29:50.415: OSPF: End of hello processing
R1#
*Mar  1 00:29:52.191: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#
*Mar  1 00:29:54.067: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:29:54.071: OSPF: End of hello processing
R1#
*Mar  1 00:29:59.847: OSPF: Rcv hello from 3.3.3.3 area 0 from FastEthernet0/0 132.1.1.3
*Mar  1 00:29:59.851: OSPF: End of hello processing
R1#
*Mar  1 00:30:01.271: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#
*Mar  1 00:30:03.279: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:30:03.283: OSPF: End of hello processing
R1#
*Mar  1 00:30:09.591: OSPF: Rcv hello from 3.3.3.3 area 0 from FastEthernet0/0 132.1.1.3
*Mar  1 00:30:09.595: OSPF: End of hello processing
R1#
*Mar  1 00:30:11.003: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#
*Mar  1 00:30:13.079: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:30:13.083: OSPF: End of hello processing
R1#
*Mar  1 00:30:19.259: OSPF: Rcv hello from 3.3.3.3 area 0 from FastEthernet0/0 132.1.1.3
*Mar  1 00:30:19.263: OSPF: End of hello processing
*Mar  1 00:30:20.107: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#
*Mar  1 00:30:22.539: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:30:22.543: OSPF: End of hello processing
R1#
*Mar  1 00:30:29.103: OSPF: Rcv hello from 3.3.3.3 area 0 from FastEthernet0/0 132.1.1.3
*Mar  1 00:30:29.107: OSPF: End of hello processing
*Mar  1 00:30:29.471: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#
*Mar  1 00:30:32.323: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:30:32.327: OSPF: End of hello processing
R1#
*Mar  1 00:30:38.679: OSPF: Rcv hello from 3.3.3.3 area 0 from FastEthernet0/0 132.1.1.3
*Mar  1 00:30:38.683: OSPF: End of hello processing
*Mar  1 00:30:38.703: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1
R1#u
*Mar  1 00:30:42.199: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 132.1.1.2
*Mar  1 00:30:42.203: OSPF: End of hello processing
R1#u all
All possible debugging has been turned off
R1#sh ip ospf ne
R1#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/BDR        00:00:38    132.1.1.2       FastEthernet0/0
3.3.3.3           1   FULL/DR         00:00:35    132.1.1.3       FastEthernet0/0

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."       

1 Accepted Solution

Accepted Solutions

Thanveer,

I'm not sure if there's any  OSPF debug command that shows the AllDRouter address in it's output.

But since it's gns3 and not a production network we can use debug ip packets:

R1(config)#access-list 100 permit ip any host 224.0.0.6

R1#debug ip packet 100

R1#debug ip ospf adj

Now we could wait for reliable flooding or just create a new OSPF link to trigger an update.

*Mar  1 00:40:34.211: OSPF: Interface Loopback0 going Up

*Mar  1 00:40:34.711: IP: s=132.1.1.1 (local), d=224.0.0.6 (FastEthernet0/0), len 96, sending broad/multicast

*Mar  1 00:40:34.715: OSPF: Build router LSA for area 0, router ID 1.1.1.1, seq 0x80000004

*Mar  1 00:40:34.779: OSPF: Rcv LS UPD from 3.3.3.3 on FastEthernet0/0 length 76 LSA count 1

*Mar  1 00:40:42.371: OSPF: Rcv LS UPD from 3.3.3.3 on FastEthernet0/0 length 64 LSA count 1

*Mar  1 00:40:44.875: IP: s=132.1.1.1 (local), d=224.0.0.6 (FastEthernet0/0), len 64, sending broad/multicast

Another way with gns3 is to use Wireshark.

Hope that helps

Rolf

View solution in original post

7 Replies 7

Rolf Fischer
Level 9
Level 9

Hi,

the OSPF network types differ in

  1. Neighbor discovery and maintenance
  2. Database synchronization
  3. Representation in the LSDB

(1) is achieved by exchanging Hello packets. In a broadcast network every Router send a single Hello which is received by all the other routers, resulting in n/2 * (n-1) neighbor relationships.

2), is achieved with the other 4 packet types. The way it is done in a broadcast (nor NBMA) network has to be more efficient than the neighbor discovery and maintenance. That's why a DR/BDR is elected in order to transform the topology for the updating process in something like a logical Hub-and-Spoke with the DR as hub. With the BDR (for redundancy if the DR fails), the adjacencies are reduced to 2n-1.

(Note that neighbor relationships and adjacencies are two different things.)

The AllDRouters Address (224.0.0.6) is used for DB sync only, not for neighbor discovery/maintenance.

Does that clarify the debug output you're seeing?

Regards

Rolf

Thanks Fischer,

yes half of my mind is free but still the other half is struggling.

I have seen the debug out output while  routers building the neighbor relationship but I was unable to see 224.0.0.6 ip in the debug out put infact it is saying

R1#

*Mar  1 02:34:25.731: OSPF: Send UPD to 132.1.1.3 on FastEthernet0/0 length 52 LSA count 1

*Mar  1 02:34:25.767: OSPF: Rcv LS UPD from 3.3.3.3 on FastEthernet0/0 length 76 LSA count 1

*Mar  1 02:34:26.291: OSPF: Rcv LS UPD from 3.3.3.3 on FastEthernet0/0 length 76 LSA count 1

*Mar  1 02:34:26.311: OSPF: Rcv LS UPD from 3.3.3.3 on FastEthernet0/0 length 64 LSA count 1

*Mar  1 02:34:27.527: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 132.1.1.1

R1#

R1#

Why am I not seeing 224.0.0.6 IP in the debug output

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

Thanveer,

I'm not sure if there's any  OSPF debug command that shows the AllDRouter address in it's output.

But since it's gns3 and not a production network we can use debug ip packets:

R1(config)#access-list 100 permit ip any host 224.0.0.6

R1#debug ip packet 100

R1#debug ip ospf adj

Now we could wait for reliable flooding or just create a new OSPF link to trigger an update.

*Mar  1 00:40:34.211: OSPF: Interface Loopback0 going Up

*Mar  1 00:40:34.711: IP: s=132.1.1.1 (local), d=224.0.0.6 (FastEthernet0/0), len 96, sending broad/multicast

*Mar  1 00:40:34.715: OSPF: Build router LSA for area 0, router ID 1.1.1.1, seq 0x80000004

*Mar  1 00:40:34.779: OSPF: Rcv LS UPD from 3.3.3.3 on FastEthernet0/0 length 76 LSA count 1

*Mar  1 00:40:42.371: OSPF: Rcv LS UPD from 3.3.3.3 on FastEthernet0/0 length 64 LSA count 1

*Mar  1 00:40:44.875: IP: s=132.1.1.1 (local), d=224.0.0.6 (FastEthernet0/0), len 64, sending broad/multicast

Another way with gns3 is to use Wireshark.

Hope that helps

Rolf

Thanks Buddy

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

You're welcome!

And thanks for the ratings and marking as resolved.

Regards,

Rolf

Just for the sake of correctness:

the adjacencies are reduced to 2n-1

I found this formula in John Moy's "Anatomy of an Internet Routing Protocol", which is a great book but I think this formula is wrong.

The DR has n-1 adjacencies and the BDR has n-1 adjacencies too, but one is common  between DR-BDR, so we have (n-1)+(n-1)-1 = 2n-3.

Best regards

Rolf

Thanks Again Dude

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco