# freebsd, pppoe, eigrp problem



## vladi (Nov 21, 2017)

Hello everyone. After 6 months our FreeBSD server was up and the PPPoE connection worked, fine something happened and by then we are unable the get on the internet. We managed to get the PPPoE connection, resolve IP addresses fine, but whenever we try to connect to an internet site we have this error (tracked by tcpdumping the network traffic)

```
11:02:19.194237 IP (tos 0x0, ttl 64, id 13411, offset 0, flags [none], proto ICMP (1), length 56)
    host025.pool82-215-161.xdsl-cust.uno.it > gw-133.uno.it: ICMP igrp-routers.mcast.net protocol 88 unreachable, length 36
   IP (tos 0xc0, ttl 2, id 0, offset 0, flags [none], proto EIGRP (88), length 60)
    gw-133.uno.it > igrp-routers.mcast.net:
        packet exceeded snapshot
```
I do not really know what protocol EIGRP 88 is. Can somebody give me some insight?
Vlad


----------



## PacketMan (Nov 22, 2017)

EIGRP is a routing protocol manufacture by Cisco.  It's more or less proprietary, but I have heard the technology has been licensed to other vendors.  Read more about it here:https://en.wikipedia.org/wiki/Enhanced_Interior_Gateway_Routing_Protocol.  Other routing protocols include OSPF, BGP, just to name two more.

So it looks like you're service provider has EIGRP configured on the port that connects to you.  ISPs usually don't do that as a best practice, unless you and them have made an arrangement.  And even then, usually ISPs use IGPs (internal routing protocols like EIGRP and OSFP) for internal use, and use EGP (external gateway protcols like BGP) to connect with external entities, like you.

So you're interface gets an IP address?  Can you ping other IP addresses inside the subnet? You can use your IP mask to determine subnet size.)  Assuming you can ping that stuff, it sound like (a) you have no route out to the internet.  If you are/were not doing a routing protocol with your ISP then you need a default route statement, and they need a route back to you.  Unless you are doing (RFC1918) private IP addressing on  your LAN, and your server is gateway, then you need NAT. Did you have that running and it broke somehow?  That just said, if your server was the NAT box, it should still be able to use the Internet as it would use its public (WAN) side interface. So I'm thinking your routing with your ISP has broken/changed somehow.


----------



## vladi (Nov 22, 2017)

I was using mpd5 for pppoe. (tried also ppp, same error came through). I get an IP address. I can resolve hostnames no problem... I have nat setup. The system was running full time for 4 months than suddenly it stopped working... I wrote today at the isp, will ask them again to understand this bgp protocol thing... thanks for now! vlad


----------



## SirDice (Nov 22, 2017)

If you get an IP address _and_ you're able to resolve hostnames (this implies a working connection or else you wouldn't be able to resolve anything), then what exactly isn't working?


----------



## PacketMan (Nov 22, 2017)

vladi said:


> I wrote today at the isp, will ask them again to understand this bgp protocol thing... thanks for now! vlad



Unless your network is a big corporate network, 99% of ISPs will not do a routing protocol with you, certainly not BGP. And now that you have told us that you are doing NAT, the use of any routing protocol with them becomes unneeded.  You can ask them why you see EIGRP on the wire. No chance you have a Cisco switch (with EIGRP configured) in path do you, and that EIGRP you see is actually from you?

As SirDice already said, I think we need to better understand what exactly is not working, and I would add, how you think that is a FreeBSD issue?

EDIT - And what is MPD?  Multilink PPP daemon if such a thing exists? Music Player Daemon?


----------



## vladi (Nov 22, 2017)

Our situation is this: ISP giving us by PPPoE HPDSL internet. We have configured a FreeBSD machine with two ethernet cards: one gets the line from the ISP, and the second one goes to a switch and then to the inner lan. The firewall machine gets its IP address by PPPoE, it works fine, it gets the address, it can resolve addresses. But whenever we try to access a site via HTTP, or FTP, it will hang indefinitely (even from the firewall machine). Going to see the traffic I could log this which caught my https://forums.freebsd.org/threads/45189/attention:

