I am trying to get a PtMP network type running along side an existing broadcast network. I have a collection of routers connected to a VPLS service and all participating in vlan 80, network type broadcast. This is problematic if a random VC between a pair of routers decides to break within the VPLS, so PtMP would be more appropriate.
The problem is, I am having a heck of a time getting certain routers to form an adjacency and keep it. The issue appears to be related to the fact that PtMP advertises /32 routes for the IP on the PtMP interface. This /32 route is then chosen over the connected route and routed out the vlan 80 interface. I'm not really sure why this is breaking it, as I know hellos/lsas are multicast on the interface, not unicasted to the IP. But you can see below in debugging that the routers end up hearing OSPF packets on the vlan 80 sub-if that originated from the vlan 69 sub-if, and complains.
Below is config between two ASR1002 routers running 15.2(4)S2. The neighborships come up on Gi0/0/0.69 then later fail. This continually happens. Note that these 2 ASRs are connected directly between a switch and this adjacency is not even trying to formed across the VPLS service. I am simply trying to get 2 vlans, one broadcast and one ptmp, running between eachother across a switch. I labbed this up between a couple 2821s and I can't get the same behavior...
There is no MTU mismatch and full size packets work fine:
ip route 10.1.50.15 255.255.255.255 Gi0/0/0.69 // this is for over-riding ospf's /32 and routing over vlan 80 so we can ping across the 69 sub-interface itself
#ping 10.1.50.15 size 5000 df-bit Type escape sequence to abort. Sending 5, 5000-byte ICMP Echos to 10.1.50.15, timeout is 2 seconds: Packet sent with the DF bit set !!!!!
encapsulation dot1Q 69
ip address 10.1.50.14 255.255.255.0
ip mtu 5000
ip ospf network point-to-multipoint
encapsulation dot1Q 80
ip address 10.1.31.7 255.255.255.0
ip ospf priority 224
router ospf 100
no passive-interface GigabitEthernet0/0/0.69
no passive-interface GigabitEthernet0/0/0.80
no passive-interface GigabitEthernet0/0/1.3201
network 10.1.6.96 0.0.0.7 area 0
network 10.1.31.0 0.0.0.255 area 0
network 10.1.50.0 0.0.0.255 area 0
Jun 27 18:29:58.590: OSPF-100 ADJ Gi0/0/0.69: Interface going Up
Jun 27 18:29:58.590: OSPF-100 ADJ Gi0/0/0.69: Interface state change to UP, new ospf state P2MP
Jun 27 18:30:27.825: OSPF-100 ADJ Gi0/0/0.80: Rcv pkt from 10.1.50.15, area 0.0.0.0 : src not on the same network
Jun 27 18:30:27.825: OSPF-100 ADJ Gi0/0/0.69: Rcv DBD from x.x.82.241 seq 0xE37 opt 0x52 flag 0x7 len 32 mtu 5000 state INIT
Jun 27 18:30:27.825: OSPF-100 ADJ Gi0/0/0.69: 2 Way Communication to x.x.82.241, state 2WAY
So I do believe this is a bug in IOS. I am running IOS-XE in this case, verison 03.07.02.S. But I've observed this issue on some older GSRs running IOS 12 as well.
Basically, I have a PtMP network along side a broadcast network between two routers. The PtMP interface should come up and send a multicast OSPF hello to discover any *directly connected* neighbors it has. After it receives replies, it then should know that the sender is adjacent and begin sending unicast OSPF packets *out the connected interface* and ignore the routing table. This isn't what it is doing. It's looking to the routing table and seeing the /32 route being announced via the other broadcast network between the two routers. So what happens is the OSPF packets end up hitting the wrong interface on the other side and are discarded.
Now if we change the PtMP to PtMP non-broadcast so that I can actually tell IOS what it's directly connected neighbors are -- it still mis-behaves. It still looks to the routing table and tries to send OSPF packets across the 'broadcast' network-type interface resulting in the adjacent router discarding those packets thus causing an adjacency to *never* form. As soon as I nail up a static host route to tell IOS that it should use the directly connected interface (ip route 10.1.50.15 255.255.255.255 Gi0/0/0.69) instead, the adjacency immediately forms and stays up.
I replicated this setup in GNS3 and locally with a couple C2821s and I cannot get this same behavior. It works fine. So I think this is a bug affecting some versions of IOS and not others.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...