Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Downs't watch on MTU change #1601

Closed
nevzorofff opened this issue Jan 6, 2018 · 5 comments
Closed

Downs't watch on MTU change #1601

nevzorofff opened this issue Jan 6, 2018 · 5 comments
Assignees
Labels

Comments

@nevzorofff
Copy link

I use MPD daemon to make VPN links, an don inactive or non existend interfaces ospfd use MTU=1500 bytes. When links up MTU changes to different value, but ospfd uses 1500 and we get MTU mismatch on other side.

@rwestphal rwestphal self-assigned this Jan 11, 2018
@rwestphal
Copy link
Member

Given the other issue you opened I assume you're using FreeBSD.

I can not reproduce this problem here using FreeBSD 11.1. zebra is able to detect MTU changes and notify the client daemons about them. Please take a look:

bash:

root@freebsd:~ # ifconfig em1 mtu 1600
root@freebsd:~ # ifconfig em1 mtu 1500

ospfd log file:

2018/01/11 10:16:55 OSPF: Zebra: Interface[em1] state update speed 1000 -> 1000, bw  0 -> 0
2018/01/11 10:16:56 OSPF: Zebra: Interface[em1] state update speed 1000 -> 1000, bw  0 -> 0
2018/01/11 10:16:56 OSPF: Zebra: Interface[em1] MTU change 1500 -> 1600.

2018/01/11 10:17:01 OSPF: Zebra: Interface[em1] state update speed 1000 -> 1000, bw  0 -> 0
2018/01/11 10:17:01 OSPF: Zebra: Interface[em1] MTU change 1600 -> 1500.

Please provide more details about the OS version you're using and if the problem is specific to PPP links or if it also happens for ethernet interfaces.

@nevzorofff
Copy link
Author

nevzorofff commented Jan 12, 2018 via email

@bisdhdh
Copy link
Member

bisdhdh commented Aug 9, 2018

  @nevzorofff
 
I tried verifying this behaviour with two FRR virtual routers(running FRR master 5.2 ), connect via two different ip4 links. I had let the adjacency  come up in both the links.
 

R1(config)# do show ip ospf neighbor 
 
Neighbor ID     Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
10.10.10.34       1 Full/Backup       34.199s 192.168.1.9     ens192:192.168.1.8       0     0     0
10.10.10.34       1 Full/DR           36.224s 10.10.10.34     ens224:10.10.10.33       0     0     0
 
 
R2(config)# do show ip ospf neighbor 
 
Neighbor ID     Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
10.10.10.33       1 Full/DR           39.798s 192.168.1.8     ens192:192.168.1.9       0     0     0
10.10.10.33       1 Full/Backup       38.056s 10.10.10.33     ens224:10.10.10.34       0     0     0

 
  
After that I played with the MTU i.e changed it from 1500 -> 1600. I saw ospf at the other end could detect the change in MTU and adjacency was torn down.

root@R2:~# ifconfig ens192
ens192    Link encap:Ethernet  HWaddr 00:50:56:96:c1:6d  
          inet addr:192.168.1.9  Bcast:192.168.1.31  Mask:255.255.255.224
          inet6 addr: fe80::250:56ff:fe96:c16d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:96 errors:0 dropped:307 overruns:0 frame:0
          TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8182 (8.1 KB)  TX bytes:3708 (3.7 KB)

 

root@R2:~# ifconfig ens192 mtu 1600
 
R2(config)# 
R2(config)# do show ip ospf neighbor 
 
Neighbor ID     Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
10.10.10.33       1 ExStart/DR        37.704s 192.168.1.8     ens192:192.168.1.9       0     0     0
10.10.10.33       1 Full/Backup       39.642s 10.10.10.33     ens224:10.10.10.34       0     0     0

 

