Internet Related/Filtering/Firewall Thread, LGfL videocentral -videos not streaming within school in Technical; We have a specific problem with LGFL videocentral ( https://videocentral.lgfl.org.uk ,and
Perform-a-Poem ) streaming in school (no problem at home)(no
problem other videos such as youtube,bbc) specifically since 11th June.
can get the actual videocentral site and thumbnails etc fine but the videos never start to
stream or allow the video start button to work. Applies to all videos on videocentral- ours,
public ones etc
Streaming of videocentral videos at the school we "piggy back" on for broadband- works fine.
The same specific problem (probably) also arose May 2012 and November 2011
All parties/services have been informed
suggestions have been
your network/a firewall/a proxy is not allowing streaming traffic.
it's not a proxy issue /it is a Videocentral issue
the school you piggy back from has a different IP address to you so there may be a routing issue
reccomend look at your DNS configuration so that requests for this site are treated in the same
way as the school which you piggy back on since they feed the internet to your school.
Both of the two school networks are set up the same way. All clients look to the server for DNS
requests and the forwarders within DNS on the server are set to DNS servers
We have no firewall at our site.
1. any ideas?
2.any specific fault-finding can do from within school while attempting to get the videos to work
We've had similar but intermittent problems with you tube and BBC iplayer the past 2 days. Not had much luck tracking it down. We didn't think to try video central. I might try that tomorrow if it comes up again. No idea for a fix or troubleshooting im afraid. We're in Kingston, and using lgfl via kingsnet. Our partner school didn't seem to be having the same issues.
Tried a tracert from a linux box. It seems a traceroute from windows doesn't work very well on LGFL outside of the school network. Even from linux, it didn't show up anything particulary helpful, but then we don't seem to be having the issue at this point. The log is below It looks like its a specific problem with streaming media. Everything else loads up fine - except fronter, but thats always slow. I don't think this is a routing issue, it looks more like filtering or firewall problems.
# traceroute -T videocentral.lgfl.org.uk
traceroute to videocentral.lgfl.org.uk (188.8.131.52), 30 hops max, 40 byte packets
1 our_core_switch (internal_ip) 1.698 ms 2.587 ms 9.577 ms
2 LA_Router (router_ip) 0.410 ms 0.812 ms 0.953 ms
3 * * *
4 10.1.4.2 (10.1.4.2) 0.738 ms 1.219 ms 1.158 ms
5 184.108.40.206 (220.127.116.11) 2.270 ms 2.606 ms 2.622 ms
6 172.31.253.22 (172.31.253.22) 2.568 ms 2.498 ms 2.309 ms
7 * * *
8 18.104.22.168 (22.214.171.124) 8.067 ms 8.008 ms 8.992 ms
9 brnt-bb-1b-as2-0.network.virginmedia.net (126.96.36.199) 12.970 ms 12.539 ms 11.426 ms
10 brnt-bb-1a-ae0-0.network.virginmedia.net (188.8.131.52) 11.446 ms 11.319 ms 11.340 ms
11 brnt-core-2a-ae0-0.network.virginmedia.net (184.108.40.206) 8.884 ms 8.824 ms 8.763 ms
12 brnt-lam-5-tenge74.network.virginmedia.net (220.127.116.11) 9.470 ms brnt-lam-5-tenge71.network.virginmedia.net (18.104.22.168) 9.408 ms brnt-lam-5-tenge74.network.virginmedia.net (22.214.171.124) 9.348 ms
13 brnt-lam-5-tenge73-1845.network.virginmedia.net (126.96.36.199) 11.366 ms 11.303 ms 11.276 ms
14 201-141-168-194.static.virginmedia.com (188.8.131.52) 10.494 ms 184.108.40.206 (220.127.116.11) 11.656 ms 18.104.22.168 (22.214.171.124) 10.789 ms
15 * * *
16 * * *
17 126.96.36.199 (188.8.131.52) 12.276 ms 12.401 ms 11.731 ms
You appear to still be on LGFL 1. Are you up to date with the various service transitions that are taking place? There have in the past been routing issues betwen the two networks.
Regarding the ability to do a tracert: are you sure it is a windows vs linux thing? For us it is a firewall matter: our nix box is in the server subnet which has different rules to the client subnet. From nix it works but from windows 7 it doesn't, however from windows 2008 in the server subnet it also works. At least once a week I forget this. Look to your own devices first to isolate the problem, at the very least they help you gather evidence to prove to your supplier that the problem lies between the edge and their service.
A packet capture of the site loading and the stream failing would almost certainly prove illuminating.
hi , well tracert from both locations and compare- both time out within one or two hops.
Net monitor- can you install and run it from a workstation (xp) on the network?
then " To start a capture session in Network Monitor 3, click the Start Page tab, click Create a new capture tab, and then either click the Start Capture button, or press F10"
and you say "A packet capture of the site loading and the stream failing would almost certainly prove illuminating" so you just - start capture then load the site , then stop capture-then what do you look for and where to see the expected data?
I found with traceroute that the default type of scan didn't work on either windows or linux. I don't know what method it uses, but on linux there is an option to scan with tcp or icmp, both of which worked. The documentation was unspecific on the default method, however, it only returned hostnames for the first two hops which are on our network. My windows 7 workstation is on the same subnet as the servers, so thats not an issue.
I think you can use network monitor on xp, if not, you can use wireshark. I've not really used network monitor, wireshark is my tool of choice for this.
Once you've done a capture, you need to look for packets relating to videocentral/whatever is the problem. Once you stop the packet capture, you should get a long list of packets that have been captured. There should be search and filter options in both wireshark and network monitor, but I don't know how useful they will be unless you know exactly what you are looking for. You might end up filtering out what you need to find. Its well worth having a play around with one of these tools, and getting familiar with it.
I haven't had any reported problems since this happened originally, so I think whatever the problem was has resolved itself for us. It may well be that we have two different problems, but it sounded suspiciously similar.