Point-to-Point Microwave Connections cannot ping each other

[Adcom911]

Edit: issue was not related to networking. The MW interfaces where missing some settings. Problem solved!

Hello,

I have a particular situation where we have Two routers one being a 8300 and one a 2911 not able to ping each other their point-to-point Microwave connections. They can see each other via CDP neighbors but weirdly can't pin across the link to the other side. Any suggestion or help will be greatly appreciated!

8300 config

interface GigabitEthernet0/0/1
description 8300-2911 MW
bandwidth 318000
ip flow monitor NTAMonitor input
no ip address
negotiation auto
end
!
interface GigabitEthernet0/0/1.299
description 8300 MW-To-2911 Vlan 299
encapsulation dot1Q 299
ip address 10.1.4.34 255.255.255.248
ip ospf network point-to-point
mpls ip
service-policy output QOS-SHAPE
end

2911 config 

interface GigabitEthernet0/2
description 2911-8300 MW
bandwidth 318000
no ip address
ip flow monitor NTAMonitor input
duplex auto
speed auto
end

!
interface GigabitEthernet0/2.299
description 2911 -to- 83000 vlan 299
encapsulation dot1Q 299
ip address 10.1.4.33 255.255.255.248
ip ospf network point-to-point
mpls ip
service-policy output QOS-SHAPE
end

[Giuseppe Larosa]

Hello @Adcom911 ,

give it a try without the 802.1Q tag 299 because CDP frames are going through the RF link

remove the ip address on the subinterfaces and move them under the main interface ( untagged)

Hope to help

Giuseppe

[Adcom911]

This might have done it!! or at least partial way. I was able to ping across the link. But as soon as I moved the sub int face ip to the main int on the 2911 I lost managment connection and it took down some our radio network. So there may be a clue in that i gotta look at when I get home.

OSPF neighborship and ping worked so we are closer with this suggestion. So just gotta see why moving that IP over to the main interface broke it. BUT THANK YOU SO MUCH THERE IS DAYLIGHT NOW AT THE END OF THIS LINK OR TUNNEL HAHAH ty so much!! 

[Giuseppe Larosa]

Hello @Adcom911 ,

this is good news.

The best next steps are the following :

a) use a new subnet under the main interfaces so that you can build IP connectivity over the RF link with OSPF on it.

b) on the C2911 use a different subnet under the subinterface .299 and have it advertised over OSPF on the main interface. If it is easier for you , you can change the subnet under subinterface .299 on the Cat8300 side. The reason is that tagged frames cannot travel on the RF link.

As an alternative to what I have suggested above contact the RF vendor / sysrtem integrator and inform them of your findings i.e. only untagged frames go over the RF link.The devices may have some configuration options to allow tagged frames over the RF link.

Hope to help

Giuseppe

[Adcom911]

Hey @Giuseppe Larosa Thanks for the suggestions. We got with the vendor and had the 299 vlan removed from the Rf links. We moved the sub interface and everything to the main interface and still are not getting across. Would you suggest we change one sides subnet? 

[Giuseppe Larosa]

Hello @Adcom911 ,

>> We got with the vendor and had the 299 vlan removed from the Rf links. We moved the sub interface and everything to the main interface and still are not getting across. Would you suggest we change one sides subnet? 

No at this point, I would rollback re-adding the subinterface with VLAN ID 299 and I would use a different subnet under each .299 subif because you have seen that tagged frames cannot travel over the RF link.

And I would have a common IP subnet untagged under the main interface that will be used for OSPF adjacency in the hope to restore IP connectivity in previous scenario.

We don't know how these RF devices work the tagged subif may be needed for example to manage them.

Hope to help

Giuseppe

[Joseph W. Doherty]

I'm wondering if it's some possible MTU issue, or framing issue, due to your .1q and MPLS settings.  Either on a Cisco device or the MW.

CDP might not add .1q or MPLS tags, to frame.

[Adcom911]

Ahh good thought let me speak to the radio team and see if the MTU's need to be adjusted. They are both 1500 on both sides. 

[Joseph W. Doherty]

BTW, reason I'm only suggesting MTU being a possible issue, such issues are normally only see near MTU.  For example, you can ping fine until ping size gets up to exceeding about 1492.

I'm this case, I'm thinking more along the lines that some device is "confused" with a .1q and MPLS tag, or just a MPLS tag.

[Adcom911]

Thanks for the suggestion. I played around with ping sizes and they all failed. So crossing off MTU as the possible issue 

[Joseph W. Doherty]

---

@Adcom911 wrote:

Thanks for the suggestion. I played around with ping sizes and they all failed. So crossing off MTU as the possible issue 

---

Not really a surprising result, because what you've described, as I described, should only be a problem as you approached MTU.

For giggles sake, just added this:

interface GigabitEthernet0/0.10
encapsulation dot1Q 10
ip address 192.168.10.2 255.255.255.0
mpls ip

to one of my CML labs and across a "copper" Ethernet:

Initial CDP result:

*Aug 27 16:37:03.752: %LDP-5-NBRCHG: LDP Neighbor 192.168.2.1:0 (1) is UP
inserthostname-here#
*Aug 27 16:37:05.225: %SYS-5-CONFIG_I: Configured from console by console
inserthostname-here#sh cdp n
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone, 
                  D - Remote, C - CVTA, M - Two-port Mac Relay 

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
inserthostname-here
                 Gig 0/0           56               R B             Gig 0/0.10
inserthostname-here
                 Gig 0/0           177              R B             Gig 0/0

Total cdp entries displayed : 2

but then:

inserthostname-here#sh cdp n
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone, 
                  D - Remote, C - CVTA, M - Two-port Mac Relay 

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
inserthostname-here
                 Gig 0/0           139              R B             Gig 0/0

However I can ping other side's main for subinterace IPs.

What does your working CDP show?

[Adcom911]

Weird it as well only sees it from the main interface and no sub interface....

[paul driver]

Hello
can the rtrs ping themselves?
Any chance of duplicate addressing?
if you shut those interfaces down do you see a rib entry for the subnet?

sh ip cef 10.1.4.32/29
sh ip route | in 10.1.
sh run | sec router

if applicable initiate a debug to see if you have any acl filtering or encapsulation failures

ip access-list 100 permit ip host 10.1.4.33 host 10.1.4.34
debug ip packet detail 100

[Adcom911]

Hey @paul driver, Thanks for the suggestions! 

Yes, the Router can ping its self, it can ping the MW's attached and the interface its on. Just not across the link. I dont think there is a chance of duplicate IP's as the router that had the previous MW hop is sitting on my desk decommissioned. Shut the port down and it learns that subnet via ospf.

show ip cef shows them both connected on the sub interface as well 

Tried the ACL and got nothing from that so doesnt look to be that 

Also wild so I know its not the routing it can reach the other side via ospf when I shut down the subinterface. So in conclusion it really has to be something wrong with the RF links 

[paul driver]

Hello

---

@Adcom911 wrote:
 not able to ping each other their point-to-point Microwave connections. 

Shut the port down and it learns that subnet via ospf.

---

Now Im confused,  how can it be learned via ospf and be reachable when you have shutdown the associated ospf P2P subinterfaces,, the ospf peering will have been torn down also?

 Maybe you could share a topology diagram?

[Adcom911]

Hey @paul driver , We have a sort of ring topology mixed with Fiber and MW p2p links. So its taking a mix of Fiber and MW around the ring to reach it. I can PM a topology to explain