```
11:02:14.776848 IP (tos 0xc0, ttl 2, id 0, offset 0, flags [none], proto EIGRP (88), length 60)
    gw-133.uno.it > igrp-routers.mcast.net:
   EIGRP v2, opcode: Hello (5), chksum: 0xce21, Flags: [none]
   seq: 0x00000000, ack: 0x00000000, AS: 9137, length: 20
     General Parameters TLV (0x0001), length: 12
       holdtime: 15s, k1 1, k2 0, k3 1, k4 0, k5 0
       0x0000:  0100 0100 0000 000f
     Software Version TLV (0x0004), length: 8
       IOS version: 8.0, EIGRP version 2.0
       0x0000:  0800 0200
11:02:14.776877 IP (tos 0x0, ttl 64, id 13410, offset 0, flags [none], proto ICMP (1), length 56)
    host025.pool82-215-161.xdsl-cust.uno.it > gw-133.uno.it: ICMP igrp-routers.mcast.net protocol 88 unreachable, length 36
   IP (tos 0xc0, ttl 2, id 0, offset 0, flags [none], proto EIGRP (88), length 60)
    gw-133.uno.it > igrp-routers.mcast.net:
        packet exceeded snapshot
```


```
11:02:15.676260 IP (tos 0x0, ttl 64, id 62854, offset 0, flags [none], proto UDP (17), length 71)
    host025.pool82-215-161.xdsl-cust.uno.it.30113 > dns.uno.it.domain: [udp sum ok] 18539+ PTR? 1.133.215.82.in-addr.arpa. (43)
11:02:15.699324 IP (tos 0x0, ttl 61, id 41220, offset 0, flags [none], proto UDP (17), length 172)
    dns.uno.it.domain > host025.pool82-215-161.xdsl-cust.uno.it.30113: [udp sum ok] 18539 q: PTR? 1.133.215.82.in-addr.arpa. 1/2/2 1.133.215.82.in-addr.arpa. PTR gw-133.uno.it. ns: 133.215.82.in-addr.arpa. NS dnsw01.uno.it., 133.215.82.in-addr.arpa. NS adns01.uno.it. ar: adns01.uno.it. A 82.215.163.163, dnsw01.uno.it. A 82.215.163.140 (144)
11:02:15.699685 IP (tos 0x0, ttl 64, id 62855, offset 0, flags [none], proto UDP (17), length 69)
    host025.pool82-215-161.xdsl-cust.uno.it.62939 > dns.uno.it.domain: [udp sum ok] 16361+ PTR? 10.0.0.224.in-addr.arpa. (41)
11:02:15.729382 IP (tos 0x0, ttl 61, id 41241, offset 0, flags [none], proto UDP (17), length 368)
    dns.uno.it.domain > host025.pool82-215-161.xdsl-cust.uno.it.62939: [udp sum ok] 16361 q: PTR? 10.0.0.224.in-addr.arpa. 1/4/8 10.0.0.224.in-addr.arpa. PTR igrp-routers.mcast.net. ns: 224.in-addr.arpa. NS a.iana-servers.net., 224.in-addr.arpa. NS c.iana-servers.net., 224.in-addr.arpa. NS b.iana-servers.net., 224.in-addr.arpa. NS ns.icann.org. ar: a.iana-servers.net. A 199.43.135.53, b.iana-servers.net. A 199.43.133.53, c.iana-servers.net. A 199.43.134.53, ns.icann.org. A 199.4.138.53, a.iana-servers.net. AAAA 2001:500:8f::53, b.iana-servers.net. AAAA 2001:500:8d::53, c.iana-servers.net. AAAA 2001:500:8e::53, ns.icann.org. AAAA 2001:500:89::53 (340)
11:02:15.729697 IP (tos 0x0, ttl 64, id 62856, offset 0, flags [none], proto UDP (17), length 72)
    host025.pool82-215-161.xdsl-cust.uno.it.11021 > dns.uno.it.domain: [udp sum ok] 23408+ PTR? 25.161.215.82.in-addr.arpa. (44)
11:02:15.749340 IP (tos 0x0, ttl 61, id 41256, offset 0, flags [none], proto UDP (17), length 199)
    dns.uno.it.domain > host025.pool82-215-161.xdsl-cust.uno.it.11021: [udp sum ok] 23408 q: PTR? 25.161.215.82.in-addr.arpa. 1/2/2 25.161.215.82.in-addr.arpa. PTR host025.pool82-215-161.xdsl-cust.uno.it. ns: 161.215.82.in-addr.arpa. NS dnsw01.uno.it., 161.215.82.in-addr.arpa. NS adns01.uno.it. ar: dnsw01.uno.it. A 82.215.163.140, adns01.uno.it. A 82.215.163.163 (171)
11:02:16.054352 IP (tos 0x0, ttl 237, id 59391, offset 0, flags [none], proto TCP (6), length 40)
    201-40-252-2.ctaje300.ipd.brasiltelecom.net.br.43689 > host025.pool82-215-161.xdsl-cust.uno.it.telnet: Flags , cksum 0x4c06 (correct), seq 0, win 65535, length 0
11:02:16.054364 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    host025.pool82-215-161.xdsl-cust.uno.it.telnet > 201-40-252-2.ctaje300.ipd.brasiltelecom.net.br.43689: Flags [R.], cksum 0x4bf3 (correct), seq 0, ack 1, win 0, length 0
11:02:16.811864 IP (tos 0x0, ttl 64, id 62857, offset 0, flags [none], proto UDP (17), length 70)
    host025.pool82-215-161.xdsl-cust.uno.it.24264 > dns.uno.it.domain: [udp sum ok] 4628+ PTR? 1.1.204.213.in-addr.arpa. (42)
11:02:16.834269 IP (tos 0x0, ttl 61, id 41960, offset 0, flags [none], proto UDP (17), length 168)
    dns.uno.it.domain > host025.pool82-215-161.xdsl-cust.uno.it.24264: [udp sum ok] 4628 q: PTR? 1.1.204.213.in-addr.arpa. 1/2/2 1.1.204.213.in-addr.arpa. PTR dns.uno.it. ns: 1.204.213.in-addr.arpa. NS adns01.uno.it., 1.204.213.in-addr.arpa. NS dnsw01.uno.it. ar: adns01.uno.it. A 82.215.163.163, dnsw01.uno.it. A 82.215.163.140 (140)
11:02:16.834714 IP (tos 0x0, ttl 64, id 62858, offset 0, flags [none], proto UDP (17), length 71)
    host025.pool82-215-161.xdsl-cust.uno.it.25810 > dns.uno.it.domain: [udp sum ok] 50867+ PTR? 2.252.40.201.in-addr.arpa. (43)
11:02:17.389289 IP (tos 0x0, ttl 61, id 42086, offset 0, flags [none], proto UDP (17), length 177)
    dns.uno.it.domain > host025.pool82-215-161.xdsl-cust.uno.it.25810: [udp sum ok] 50867 q: PTR? 2.252.40.201.in-addr.arpa. 1/2/0 2.252.40.201.in-addr.arpa. PTR 201-40-252-2.ctaje300.ipd.brasiltelecom.net.br. ns: 252.40.201.in-addr.arpa. NS ns04-bsa.brasiltelecom.net.br., 252.40.201.in-addr.arpa. NS ns03-cta.brasiltelecom.net.br. (149)
11:02:19.194226 IP (tos 0xc0, ttl 2, id 0, offset 0, flags [none], proto EIGRP (88), length 60)
    gw-133.uno.it > igrp-routers.mcast.net:
   EIGRP v2, opcode: Hello (5), chksum: 0xce21, Flags: [none]
   seq: 0x00000000, ack: 0x00000000, AS: 9137, length: 20
     General Parameters TLV (0x0001), length: 12
       holdtime: 15s, k1 1, k2 0, k3 1, k4 0, k5 0
       0x0000:  0100 0100 0000 000f
     Software Version TLV (0x0004), length: 8
       IOS version: 8.0, EIGRP version 2.0
       0x0000:  0800 0200
11:02:19.194237 IP (tos 0x0, ttl 64, id 13411, offset 0, flags [none], proto ICMP (1), length 56)
    host025.pool82-215-161.xdsl-cust.uno.it > gw-133.uno.it: ICMP igrp-routers.mcast.net protocol 88 unreachable, length 36
   IP (tos 0xc0, ttl 2, id 0, offset 0, flags [none], proto EIGRP (88), length 60)
    gw-133.uno.it > igrp-routers.mcast.net:
        packet exceeded snapshot
```

