Re: [swinog] What GeoIP Locator service do srf.ch, bluewin.ch and iTunes use?
Hi Benoit, Can`t say for sure how srf do it but in most cases this is done based on internet registry queries (RIPE db for example). Maybe you checked this already but it is possible that the specific IPs having the issue are not directly related to the /19 you mentionned but to a smaller more specific subnet which is assigned to a different country (or was recently as most of these applications do not make real time queries and only synchronise from time to time). Could you possibly provide one or two of the impacted IPs to see if they are part of the /19 or a smaller subnet? In addition to this I also read that some content providers perform more checks on top of the IP layer, for example related to browser or media application settings, at this level only srf can give you more details. Anyway in my experience similar problems were almost always related to the subnet information in the internet registry... Regards, Fadi On 1/25/12, Benoit Panizzon wrote: > Hello World > > Some of our customer within our 31.11.0.0/19 allocation, get blocked while > trying to access streaming content from drs.ch, bluewin.ch and iTunes, > because > somehow those sites think they are located outside switzerland. (I suppose > it > mainly affects content hosted as srf.ch) > > http://www.ipaddresslabs.com > and > http://www.maxmind.com > > Do locate the ip addresses correctly to switzerland. > > So I suppose SRF uses some other service. > > Does somebody know what GeoIP Locator services srf.ch uses? The SRF IT > Helpdesk was not able to tell me. > > Kind regards > > Benoit Panizzon > -- > I m p r o W a r e A G- > __ > > Zurlindenstrasse 29 Tel +41 61 826 93 07 > CH-4133 PrattelnFax +41 61 826 93 02 > Schweiz Web http://www.imp.ch > __ > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] IPv6 de-aggregation
Hi John, In my company we will accept or advertise upto /48, also most of our upstreams will do the same. As for routing sub-allocations from a different AS some providers do that some don`t, as you said they will have to be convinced (but it`s not really good practice for PA space). Regards, Fadi On Fri, Apr 27, 2012 at 10:09 AM, wrote: > Hi SWINOG members, > > ** ** > > we’re a LIR, we got a /32 from RIPE and we want to allocate /40s and /48s > to customers. Only snag is that the customers will not have their Internet > feed from us but from any Service Provider of their choice. The customers > will have to convince their SPs (X, Y, Z) to route these „non X,Y,Z” or > “foreign“ prefixes. We’re getting a lot of “raised eyebrows” about this. > What’s this about prefixes longer that /32 not being propagated? When I > look at the IPv6 table I see: > > ** ** > > IPv6 Routing Table Summary - 8625 entries > > 5 local, 2 connected, 3 static, 0 RIP, 8615 BGP 0 IS-IS, 0 OSPF > > Number of prefixes: > > /0: 1, /8: 1, /10: 1, /12: 1, /16: 1, /19: 2, /20: 5, /21: 3 > > /22: 5, /23: 5, /24: 7, /25: 4, /26: 9, /27: 10, /28: 31, /29: 19 > > /30: 15, /31: 13, /32: 4049, /33: 97, /34: 87, /35: 93, /36: 242, /37: > 7 > > /38: 50, /39: 22, /40: 385, /41: 12, /42: 18, /43: 34, /44: 151, /45: > 15 > > /46: 75, /47: 45, /48: 3006, /49: 3, /50: 1, /52: 5, /56: 9, /64: 40** > ** > > /126: 1, /128: 45 > > ** ** > > So where did all the /48s come from ... also one or two /40s... ?? > > ** ** > > What do you think about this? If you’re a SP would you route the /48s or > /40s from the customers? What about your upstream peers? > > ** ** > > Thanks in advance for your answers. > > ** ** > > John > > ** ** > > John Collins > > ** ** > > Eidgenössisches Finanzdepartement EFD > > Bundesamt für Informatik und Telekommunikation BIT > > Basisprodukte > > Telekommunikation > > Netzplanung und Engineering > > ** ** > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > > ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] routing protocols between isp and customer?
Hi Roman, Most ISPs would use BGP and typically it would look like this: ISP-iBGP_AS100-ISP | | | | eBGP eBGP | | | | CSR--iBGP_AS65532--CSR Regards, Fadi On Fri, Nov 2, 2012 at 9:56 AM, Roman Hochuli wrote: > Hey All > > Quick question: do you allow/run routing protocols between your (isp-) > network and your customer? > If so: which protocols? > If not: what reasons do you tell the customer? > > > In particular I am interested to know about setups when they want to > announce the prefix/subnet you assigned them from your PA-space back to > you because they want to run redundant routers. > > The setup would probably look like this: > >Customer Subnet 10.0.0.0/27 > / \ > | | > [customer router a] - - [customer router b] > | | > > | | > [isp router a] - - [isp router b] > | | > \ / > ISP Network 10.0.0.0/8 > > -- > Best regards, > Roman Hochuli > Operations Manager > > nexellent ag > Saegereistrasse 33 > CH-8152 Glattbrugg > > Phone: +41 44 872 20 00 > Fax: +41 44 872 20 01 > URL: www.nexellent.ch > X-NCC-RegID: ch.nexellent > > Imagination is the one weapon in the war > against reality. > -- Jules de Gaultier > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] routing protocols between isp and customer?
Hi Roman, I cannot speak for others but I would imagine that any ISPs should be willing to run such setups, at least I can confirm in the ISP where I work we do this all the time, for both PA and PI. Regards, Fadi On Fri, Nov 2, 2012 at 11:44 AM, Roman Hochuli wrote: > Hello Fadi > > Thank you for your reply. > > > Most ISPs would use BGP and typically it would look like this: > > That's basically the setup I described. Still remaining my question: > which ISPs run setups like that in CH? > > -- > Best regards, > Roman Hochuli > Operations Manager > > nexellent ag > Saegereistrasse 33 > CH-8152 Glattbrugg > > Phone: +41 44 872 20 00 > Fax: +41 44 872 20 01 > URL: www.nexellent.ch > X-NCC-RegID: ch.nexellent > > Imagination is the one weapon in the war > against reality. > -- Jules de Gaultier > ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Transparent 1Gig Ethernet over IP/Ethernet?
Hi Chris, Here are two more that support LACP tunneling at wire speed. Juniper EX series http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/l2pt-ex-series.html RAD ETX series http://www.rad.com/12/Ethernet-over-Fiber/13101/ Regards, Fadi On Mon, Jun 17, 2013 at 9:21 AM, Jérôme Tissières wrote: >Hi Chris, Hi all, > > Q-in-Q / L2Tunnel and 802.1ad with LACP works with Cisco switches without > any problem. > On ME switch and I tested it with small low-cost 3560G, it works too. > > Here's an example: > > http://www.cisco.com/en/US/docs/switches/metro/me3400e/software/release/12.2_55_se/configuration/guide/swtunnel.html#wp1066465 > > Is it what you are looking for? > > Cheers, > Jerome > > > > > > Jerome Tissieres > ___ > Head of Network Engineering & Operations > > Ticinocom SA > Via Stazione 5 > CH-6600 Locarno > Phone +41 91 220 00 00 > Fax +41 91 220 00 10 > www.ticino.com > ___ > > > 2013/6/16 chris burri > >> Unfortunately, QinQ (which is called "vman" in the Extreme Networks >> world) does not work with LACP. Corroborating to the problem is the fact >> that the LAG ports originate on the same switch that provides the transport >> vmans. Since QinQ transports share src/dst MAC address-space with the >> connected "customer" VLANs, the "direct" approach does not even work for >> non-LACP LAGs. >> >> I successfully employed encapsulation of the LACP LAG legs with a pair of >> EdgeMAX Lite routers, configured for L2 GRE Bridging. I was then able to >> pipe the encapsulated LAG legs back into the Summit X460 Switch where they >> originally came from, and transport them over the vmans. Unfortunately, the >> performance achieved by this solution (~350mbps on a single leg) is far >> from sufficient. >> >> Two kind members of the NANOG mailing list pointed me to ethernet >> demarcation devices (E-Line being of interest here) from accedian and >> ciena, which might just do the trick at GigE wire speed: >> >> http://www.accedian.com/en/products/ethernid-family.html >> http://www.ciena.com/products/3902/ >> >> Silvan also pointed out that Mikrotik's EoIP might provide adequate >> performance when provided by a pair of CCR1036 36 core CPU routers. >> However, it looks as if the accedian/ciena devices would offer a much more >> cost-effective approach. >> >> >> Mit freundlichen Grüssen >> Chris Burri >> >> >> --- >> >> -= Amat Victoria Curam =- >> >> >> > Date: Sun, 16 Jun 2013 12:19:39 +0200 >> > From: swinog-l...@dudes.ch >> > To: swinog@lists.swinog.ch >> > Subject: Re: [swinog] Transparent 1Gig Ethernet over IP/Ethernet? >> >> > >> > >> > > I need to transparently (especially LACP >> > > frames) transport a gigabit ethernet link with at least 1500 MTU over >> > > either IP or Ethernet. Jumbo frames are enabled on >> > > the L2 transport backbone. While I need "full" (some encap overhead >> > > will be acceptable) GigE wire speed, encryption is unnecessary. >> > >> > Since you don't need encryption, aren't these more or less the same >> > requirements as to transport dot1q tags within an existing vlan, that >> > is, q-in-q? The foundry/brocade approach would be to override the frame >> > tag on the entry and exit ports and declare those ports as access-ports >> > (untagged to transport-vlan XYZ), thus transporting anything that comes >> > in there via vlan XYZ to the destination. Or is LACP more low-level and >> > can't be tricked to be relayed by playing with frame types? >> > >> > Cheers, >> > Markus >> > >> > >> > ___ >> > swinog mailing list >> > swinog@lists.swinog.ch >> > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog >> >> >> ___ >> swinog mailing list >> swinog@lists.swinog.ch >> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog >> >> > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > > ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
[swinog] Fwd: Transparent 1Gig Ethernet over IP/Ethernet?
Hi Chris, Here are two more that support LACP tunneling at wire speed. Juniper EX series http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/l2pt-ex-series.html RAD ETX series http://www.rad.com/12/Ethernet-over-Fiber/13101/ Regards, Fadi On Mon, Jun 17, 2013 at 9:21 AM, Jérôme Tissières wrote: >Hi Chris, Hi all, > > Q-in-Q / L2Tunnel and 802.1ad with LACP works with Cisco switches without > any problem. > On ME switch and I tested it with small low-cost 3560G, it works too. > > Here's an example: > > http://www.cisco.com/en/US/docs/switches/metro/me3400e/software/release/12.2_55_se/configuration/guide/swtunnel.html#wp1066465 > > Is it what you are looking for? > > Cheers, > Jerome > > > > > > Jerome Tissieres > ___ > Head of Network Engineering & Operations > > Ticinocom SA > Via Stazione 5 > CH-6600 Locarno > Phone +41 91 220 00 00 > Fax +41 91 220 00 10 > www.ticino.com > ___ > > > 2013/6/16 chris burri > >> Unfortunately, QinQ (which is called "vman" in the Extreme Networks >> world) does not work with LACP. Corroborating to the problem is the fact >> that the LAG ports originate on the same switch that provides the transport >> vmans. Since QinQ transports share src/dst MAC address-space with the >> connected "customer" VLANs, the "direct" approach does not even work for >> non-LACP LAGs. >> >> I successfully employed encapsulation of the LACP LAG legs with a pair of >> EdgeMAX Lite routers, configured for L2 GRE Bridging. I was then able to >> pipe the encapsulated LAG legs back into the Summit X460 Switch where they >> originally came from, and transport them over the vmans. Unfortunately, the >> performance achieved by this solution (~350mbps on a single leg) is far >> from sufficient. >> >> Two kind members of the NANOG mailing list pointed me to ethernet >> demarcation devices (E-Line being of interest here) from accedian and >> ciena, which might just do the trick at GigE wire speed: >> >> http://www.accedian.com/en/products/ethernid-family.html >> http://www.ciena.com/products/3902/ >> >> Silvan also pointed out that Mikrotik's EoIP might provide adequate >> performance when provided by a pair of CCR1036 36 core CPU routers. >> However, it looks as if the accedian/ciena devices would offer a much more >> cost-effective approach. >> >> >> Mit freundlichen Grüssen >> Chris Burri >> >> >> --- >> >> -= Amat Victoria Curam =- >> >> >> > Date: Sun, 16 Jun 2013 12:19:39 +0200 >> > From: swinog-l...@dudes.ch >> > To: swinog@lists.swinog.ch >> > Subject: Re: [swinog] Transparent 1Gig Ethernet over IP/Ethernet? >> >> > >> > >> > > I need to transparently (especially LACP >> > > frames) transport a gigabit ethernet link with at least 1500 MTU over >> > > either IP or Ethernet. Jumbo frames are enabled on >> > > the L2 transport backbone. While I need "full" (some encap overhead >> > > will be acceptable) GigE wire speed, encryption is unnecessary. >> > >> > Since you don't need encryption, aren't these more or less the same >> > requirements as to transport dot1q tags within an existing vlan, that >> > is, q-in-q? The foundry/brocade approach would be to override the frame >> > tag on the entry and exit ports and declare those ports as access-ports >> > (untagged to transport-vlan XYZ), thus transporting anything that comes >> > in there via vlan XYZ to the destination. Or is LACP more low-level and >> > can't be tricked to be relayed by playing with frame types? >> > >> > Cheers, >> > Markus >> > >> > >> > ___ >> > swinog mailing list >> > swinog@lists.swinog.ch >> > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog >> >> >> ___ >> swinog mailing list >> swinog@lists.swinog.ch >> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog >> >> > > > ___ > swinog mailing list > swinog@lists.swinog.ch > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > > ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
