Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment

[Gino O'Donnell]

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html

On 2/24/15 10:59 AM, Blair Trosper wrote:
> In VPC, you can also designate
> your own subnets, which makes things a little more tough a la
> interconnecting the disparate regions.
> 
> On Tue, Feb 24, 2015 at 12:27 PM, Luan Nguyen  wrote:
> 
>> Shouldn't it be the other way around? Ipv6 as the unique universal
>> external network and you can define your own IPv4 within your cloud context
>> separate from the cloud provider network and from other customers. So if
>> you have contexts in different region - you can interconnect using layer 3
>> or layer 2 - through the cloud provider network...bring your own IPv4. If
>> you need internet access, you'll get NATted. If you need connections to
>> your branches/HQs...etc, build your own tunnel or use the cloud provider -
>> which by the way gives you your own vrf so no need to worry about
>> overlapping anything.
>> Noone heard of Dimension Data Cloud? :)
>>
>> On Tue, Feb 24, 2015 at 1:10 PM, Blair Trosper 
>> wrote:
>>
>>> ADDENDUM:  They're taking into consideration my suggestion of using IPv6
>>> as
>>> a "universal" internal network so that the different regions could be
>>> interconnected without having to give up the region-independent use of
>>> 10.0.0.0/8, which I think would be an elegant solution.
>>>
>>> On Tue, Feb 24, 2015 at 12:08 PM, Blair Trosper 
>>> wrote:
>>>
 I have an unimpeachable source at AWS that assures me they're working
>>> hard
 to deploy IPv6.  As it was explained to me, since AWS was sort of first
>>> to
 the table -- well before IPv6 "popped", they had designed everything on
>>> the
 v4 only.  Granted, you can get an IPv6 ELB, but only in EC2 classic,
>>> which
 they're phasing out.

 But I'm assured they're rushing IPv6 deployment of CloudFront and other
 services as fast as they can.  I'm assured of this.

 But you also have to appreciate the hassle of retrofitting a cloud
 platform of that scale, so I do not envy the task that AWS is
>>> undertaking.

 On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong  wrote:

> Amazon is not the only public cloud.
>
> There are several public clouds that can support IPv6 directly.
>
> I have done some work for and believe these guys do a good job:
>
> Host Virtual (vr.org )
>
> In no particular order and I have no relationship with or loyalty or
> benefit associated with any of them. I neither endorse, nor decry any
>>> of
> the following:
>
> Linode
> SoftLayer
> RackSpace
>
> There are others that I am not recalling off the top of my head.
>
> Owen
>
>> On Feb 23, 2015, at 07:52 , Ca By  wrote:
>>
>> On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann 
> wrote:
>>
>>> Currently engaged on a project where they’re building out a VPC
>>> infrastructure for hosted applications.
>>>
>>> Users access apps in the VPC, not the other direction.
>>>
>>> The issue I'm trying to get around is the customers who need to
>>> connect
>>> have multiple overlapping RFC1918 space (including overlapping what
>>> was
>>> proposed for the VPC networks).  Finding a hole that is big enough
>>> and
> not
>>> in use by someone else is nearly impossible AND the customers could
>>> go
>>> through mergers which make them renumber even more in to overlapping
> 1918
>>> space.
>>>
>>> Initially, I was looking at doing something like (example IP’s):
>>>
>>>
>>> Customer A (172.28.0.0/24)  <—> NAT to 100.127.0.0/28 <——> VPN to
>>> DC
> <——>
>>> NAT from 100.64.0.0/18 <——>  VPC Space (was 172.28.0.0/24)
>>>
>>> Classic overlapping subnets on both ends with allocations out of
>>> 100.64.0.0/10 to NAT in both directions.  Each sees the other end
>>> in
>>> 100.64 space, but the mappings can get tricky and hard to keep
>>> track of
>>> (especially if you’re not a network engineer).
>>>
>>>
>>> In spitballing, the boat hasn’t sailed too far to say “Why not use
>>> 100.64/10 in the VPC?”
>>>
>>> Then, the customer would be allocated a /28 or larger (depending on
> needs)
>>> to NAT on their side and NAT it once.  After that, no more NAT for
>>> the
> VPC
>>> and it boils down to firewall rules.  Their device needs to NAT
> outbound
>>> before it fires it down the tunnel which pfSense and ASA’s appear
>>> to be
>>> able to do.
>>>
>>> I prototyped this up over the weekend with multiple VPC’s in
>>> multiple
>>> regions and it “appears” to work fine.
>>>
>>> From the operator community, what are the downsides?
>>>
>>> Customers are businesses on dedicated business services vs. consumer
> cable
>>> modems (although there are a few on business class cable).  Others
>>> are
> on
>>> MPLS and I’m hashing that out.

Re: Parsing Syslog and Acting on it, using other input too

[Gino O'Donnell]

Check out Sagan: http://sagan.quadrantsec.com/

On 8/29/13 6:03 AM, Kasper Adel wrote:
> Hello.
> 
> I am looking for a way to do proactive monitoring of my network, what I am
> specifically thinking about is receiving syslog msgs from the routers and
> the backend engine would correlate certain msgs with output/data that i am
> receiving through SSH/telnet sessions. What i am after is not exposed to
> SNMP so i need to do it on my own.
> 
> 
> I am sure there are many tools that can do parsing of syslog and acting
> upon it but i wonder if there is something more flexible out there that I
> can just re-use to do the above ? Please point me to known public or
> home-grown scripts in use to achieve this.
> 
> Regards,
> 
> Sam
>