So basically I keep receiving this "packet exceeded snapshot" error and I am stuck there.
The ISP assistance told me there is no problem from their side, and all the problems are from my side. But to diagnose the problem, the isp set the antenna to act as a router. In that configuration, I could obtain ip via dhcp, internet was working fine. But the isp would not let the antenna act as a router indefinitely for some reasons, so it reverted it to its "normal" state but the problem was persistbing. It is still now persisting. The problem is that this place is a club, I am just going there from time to time. I am trying to make my mind around the problem, so that next time I'm there I'll try some other things. But it doesn't look like pppoe has much configuration to take place... stupidest solution can be to buy a router capable of doing pppoe for around 20 euros, but that's not my attitude around the thing...

To answer the question "what has FreeBSD going to do with this?" ... well, our club just uses FreeBSD at the moment... happy with this!


----------



## vladi (Nov 22, 2017)

Ok. I have to check whether the switch we have is a cisco one. I'll unplug that one and check without it. The strange thing for me is that the same configuration (firewall,switch,nat) worked for 5 months without issues.


----------



## PacketMan (Nov 22, 2017)

vladi said:


> But to diagnose the problem, the isp set the antenna to act as a router. In that configuration, I could obtain ip via dhcp, internet was working fine. But the isp would not let the antenna act as a router indefinitely for some reasons, so it reverted it to its "normal" state but the problem was persistbing. It is still now persisting. The problem is that this place is a club.....
> To answer the question "what has freebsd going to do with this?" ... well, our club just uses freebsd at the moment... happy with this!



So, it sounds like the ISP has their own WiFI equipped router at your club, and they have it in NAT mode. That is normal and typical.  They took it out of NAT mode, and put it in routing mode to help you troubleshoot and then put it back in NAT mode. That is also normal and typical. If indeed they have that in NAT mode, then there is no real need for you to have a server with two NICS in it; unless you want the extra protection of having your own FW.  I can't explain why you get IP address, resolve names, but can't do anything else with it.

Please forgive me sound harsh, which I'm not being, but I don't think you need FreeBSD support, I think you need networking support. Since its a club I can't imagine your requirements are that great.  Either (a) have your ISP provide you with a firewall running NAT, and you use ethernet switch on the inside, or (b) if you want to run your own firewall, then (b1) have ISP (if they can) turn off routing and/or NAT, and you run PPPoE on your WAN interface on the FreeBSD machine with NAT too, or (b2) considering using pfSense. ( https://en.wikipedia.org/wiki/PfSense )  That will help you set up a working cookie cutter FW quicker I think. Or (b3) go buy your own NAT/FW appliance.


Either way I don't think FreeBSD help is want you require at the moment.


----------



## vladi (Nov 23, 2017)

The isp just provides us with the antenna, the antenna amplifier from which coming out there is an ethernet cable to be plugged on our own router capable of pppoe. Instead of buying a router, we set up a machine with two nics acting as firewall/router. The isp claims that if we buy a router capable of pppoe everything works. Yes we definitely need network support but since the ISP did not help us in that sense I thought to ask here...


----------



