Re: Indonesian ISP Moratel announces Google's prefixes
By reading cloudflare blog, cloudflare network engineer discovered that Google's authoritative DNS server networks (including Google's public DNS 8.8.8.0/24) were being routed to Indonesia according their cloudflare's SF office edge router, this is werid unless cloudflare is doing something crazy on their edge router, given that those networks are heavily anycasted across the Internet, if cloudflare sees those networks are being routed to Indonesia from San Francisco, then a lot more people should've been affected. On Tue, Nov 6, 2012 at 8:51 PM, Christopher Morrow morrowc.li...@gmail.comwrote: On Tue, Nov 6, 2012 at 11:48 PM, Jian Gu guxiaoj...@gmail.com wrote: What do you mean hijack? Google is peering with Moratel, if Google does not want Moratel to advertise its routes to Moratel's peers/upstreams, then Google should've set the correct BGP attributes in the first place. curios to know which those are?
Re: Indonesian ISP Moratel announces Google's prefixes
Where did you get the idea that a Moratel customer announced a google-owned prefix to Moratel and Moratel did not have the proper filters in place? according to the blog, all google's 4 authoritative DNS server networks and 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a Moratel customers announce all those prefixes? On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore patr...@ianai.netwrote: On Nov 06, 2012, at 23:48 , Jian Gu guxiaoj...@gmail.com wrote: What do you mean hijack? Google is peering with Moratel, if Google does not want Moratel to advertise its routes to Moratel's peers/upstreams, then Google should've set the correct BGP attributes in the first place. That doesn't make the slightest bit of sense. If a Moratel customer announced a Google-owned prefix to Moratel, and Moratel did not have the proper filters in place, there is nothing Google could do to stop the hijack from happening. Exactly what attribute do you think would stop this? -- TTFN, patrick On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia m...@anuragbhatia.com wrote: Another case of route hijack - http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about I am curious if big networks have any pre-defined filters for big content providers like Google to avoid these? I am sure internet community would be working in direction to somehow prevent these issues. Curious to know developments so far. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia| Google+ https://plus.google.com/118280168625121532854
Re: Indonesian ISP Moratel announces Google's prefixes
I don't know what Google and Moratel's peering agreement, but leak? educate me, Google is announcing /24 for all of their 4 NS prefix and 8.8.8.0/24 for their public DNS server, how did Moratel leak those routes to Internet? On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore patr...@ianai.netwrote: On Nov 07, 2012, at 00:07 , Jian Gu guxiaoj...@gmail.com wrote: Where did you get the idea that a Moratel customer announced a google-owned prefix to Moratel and Moratel did not have the proper filters in place? according to the blog, all google's 4 authoritative DNS server networks and 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a Moratel customers announce all those prefixes? Ah, right, they just leaked Google's prefix. I thought a customer originated the prefix. Original question still stands. Which attribute do you expect Google to set to stop this? Hint: Don't say No-Advertise, unless you want peers to only talk to the adjacent AS, not their customers or their customers' customers, etc. Looking forward to your answer. -- TTFN, patrick On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore patr...@ianai.net wrote: On Nov 06, 2012, at 23:48 , Jian Gu guxiaoj...@gmail.com wrote: What do you mean hijack? Google is peering with Moratel, if Google does not want Moratel to advertise its routes to Moratel's peers/upstreams, then Google should've set the correct BGP attributes in the first place. That doesn't make the slightest bit of sense. If a Moratel customer announced a Google-owned prefix to Moratel, and Moratel did not have the proper filters in place, there is nothing Google could do to stop the hijack from happening. Exactly what attribute do you think would stop this? -- TTFN, patrick On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia m...@anuragbhatia.com wrote: Another case of route hijack - http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about I am curious if big networks have any pre-defined filters for big content providers like Google to avoid these? I am sure internet community would be working in direction to somehow prevent these issues. Curious to know developments so far. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia| Google+ https://plus.google.com/118280168625121532854
Re: Indonesian ISP Moratel announces Google's prefixes
Dear Mr. Know-Peering, I came here to learn and I believe I have the right to say what I was thinking, no matter how ignorant my comment was. I don't have the right to blame anybody, in fact I don't give a damn whose fault it is, it is not my business. I apologize if I offended you when you claimed that it was a hijacking. On Tue, Nov 6, 2012 at 9:45 PM, Patrick W. Gilmore patr...@ianai.netwrote: On Nov 07, 2012, at 00:35 , Jian Gu guxiaoj...@gmail.com wrote: Hmm, look at this screen shot from the blog, 8.8.8.0/24 was orignated from Google. Everyone who posted in this thread was well aware of that. (Well, except me in my first post. :) Google was still the victim, and it was still not their fault. You are showing wide and clear ignorance on the basics of peering. Which is fine, the vast majority of the planet hasn't a clue what peering is. However, the rest of the people who do not know what they are talking about have managed to avoid commenting on the subject to 10K+ of their not-so-closest friends. To be clear, if you had started with something like: Why is Google originating the route? Doesn't that make it valid?, you would have gotten a lot of help support. But instead you started by claiming it was Google's fault and they could stop this by setting the correct BGP attributes. I note you still haven't told us what those attributes would be despite repeated questions. Perhaps it's time to admit you don't know what attributes, and you need a little more education on peering in general? When you find yourself in a hole, stop digging. -- TTFN, patrick tom@edge01.sfo01 show route 8.8.8.8 inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown, 14 hidden) + = Active Route, - = Last Active, * = Both 8.8.8.0/24 *[BGP/170] 00:27:02, MED 18, localpref 100 AS path: 4436 3491 23947 15169 I to 69.22.153.1 via ge-1/0/9.0 On Tue, Nov 6, 2012 at 9:33 PM, Hank Nussbacher h...@efes.iucc.ac.il wrote: At 21:21 06/11/2012 -0800, Jian Gu wrote: If Google announces 8.8.8.0/24 to you and you in turn start announcing to the Internet 8.8.8.0/24 as originating from you, then a certain section of the Internet will believe your announcement over Google's.This has happened many times before due to improper filters, but this is the first time I have seen the victim being blamed. Interesting concept. -Hank I don't know what Google and Moratel's peering agreement, but leak? educate me, Google is announcing /24 for all of their 4 NS prefix and 8.8.8.0/24 for their public DNS server, how did Moratel leak those routes to Internet? On Tue, Nov 6, 2012 at 9:13 PM, Patrick W. Gilmore patr...@ianai.net wrote: On Nov 07, 2012, at 00:07 , Jian Gu guxiaoj...@gmail.com wrote: Where did you get the idea that a Moratel customer announced a google-owned prefix to Moratel and Moratel did not have the proper filters in place? according to the blog, all google's 4 authoritative DNS server networks and 8.8.8.0/24 were wrongly routed to Moratel, what's the possiblity for a Moratel customers announce all those prefixes? Ah, right, they just leaked Google's prefix. I thought a customer originated the prefix. Original question still stands. Which attribute do you expect Google to set to stop this? Hint: Don't say No-Advertise, unless you want peers to only talk to the adjacent AS, not their customers or their customers' customers, etc. Looking forward to your answer. -- TTFN, patrick On Tue, Nov 6, 2012 at 9:02 PM, Patrick W. Gilmore patr...@ianai.net wrote: On Nov 06, 2012, at 23:48 , Jian Gu guxiaoj...@gmail.com wrote: What do you mean hijack? Google is peering with Moratel, if Google does not want Moratel to advertise its routes to Moratel's peers/upstreams, then Google should've set the correct BGP attributes in the first place. That doesn't make the slightest bit of sense. If a Moratel customer announced a Google-owned prefix to Moratel, and Moratel did not have the proper filters in place, there is nothing Google could do to stop the hijack from happening. Exactly what attribute do you think would stop this? -- TTFN, patrick On Tue, Nov 6, 2012 at 3:35 AM, Anurag Bhatia m...@anuragbhatia.com wrote: Another case of route hijack - http://blog.cloudflare.com/**why-google-went-offline-today-** and-a-bit-about http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about I am curious if big networks have any pre-defined filters for big content providers like Google to avoid these? I am sure internet community would be working in direction to somehow prevent these issues. Curious to know developments so far. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin http://in.linkedin.com/in/**anuragbhatia21
Re: Provider WAAS service for multiple MPLS VPN customers, possible?
Theoretically if both WAEs are placed inline on MPLS uplink, then it should work -- unless WAAS code can only recognize IP/Ethernet but not IP/MPLS/Ethernet traffic. I don't think WAAS is VRF aware and can maintain a multi-VRF routing table. On Mon, Feb 27, 2012 at 8:04 AM, Frank Ho completea...@gmail.com wrote: Hi there, Just want to know if anybody out there has tried to put a pair of Cisco WAAS cards on two PEs to optimize the traffic of multiple VRFs between them ? Is that actually possible ? If it's possible, how does the WAAS module card forward the optimized traffic back to the correct VRF? Any hints or sample configurations are most appreciated. Frank.
Re: Foundry MRP cohabit with STP
MRP and STP are configured under VLAN, same physical interface tagged with different VLANs can participate both MRP and STP in different VLAN, if you are asking MRP and STP under the same VLAN, that is not a valid configuration, think about it, what if MRP wants to block an interface but STP wants the same interface to forward traffic? On Tue, Nov 15, 2011 at 1:30 AM, Viet-Hung Ton v...@integra.fr wrote: Hi, We are deploying a network using MRP of Foundry (Metro Ring Protocol of Brocade now) and STP (in this case Rapid Spanning Tree Protocol-802.1W). The problem is that in some networking segment, we must enable both of protocols in the same interfaces and vlans for the correct function of our network. By the way, as MRP and STP are 2 protocols of loop prevention, the devices of Brocade force us choosing and activating just one among them that not our intention. Anybody has the same situation of some experiences in this case: how to make coexist these two protocols. (MRP and STP). Best thanks, Viet Ton.
Re: Junos Asymmetric Routing
Then you should look at your IGP, right? On Fri, May 28, 2010 at 8:09 AM, Ken Gilmour ken.gilm...@gmail.com wrote: Hi Jian, Yes sir that's what I thought too. The packets are being NATted (and I also used a bit of DNAT for port forwarding to test the theory) but the result is the same. Regards, Ken On 27 May 2010 23:46, Jian Gu guxiaoj...@gmail.com wrote: Wouldn't simply configure source NAT on firewall 2.2.2.1 resolve the problem gracefully? when connection requests coming in through ISP2, source NAT the incoming traffic's source IP with IPs on firewall inside interface, that way when server replies, firewall 2.2.2.1 will guarantee to receive the ACK because ACK traffic won't follow default routing to ISP1. On Thu, May 27, 2010 at 4:27 PM, Ken Gilmour ken.gilm...@gmail.com wrote: Hi all, I have a very peculiar situation here that i seem to have difficulty explaining in such a way for people to understand. I just got off the phone to the Juniper Devs after about 4 hours with no result. They understand the problem but can't seem to think of a working solution (last solution led to the primary firewall hard crashing and then failing over after a commit (which also makes me wonder what made the primary crash and not the secondary)). I am wondering if there is anyone creative on the list who has encountered and worked around this problem before... Here goes *sigh* ISP1 - 1.1.1.0/24 ISP2 - 2.2.2.0/24 ISP1 is the default gateway, ISP2 is a backup provider but which is always active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. Client comes in on ISP2's link (non default gateway) but for some reason, the packets seem to be going back out through the link for ISP1. So look at it this way: SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by the firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in TCPDump, the firewall at 2.2.2.1 never sees it. Here's a log snippet (I can send you more if you need: May 27 21:38:49 21:38:48.1509569:CID-1:RT: route lookup: dest-ip 3.3.3.3 *orig ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 You will see that the orig and out zones are the same zone, however this was a last ditch effort (putting both interfaces into one zone, effectively creating a swamp). Our current (non-preferred) solution is to put match-all rules on our Catalyst 6513s and put both providers into a swamp and the switch will then intercept the packets if they are destined for the wrong interface and send them out the right one based on a bunch of boolean. We've tried setting up a virtual instance on the offending interface and a firewall filter, but this had little to no effect (at one point it stopped passing the packets to the end machine altogether). We're using small SRX 650ies. Why do we want to do it this way you ask? In the event of a BGP session failure we need to be able to use our statically routed IPs and rely on someone else. Thanks! Ken
Re: Junos Asymmetric Routing
Wouldn't simply configure source NAT on firewall 2.2.2.1 resolve the problem gracefully? when connection requests coming in through ISP2, source NAT the incoming traffic's source IP with IPs on firewall inside interface, that way when server replies, firewall 2.2.2.1 will guarantee to receive the ACK because ACK traffic won't follow default routing to ISP1. On Thu, May 27, 2010 at 4:27 PM, Ken Gilmour ken.gilm...@gmail.com wrote: Hi all, I have a very peculiar situation here that i seem to have difficulty explaining in such a way for people to understand. I just got off the phone to the Juniper Devs after about 4 hours with no result. They understand the problem but can't seem to think of a working solution (last solution led to the primary firewall hard crashing and then failing over after a commit (which also makes me wonder what made the primary crash and not the secondary)). I am wondering if there is anyone creative on the list who has encountered and worked around this problem before... Here goes *sigh* ISP1 - 1.1.1.0/24 ISP2 - 2.2.2.0/24 ISP1 is the default gateway, ISP2 is a backup provider but which is always active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. Client comes in on ISP2's link (non default gateway) but for some reason, the packets seem to be going back out through the link for ISP1. So look at it this way: SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by the firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in TCPDump, the firewall at 2.2.2.1 never sees it. Here's a log snippet (I can send you more if you need: May 27 21:38:49 21:38:48.1509569:CID-1:RT: route lookup: dest-ip 3.3.3.3 *orig ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 You will see that the orig and out zones are the same zone, however this was a last ditch effort (putting both interfaces into one zone, effectively creating a swamp). Our current (non-preferred) solution is to put match-all rules on our Catalyst 6513s and put both providers into a swamp and the switch will then intercept the packets if they are destined for the wrong interface and send them out the right one based on a bunch of boolean. We've tried setting up a virtual instance on the offending interface and a firewall filter, but this had little to no effect (at one point it stopped passing the packets to the end machine altogether). We're using small SRX 650ies. Why do we want to do it this way you ask? In the event of a BGP session failure we need to be able to use our statically routed IPs and rely on someone else. Thanks! Ken
Re: useful bgp example
You don't need ip prefix-list NETZ seq 1000 deny 0.0.0.0/0 le 32 You can use RFC1918 space address for iBGP peering. On Wed, May 19, 2010 at 11:37 AM, Jeff Harper jhar...@first-american.net wrote: -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Wednesday, May 19, 2010 1:29 PM To: Jeff Harper Cc: Deric Kwok; nanog@nanog.org Subject: Re: useful bgp example Nice, but you don't show it as-path filtering your transits out. I frequently see people take something learned from transit A and sending it to transit B, and if it happens to be the backup path in-use for your customer, your transits will accept it and likely pick you as best-path and hairpin through your network. - Jared Yeah, I left out the actual prefix-list contents, in hindsight I should have added it, so here it is. Also, a typo in the network statement, lol. network 1.1.1.0 mask 255.255.0.0 ip prefix-list NETZ description The networks we advertise via BGP ip prefix-list NETZ seq 10 permit 1.1.1.0/16 ip prefix-list NETZ seq 1000 deny 0.0.0.0/0 le 32
Re: Gig Throughput on IPSEC
You can run L2TPv3 (available on IOS routers) between sites, not sure about the throughput though. On Wed, Nov 11, 2009 at 2:01 AM, a...@baklawasecrets.com wrote: On second thoughts, thinking about this I am probably looking for some kind of Layer2 encryption devices. This will make things a lot easier for the deployment. Any experiences, thoughts on these types of devices, would be much appreciated. Adel On Wed 9:25 AM , a...@baklawasecrets.com sent: Hi, I have a requirement to encrypt data using IPSEC over a p-t-p gig fibre link. In the past I've normally used Juniper to terminate VPNs, as I have found them excellent devices and the route based VPN functionality very useful. However looking at their range, only the ISG will do a gig of IPSEC. I'm leaning towards keeping my exising Juniper SSG550's for firewall/routing capability at each site. Then having a separate encryption devices to handle the site-to-site vpn requiring the gig throughput. Does anyone have any suggestions on devices to use? Adel
