Hi I’ve got a central site and a number of remote networks – each remote network maintains a layer-3 speedfusion link back to the central site (there is one profile on the central site for every remote site).
There is no need for connectivity directly between sites over speedfusion - in fact its a negative that the default behavior is for the speedfusion link to learn routes to all remote sites as being via the speedfusion link – its not a deal breaker that this happens, but its that would be preferable for us to be able to disable this … The main concern is that all remote sites are connected to the internet via very slow links – we have need to ensure that the minimal amount of traffic possible is passed to any of the remote sites.
In firmware 6.1.0 some ospf settings were added – under Network -> OSPF&RIP – there is a default OSPF ‘Area 0’ configured with the PepVPN interface as a member – the link type is described as broadcast. Is this setting interpreted somewhere in deciding how the speedfusion link should behave – is there any possibility that this would adjust the tunnel characteristics to create a shared broadcast domain among the vpn participants? Can this result in traffic from Site A -> Central Site also needing to be passed to Site B, Site C , … etc. Here is a picture of the default config:
Once again, I’m not entirely sure how the speedfusion and ospf features might interact – so I think its easier to just specify what I want to make sure I’m achieving with a simple example.
Example:
I have a central site with 2 speedfusion profiles, and there are 2 remote sites which each establish a speedfusion link with the central site.
Site A is connected via speedfusion to Central Site
Site B is connected via speedfusion to Central Site
Site A and Site B are connected to the internet via very slow links. I need to ensure:
Packet flows between Site A <-> Central Site does not result in any traffic being sent to Site B
Packet flows between Site B <-> Central Site does not result in any traffic being sent to Site A
Do I need to adjust any OSPF settings or anything elsewhere to ensure this behavior is achieved …? Is there any risk that the speedfusion link would establish a broadcast domain that is shared among all the sites – such that a packet intended for only one site is actually delivered to all sites?
Your example helps so I will keep it simple. There would not be any traffic between the remote sites unless a session was established between them. It is not a broadcast domain because you are routing at layer three. The following steps will block traffic between sites A and B if an attempt is made to establish a session in either direction:
Site A:
Outbound firewall rule 1
Source = any
Destination = site B LAN network
Action = deny
Outbound firewall rule 2
Source = any
Destination = any
Action = allow
Site B:
Outbound firewall rule 1
Source = any
Destination = site A LAN network
Action = deny
Outbound firewall rule 2
Source = any
Destination = any
Action = allow
Ok thanks for the confirming – this matches my expectations – I just wasn’t sure exactly what might be happening by default with OSPF routing/speedfusion … I definitely don’t want traffic to get routed from site a -> site b -> central site -> internet for example …
And just to be clear – the major (confusing!) observation which prompted this question is that there is a bug in the command-line ‘get session’ command … If any recent ICMP activity (as from a ping session) has occurred, the session table printed by ‘get session’ gets all kinds of wrong … It shows entries for ICMP flows between random hosts – often with both source and destination addresses not belonging to the peplink LAN – or even any speedfusion peers. The src/dst fields of the entry for the ICMP flow seem to get populated with random src and dst addresses of flows from other parts of the session table …
The bug does not manifest in the web interface – only in the command-line ssh interface …
I actually did this already and I got bumped to the trouble support system of the vendor from whom I bought this particular peplink model (we have several, some from you guys and some from a reseller). Pursued it for awhile with their support system but didn’t get anywhere useful and the issue seems to have gotten dropped …
Am I the only one seeing this issue (it’s reproducible for me on multiple peplink balance routers with this firmware version …) Should I submit the ticket again?
What it did before and (will do again)
run ‘get session’ many times with no icmp activity coming from the LAN
begin a packet dump
initiate an icmp session via ‘ping’ from a host on the LAN to a reachable host on the internet
run get session repeatedly while the ping session is active (this will show the session table getting screwed up)
stop the ping session
run ‘get session’ a few more times to show things going back to normal
download the diagnostics report
submit all the ‘get session’ pre-ping, during ping, and post-ping output, the diagnostic report, and the packet capture downloaded from the peplink support interface