## PacketMan (Nov 24, 2017)

Please answer the following questions:


Is the link between your club and the ISP wireless, or wired (either 'copper' or fiber)?
Is the ISP device on site doing NAT, or routing, or bridging?
What did ISP tell you to do? NAT or routing?
If they told you to do routing with them what did they tell you to do/use?
If you don't know the answers then ask the ISP.

This forum is a FreeBSD support forum, not a networking support forum.  That just said, if you are having issues with FreeBSD with network then we can help you, but that help is in the form of how to configure FreeBSD to do something (like routing, firewall, support for 802.1q tagging, recognizing and acting on QoS (either 802.1p, or at IP level like DiffServ for example).  Helping you figure out networking in general, your design and requirements on how to inter-operate with your ISP is beyond this group.  There are lots of other forums for that, and your ISP should have a sales-engineering person and a techy person to help you understand what you need to do.  Consider escalating and asking them for help beyond their front line help desk.  If you are a club and they did a wireless shot to your building then I'm guessing you have an account manager and he/she can connect you with the right staff.

After you have nailed that down, then figure out how FreeBSD may or may not be right for you.  Honestly you could consider pfSense to get you up and running more quickly, and if you have time you can tinker and learn FreeBSD on your own terms. When you are stronger with FreeBSD and want to replace your 'box' with it, and still need a little help then absolutely reach out to us for help.


----------



## vladi (Nov 24, 2017)

The link between our club is wired. We have a dish antenna, a signal amplifier which powers the antenna, and from which an ethernet cable is coming out.
The isp technician coming to put the antenna told us we just needed a router capable of pppoe. 
is the isp device doing NAT, or routing, or bridging... hmm. I don't really know.I'll ask them. 
When the technician came and I told him I would use a freebsd machine acting as a router, he looked like he did not know much about the thing. He had never used a console based operating system. I configured the machine with mpd5 for getting the pppoe connection, and that was it. I then put up a natd demon for sharing the connection on our local net. I put up a firewall, and that was working fine for 6 months. Then the problem arose, from one day to another. Their tech support told me that when I was not using a router to connect then they could'nt help me out, that it was surely a misconfigured network from our side. 
Anyway, on sunday I'll go to the club and check out the whole thing. 
Well man the process of learning how to use freebsd never ends. I know how an operating systems work... and since I left linux world since 6 years I'll definitely won't go the other way round...


----------



## PacketMan (Nov 24, 2017)

vladi said:


> The link between our club is wired. We have a dish antenna, a signal amplifier which powers the antenna, and from which an ethernet cable is coming out.



I'm sorry,  I'm really confused. If you are 'wired' to your ISP then what is the antenna dish for?  I'm really struggling to understand the design so I can better offer guidance.  My advice at this point is time is hire someone who knows networking, have them talk to your ISP, and then he/she can tell you what you need to do.  If you hire the right person, telling them you are using a *nix based device to do your stuff won't concern them.


----------



## vladi (Nov 24, 2017)

Well we have internet via radio... hpdsl.


----------



## vladi (Nov 24, 2017)

SirDice said:


> If you get an IP address _and_ you're able to resolve hostnames (this implies a working connection or else you wouldn't be able to resolve anything), then what exactly isn't working?


Well. ftp access is not working, nor web services like accessing an internet page. I'll get the errors I showed in the log extract if I tcpdump the traffic. Meanwise, the browser is hanging forever on any page (for example, ftp ftp.freebsd.org will reach the ftp server, but won't be able to login. ) On sunday I'll go there and check it out again. The isp claims everything's fine, they have "solved the problem". Apart from tcpdumping the traffic what can I do to better focus the problem? I can try traceroute ...


----------



## vladi (Nov 24, 2017)

By reading at the pppoe man page, I can see that problems can arise when the mtu is greater than 1492 in the internal network, because of the overhead implied in encapsulating the packets. The man page suggests to set the mtu on the machines below the firewall to 1412. Well I'll give it a try.


----------