Aug  9 01:15:08 dev ospfd[31173]: Packet[DD]: Neighbor 10.10.10.34 MTU 1600 is larger than 
[ens192:192.168.1.8]'s MTU 1500
Aug  9 01:16:58 dev ospfd[31173]: message repeated 22 times: [ Packet[DD]: Neighbor 10.10.10.34 
MTU 1600 is larger than [ens192:192.168.1.8]'s MTU 1500]
Aug  9 01:17:01 dev CRON[31682]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug  9 01:17:03 dev ospfd[31173]: Packet[DD]: Neighbor 10.10.10.34 MTU 1600 is larger than [ens192:192.168.1.8]'s MTU 1500
 
R1(config)# 
R1(config)# do show ip ospf neighbor 
 
Neighbor ID     Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
10.10.10.34       1 ExStart/Backup    35.062s 192.168.1.9     ens192:192.168.1.8       0     0     0
10.10.10.34       1 Full/DR           35.026s 10.10.10.34     ens224:10.10.10.33       0     0     0
 
R1(config)# 

Now changing the MTU back from 1600 to 1500 and the adjacency is back.

root@R2:~# ifconfig ens192 mtu 1500
 
 
R1(config)# Aug  9 01:18:48 dev ospfd[31173]: message repeated 21 times: [ Packet[DD]: Neighbor 
10.10.10.34 MTU 1600 is larger than [ens192:192.168.1.8]'s MTU 1500]
Aug  9 01:18:58 dev ospfd[31173]: SPF Processing Time(usecs): 101
Aug  9 01:18:58 dev ospfd[31173]: #011    SPF Time: 73
Aug  9 01:18:58 dev ospfd[31173]: #011   InterArea: 1
Aug  9 01:18:58 dev ospfd[31173]: #011       Prune: 1
Aug  9 01:18:58 dev ospfd[31173]: #011RouteInstall: 18

 
R1(config)# 
R1(config)# do show ip ospf neighbor 
 
Neighbor ID     Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
10.10.10.34       1 Full/Backup       39.047s 192.168.1.9     ens192:192.168.1.8       0     0     0
10.10.10.34       1 Full/DR           33.494s 10.10.10.34     ens224:10.10.10.33       0     0     0

 
 

R1(config)# do show version 
FRRouting 5.1-dev-MyOwnFRRVersion-g06a5959 (R1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
This is a git build of frr-5.1-dev-320-g06a5959
Associated branch(es):
       local:master
       github/frrouting/frr.git/master
 
configured with:
     '--prefix=/usr' '--enable-exampledir=/usr/share/doc/frr/examples/' '--localstatedir=/var/run/frr' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--enable-pimd' '--enable-watchfrr' '--enable-ospfclient=yes' '--enable-ospfapi=yes' '--enable-multipath=64' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' '--enable-rtadv' '--enable-fpm' '--enable-systemd=yes' '--with-pkg-git-version' '--with-pkg-extra-version=-MyOwnFRRVersion'
R1(config)# exit
R1# 
R1# exit
root@dev:/var/log/frr# uname -a
Linux dev 4.4.36-nn3-server #nn3 SMP PREEMPT Thu Apr 13 08:23:18 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux

 
 
Everything looks fine to me. Let me know if we are in the same page !

@qlyoung qlyoung added ospf question Not a bug labels Apr 17, 2019
@qlyoung
Copy link
Member

qlyoung commented Apr 17, 2019

Looks like it works, reopen if not

@qlyoung qlyoung closed this as completed Apr 17, 2019
@nevzorofff
Copy link
Author

FreeBSD 12.2-RELEASE-p4 and frr7-7.5_1 — same problem

d# sh ip ospf interface
ng1 is up
ifindex 10, MTU 1500 bytes, BW 0 Mbit <UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST>

ifconfig:
ng1: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1400
inet 192.168.199.1 --> 192.168.199.5 netmask 0xffffffff
inet6 fe80::2e0:f4ff:fe1e:2839%ng1 prefixlen 64 scopeid 0xa
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants