Anyone with a clue at Zayo?
Have a turnup we've been working on all day and no luck so far. Now we're being told that nobody can help outside hours :( Any help much appreciated. Thanks Pat
ATT - XO Peering (AS7018 and AS2828)
Hi, Please could someone from ATT and/or XO contact me off list to discuss some issues we've been seeing on a link between AS7018 and AS2828. Thanks Pat -- --- Patrick Sumby Director of Global Engineering Sohonet
Re: IRR-clueful person at 3356?
L3 can be tricky with IRR especially if you have objects split across multiple IRR databases. This should help with what filters you want them to put on: http://www.clarksys.com/blog/2009/09/02/using-irr-with-level3/ You can test before using: whois -h filtergen.level3.net RIPE::YOUR-AS-SET -searchpath=RIPE;ARIN;RADB -recurseok -warnonly Regards Patrick On 17/08/2012 16:16, Robert E. Seastrom wrote: Hi folks, Sorry for the extremely broad email but I'm trying to sort out an IRR issue regarding automatic filter generation at Level(3) on behalf of a friend. The telemetry I'm getting (thirdhand and believed to originate from first line support) suggests that both Level(3)'s direct customer and any downstreams of that customer need to be in the same IRR component. If true this would be a rather startling shortcoming of their filter generation software and at odds with the whole point of having multiple components to the IRR system. Anyone got any pointers or help? Email to r...@level3.net has not gotten us anywhere, but I was not the one who sent it and can't guarantee that the right questions were asked. Thanks, -r
Re: BGP and Firewalls...
We run redundant solutions for a number of our customers and have always decoupled the routing and firewalling. I can think of one situation where the customer manages the BGP and firewall failover on their firewalls, it doesn't work too well. The issue as I see it is that in the event of a device failure if you only have firewalls you need to keep the firewall session states when failing over to the second device, the BGP sessions will not if in an active passive HA setup whereas user traffic states will. If you run in an active active setup, BGP states will remain up however user traffic states will not always be transferred. If you're only using one firewall then this is not going to be an issue but it depends if the solution you're deploying has only redundant connectivity or redundant equipment as well. My experience is mainly using Juniper routers and firewalls so not able to comment on the Palo Alto platform. Decoupling the two functions gives a much better model from an NSP sales perspective as it means you're able to sell failover with no managed equipment / just managed routers / full solution with routers and firewalls. -- --- Patrick Sumby Network Architect Sohonet On 07/12/2011 17:31, Gregory Croft wrote: Hi All, Does anyone have any experience with using firewalls as edge devices when BGP is concerned? Specifically the Palo Alto series of devices. If so please contact me off list. Thank you. Thank you, Gregory S. Croft
Re: Is AS information useful for security?
On 15/12/2011 16:28, Drew Weaver wrote: -Original Message- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] Sent: Thursday, December 15, 2011 9:45 AM To: nanog@nanog.org Subject: Re: Is AS information useful for security? origin-AS could be another story. If you know of an AS that is being used by the bad guys for bad purposes, you can write a routing policy to dump all traffic to/from that AS into the bit bucket or take some other action that could be dictated by your security policy. In that case, a routing policy could beconsidered an extension of a security policy. I could be wrong here but I believe origin-AS uses a lookup from the routing table to figure out what the originAS for the source IP should be (and not what it explicitly IS) which means the information is unreliable. For example if someone is sending spoofed packets towards you the origin AS will always show up as the originator of the real route instead of the origin AS of the actual traffic. This is why it would be useful to have the originAS (from the actual origin) in the packet header. How would you determine and enforce this? Ok so a packet leaves my network that I know originated from my network based on some factor (IGP route existing or matched prefix list) and the origin AS is put into a new field in the packet header... Whats to stop the spoofer putting that origin AS into their spoofed packet headers? This means that another level of checking then needs to be put into inter AS BGP sessions to make sure that all traffic passing across the link would need to be checked to make sure origin ASs are matched. Couldn't most of the same protection be solved by more people running BCP38 and RPKI? Thanks, -Drew
Re: the route is not in our bgprouter
On Tue, Oct 25, 2011 at 9:49 PM, Deric Kwokderic.kwok2...@gmail.com wrote: Our upstream provider said that destination network is blocking our ip. Now my question is how we can know it you can't really, if they do things right. (Aside from just not getting there) Have you tried contacting the destination network. I assume you have a customer that wants to talk to their customer? Its in both your interests to see why things aren't working. If this network is blocking us, the traceroute should reach out our bgp router to go further nodes before that network, right presumably, unless the destination is a direct peer. 2nd question is how they block us to not allow the route to advertise from our upstream to our bgp router. probably they just don't accept your route... why do you think your route isn't propogated beyond your border(s)? What is your prefix that you're announcing? Is it from a new range an potentially bogon filtered somehwere? What is the destination you're trying to get to? What do you see in BGP looking glasses for that IP. They could be doing something stupid/evil like putting your AS in their path. ls it possible? Thank you so much On Tue, Oct 25, 2011 at 9:35 AM, Patrick Sumby patrick.su...@sohonet.co.uk wrote: If your provider has a looking glass then that is a good start to see if they have the route in their routing tables. http://www.traceroute.org/ is a good start for searching for a looking glass on their website. Have you checked to see if you're actually recieving the route? You may be getting the route but not installing it into your routing table for some reason (eg invalid next hop or a router from another provider is being prefered). Do you have prefix lists inbound from your provider that could be blocking a route? show ip route X.X.X.X and show ip bgp route X.X.X.X will give different information. If you've covered the above and not found the answer then try talking to your provider. Regards Patrick On 25/10/2011 13:26, Deric Kwok wrote: Hi When we try to reach to outside ip, this route doesn't have in our bgp router How can we check whether it doesn't advertise from our upstream to us? Any web site and tools can help? Thank you
Re: the route is not in our bgprouter
If your provider has a looking glass then that is a good start to see if they have the route in their routing tables. http://www.traceroute.org/ is a good start for searching for a looking glass on their website. Have you checked to see if you're actually recieving the route? You may be getting the route but not installing it into your routing table for some reason (eg invalid next hop or a router from another provider is being prefered). Do you have prefix lists inbound from your provider that could be blocking a route? show ip route X.X.X.X and show ip bgp route X.X.X.X will give different information. If you've covered the above and not found the answer then try talking to your provider. Regards Patrick On 25/10/2011 13:26, Deric Kwok wrote: Hi When we try to reach to outside ip, this route doesn't have in our bgp router How can we check whether it doesn't advertise from our upstream to us? Any web site and tools can help? Thank you
Re: Facebook insecure by design
On 02/10/2011 19:01, Michael Thomas wrote: William Allen Simpson wrote: On 10/2/11 12:36 PM, Jimmy Hess wrote: On Sun, Oct 2, 2011 at 10:38 AM, Michael Thomasm...@mtcc.com wrote: I'm not sure why lack of TLS is considered to be problem with Facebook. The man in the middle is the other side of the connection, tls or otherwise. That's where the X509 certificate comes in. A man in the middle would not have the proper private key to impersonate the Facebook server that the certificate was issued to. My understanding of his statement is that Facebook itself is the MITM, collecting all our personal information. Too true. Bingo. Mike +1
Re: So... is it time to do IPv6 day monthy yet?
+1 I've enjoyed it so far! On 08/06/2011 16:07, Ryan Pavely wrote: I was thinking the same thing. Good call :) Ryan Pavely Net Access Corporation http://www.nac.net/ On 6/8/2011 10:40 AM, Jay Ashworth wrote: It certainly sounds like it might be. Cheers, -- jra
Re: Using IPv6 with prefixes shorter than a /64 on a LAN
On 24/01/2011 22:41, Michael Loftis wrote: On Mon, Jan 24, 2011 at 1:53 PM, Ray Soucyr...@maine.edu wrote: Many cite concerns of potential DoS attacks by doing sweeps of IPv6 networks. I don't think this will be a common or wide-spread problem. The general feeling is that there is simply too much address space for it to be done in any reasonable amount of time, and there is almost nothing to be gained from it. The problem I see is the opening of a new, simple, DoS/DDoS scenario. By repetitively sweeping a targets /64 you can cause EVERYTHING in that /64 to stop working by overflowing the ND/ND cache, depending on the specific ND cache implementation and how big it is/etc. Routers can also act as amplifiers too, DDoSing every host within a multicast ND directed solicitation group (and THAT is even assuming a correctly functioning switch thats limiting the multicast travel) Add to it the assumption that every router gets certain things right (like everything correctly decrementing TTLs as assumed in RFC 4861 11.2 in order for hosts to detect off-link RA/ND messages and guard themselves against those), in these ways it's certainly at least somewhat worse than ARP. If you're able to bring down, or severely limit, a site by sending a couple thousand PPS towards the /64 it's on, or by varying the upper parts of the /64 to flood all the hosts with multicast traffic while simultaneously floodign the routers LRU ND cache well thats a cheap and easy attack and it WILL be used, and that can be done with the protocols working as designed, at least from my reading. Granted I don't have an IPv6 lab to test any of this. But I'd be willing to bet this exact scenario is readily and easily possible, it already is with ARP tables (and it DOES happen, it's just harder to make happen with ARP and IPv4 since the space is so small, esp when compared to a /64) IPv6 ND LRU Caches/tables aren't going to be anywhere near big enough to handle a single /64's worth of hosts. And if they're any significant amt smaller then it'd be trivial to cause a DoS by sweeping the address space. It would depend on the ND table limits/sizes, and any implementation specific timers/etc and garbage collection, and a some other details I don't have, but, I bet it'd be a really small flow in the scheme of things to completely stomp out a /64someone I'm sure knows more about the implementations, and I'm betting this has been brought up before about IPv6/ND... So I pretty strongly disagree about your statement. Repetitively sweeping an IPv6 network to DoS/DDoS the ND protocol thereby flooding the ND cache/LRUs could be extremely effective and if not payed serious attention will cause serious issues. Yes This is an issue for point-to-point links but using a longer prefix (/126 or similar) has been suggested as a mitigation for this sort of attack. I would assume that in the LAN scenario where you have a /64 for your internal network that you would have some sort of stateful firewall sitting infront of the network to stop any un-initiated sessions. This therefore stops any hammering of ND cache etc. The argument then is that the number of packets hitting your firewall / bandwidth starvation would be the the alternative line of attack for a DoS/DDos but that is a completely different issue.
