NBMA OSPF Ethernet segment's line protocol not coming up - Any Ideas?

I have an NBMA network that I am trying to add an OSPF Area off a spoke router, R3, that's Serial interface Priority is set to 0 so the Hub is the DR. I then tried adding a segment off of R3, and I am seeing on both sides the interface is up/down, and I cannot for the life of me figure this out.

I in the output of show ip ospf int x/x that there is no DR / BDR, and I am wondering if that is why it is down?

R4#show ip ospf int fa0/0
FastEthernet0/0 is up, line protocol is down
Internet Address 172.12.34.4/24, Area 34, Attached via Network Statement
Process ID 1, Router ID 4.4.4.4, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Transmit Delay is 1 sec, State DOWN, Priority 1
No designated router on this network
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
R4#
ASR#3
[Resuming connection 3 to r3 ... ]

R3#show ip ospf int fa0/0
FastEthernet0/0 is up, line protocol is down
Internet Address 172.12.34.3/24, Area 34
Process ID 1, Router ID 3.3.3.3, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DOWN, Priority 1
No designated router on this network
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40

R3 has an interface in Area 0, on both routers I have "network 172.12.34.0 0.0.0.255 area 34" in the OSPF configuration, and I verified that R3's WAN interface does at least see the DR / Hub:

R3#show ip ospf int s0/2
Serial0/2 is up, line protocol is up
Internet Address 172.12.123.3/24, Area 0
Process ID 1, Router ID 3.3.3.3, Network Type NON_BROADCAST, Cost: 64
Transmit Delay is 1 sec, State DROTHER, Priority 0
Designated Router (ID) 1.1.1.1, Interface address 172.12.123.1
No backup designated router on this network
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
oob-resync timeout 120
Hello due in 00:00:06
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 1.1.1.1 (Designated Router)
Suppress hello for 0 neighbor(s)

Why on Earth is this not working? Any help in understanding this is greatly appreciated!

OSPF_R3toR4.jpg

Find more posts tagged with

Comments

ande0255

Not sure if I glossed over this point in my studies, but from what I read Broadcast sections depend on the DR/BDR hierarchy, whereas my Serial NBMA network or point-to-point / multipoint-to-point links do not.

Not sure if Ethernet can be sub-interfaced to be made to work as I am too fried to even turn my rack back on at this point, but I think that is the official cause of the issue (I hope), one of those simple concepts that can be glossed over without labbing your *ss off.

x_x go me wooo

networker050184

OSPF doesn't have anything to do with your interface being down.

ande0255

Yes that is starting to sink in that I will need to check the cabling type between the two devices. I thought initially I'd need a switch between the two for an ethernet segment, but I have another router in Area 0 off of R1's FastEthernet with no intermediary device, and that is having no issues coming up router to router via ethernet cable.

After throwing some different interface level commands at it and it not changing a thing today, back to layer 1 I go once I have time to get my hands dirty.

Simrid

I would recommend running some debug commands. Debug command should enable you to dig a little deeper.

ande0255

Thanks for the response, I am betting after doing some research that it's the cabling being used, as I've only really worked with Serial interfaces to connect routers in my home lab so I'm not used to an Up/Down interface unless there is an encapsulation issue.

I will try the cable that is connecting R1 to R5 successfully over FastEthernet, and if that is a success, then we have our culprit - I shall report back!

ande0255

How embarrassing, it was a bad / incorrect cable, I had thought I tested it but I must not have. So easy to forgot that physical layer when you are working with a physical lab.

dppagc

One very elementary question which I dont understand.
If it was a physical issue shouldnt it be down/down instead?

The first one is physical and the second one is line protocol right?

joetest

it depends on the error. If no signal could get through then yes it would be down/down. But if he had plugged the cable in the wrong slot or whatever the other side would show as up assuming it worked.

I.e. if he had plugged a cable into 2 serial ports with different encapsulations(PPP vs HDLC) it would still show as UP/Down.

ande0255

dppagc wrote: »

One very elementary question which I dont understand.
If it was a physical issue shouldnt it be down/down instead?

The first one is physical and the second one is line protocol right?

I also thought this would be the case from the materials I've studied, and of course my lab work, but upon digging I found some discussions regarding this state.

It seems that Serial interfaces will show down/down if the cabling is unplugged, but you can't really get a serial cable type wrong to my knowledge, as the connectors pin #'s would make that hard if not possible at all. And if a clock rate is not set, or as mentioned above the encapsulation is incorrect, then it would show Up/Down indicating that Layer 1 is ok and you need to troubleshoot up the OSI.

In the case of Ethernet, I believe it detects the cable cause the RJ-45 connector is universal across several cable types, but because of the incorrect cable type it cannot communicate properly indicating a non-physical issue (even though to resolve it you need to correct the cable type which is a physical cabling fix).

I am glad I held onto this 1 ton lab of routers and switches now, the things I am learning (and learning that I overlook) working on it is really helping with learning things beyond just course content to pass the CCNP... if I do pass it

dppagc

Just out of curiosity, what type of cable did you use before and after?
What exactly was the mistake made?

ande0255

I had what appeared to be a rollover cable, as the colors were exact opposite when comparing connectors head to head, I was comparing different cable colors when I found the random crossover pattern I remember from physically labbing a very long time ago.

Once I plugged in the crossover, immediately Up/Up, and OSPF kicked in right away working as expected.

james43026

Ahh yes, you have experienced the troubles of the ethernet loopback frame, failing to find it's way back to the originating device, thus causing the devices to not be able to bring the protocol up. In the real world, you won't usually have an issue with this, on newer equipment, 100% won't experience any issues like this on full gig links and above in the world of ethernet. As newer equipment will usually have auto MDIX on all ports, and anything full gig and above are required to have auto MDIX support.

dppagc wrote: »

One very elementary question which I dont understand.
If it was a physical issue shouldnt it be down/down instead?

The first one is physical and the second one is line protocol right?

On a router, you will almost always see an ethernet interface as up/down, when nothing is connected to the port, as long as it is administratively up. The status has a different meaning on a router, it doesn't just mean that the physical layer is able to send NLP or FLP across the link, like it would for a switch. For a router it literally only determines if the port is shutdown or not. The protocol is what will tell you if there is either a physical or layer 2 issue going on. I know it's strange, but the ethernet loop frame tests and proves that a device can both send and receive at both layer 1 and layer 2.

This ethernet loop mechanism is actually called the configuration testing protocol. It's basically the layer 2 equivalent of a ping test, but it essentially says, hey, if you get this frame, send it back to me please. I should also say that these packets aren't really explained in great detail. They have the same MAC for the source and destination. And by default a switch would drop such a frame. Cisco isn't clear on exactly how it works, as they simply state that the packet is sent onto the wire, and that it somehow receives it back immediately, which would require something to send it back, as it is supposed to confirm that the router can both send and receive, and without a device sending the packet back, this simply wouldn't work. The internet yields very little information on the subject as well. If anyone has any additional information that would be great. When playing around with this, you clearly only see the keepalives send out once form the originating device, and you never see a real reply from another device. This leaves me to assume that Ciscos description is incorrect, and that a router only uses this mechanism to send packets, just to test that an electrical circuit is open, and that bits can be passed over the link, and as long as it can send, it assumes that it can receive as well. As two routers directly connected do not seem to even see these packets from one another. I'm going to try modifying an ethernet cable to only have transmit pins on one side of the link, and receive pins on the other side. I'm then going to check if at least one side of the link between two routers will come up.

Update: After doing a quick test in GNS3, not home to do testing with lab equipment. With two routers directly connected, I do see the loop frames from both devices from a wireshark capture on a single router interface. But when multiple routers are connected to the same switch, they do not see eachothers loop frames, as expected the switch does not forward them. Which further leads me to believe that these packets are used to only confirm that a device can send.