Yes, we split our IP space between them. Im still learning the finer points of OSPF, For a control freak, moving from the comfort of static routes across the network to letting some machine make decisions for me is emasculating, So I need to make the OSPF bow before me and call me master, then I will tackle the BGP with a ball gag and whip
On Mon, Oct 19, 2015 at 2:11 PM, Mike Hammett <[email protected]> wrote: > Do you have more than one upstream? Hard to tell from the message. If so, > learn BGP with a quickness. ;-) > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ------------------------------ > *From: *"That One Guy /sarcasm" <[email protected]> > *To: *[email protected] > *Sent: *Monday, October 19, 2015 2:09:12 PM > *Subject: *Re: [AFMUG] Eoip and mpls > > > I plan on MPLS internally over the OSPF network, at least I think thats > what I should do. We have a bunch of customers with more than two sites > that would benefit. > > Right now, for the upstream tunnel, since we dont currently have any BGP, > I am planning on the EOIP tunnel being part of the OSPF network to fail > bandwidth over to the right statically routed upstream provider for the > ARIN space, Assuming we dont lose a provider at the same time as we lose a > primary backhaul, this should keep customer traffic flowing, albeit with > more hops. This is on RB1100ahx2 routers with traffic never exceeding > 200mbps either way. > > Noting that we dont currently have BGP, so that not being an option, how > bad is what im doing in terms of networking 101 political correctness? > > On Mon, Oct 19, 2015 at 1:30 PM, [email protected] < > [email protected]> wrote: > >> You can layer EoIP over top of another VPN for security and I usually use >> PPTP for this as I can see if the link is connected and >> for how long. If you aren't familiar with MPLS, EoIP is a lot easier to >> debug and doesn't require your entire network to be running >> MPLS. >> >> Running across CCRs, I can't tell the difference in performance or CPU >> load between EoIP and MPLS/VPLS with 200Mbps of traffic. >> If you are doing just a customer or two, I'd use EoIP. If you plan on >> offering this to a larger customer base, switch to MPLS. >> >> On Mon, Oct 19, 2015 at 1:40 PM, Adam Moffett <[email protected]> >> wrote: >> >>> Wow cool. >>> >>> >>> On 10/19/2015 1:37 PM, Mathew Howard wrote: >>> >>> Here we go - from the .30 changelog: >>> >>> *) tunnels - eoip, eoipv6, gre,gre6, ipip, ipipv6, 6to4 tunnels >>> have new property - ipsec-secret - for easy setup of ipsec >>> encryption and authentication; >>> >>> On Mon, Oct 19, 2015 at 12:34 PM, Mathew Howard <[email protected]> >>> wrote: >>> >>>> I'm pretty sure you can use encryption with EoIP these days... it's a >>>> fairly recent addition, if I remember right. >>>> >>>> On Mon, Oct 19, 2015 at 12:29 PM, That One Guy /sarcasm < >>>> [email protected]> wrote: >>>> >>>>> So what is this doing? >>>>> >>>>> *ipsec-secret* (*string*; Default: ) When secret is specified, router >>>>> adds dynamic ipsec peer to remote-address with pre-shared key and policy >>>>> with default values (by default phase2 uses sha1/aes128cbc). Both >>>>> local-address and remote-address of the tunnel must be specified for >>>>> router >>>>> to create valid ipsec policy. >>>>> >>>>> On Mon, Oct 19, 2015 at 12:04 PM, Adam Moffett <[email protected]> >>>>> wrote: >>>>> >>>>>> 100% less secure. There's no encryption at all in EoIP. >>>>>> >>>>>> >>>>>> On 10/19/2015 11:44 AM, That One Guy /sarcasm wrote: >>>>>> >>>>>> in the mikrotik implementation with ipsec, how much less "secure" >>>>>> than something like an ipsec VPN tunnel? For the most part, since its all >>>>>> routed traffic anyway, security isnt all that great a concern, other than >>>>>> maybe some snmp strings I cant think of much that would matter >>>>>> >>>>>> We do have an instance, Im assuming MPLS will be what would be best, >>>>>> the customer has a 10mb ptp fiber connection from another provider >>>>>> terminated in our NOC as a backup to their DIA with us over our wireless >>>>>> infrastructure, but I dont know, its all new to me >>>>>> >>>>>> On Mon, Oct 19, 2015 at 8:54 AM, Adam Moffett < <[email protected]> >>>>>> [email protected]> wrote: >>>>>> >>>>>>> EoIP is non-standard, and while multiple platforms have it, they are >>>>>>> probably not compatible. >>>>>>> >>>>>>> The main reason to do EoIP is if you need the entire layer2 header. >>>>>>> I use it now and then to default a device, then bridge it's port with an >>>>>>> EOIP tunnel back to my office so that I can access it from my laptop on >>>>>>> it's default IP. >>>>>>> >>>>>>> You can also carry a full size 1500 byte packet on the EoIP >>>>>>> tunnel....it will be fragmented on the outer layer so there's an >>>>>>> efficiency >>>>>>> penalty in doing so, so if everything works with a shorter MTU then use >>>>>>> a >>>>>>> shorter MTU. I switched a VPN to an EOIP tunnel for a library whose >>>>>>> SonicWall broke PMTUD and thus there was packet loss on the tunneled >>>>>>> traffic until I switched them to EoIP. >>>>>>> >>>>>>> The other reason to do EoIP is that it's stupid simple. >>>>>>> >>>>>>> Downsides: EoIP is insecure. Supposedly it's more cpu intensive >>>>>>> than other types of tunnels, but in practice I haven't noticed. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10/19/2015 2:28 AM, That One Guy /sarcasm wrote: >>>>>>> >>>>>>>> >>>>>>>> More interested in eoip comments, but when are these two bad ideas, >>>>>>>> eoip with the ipsec in particular. >>>>>>>> I have two scenarios where eoip will be necessary to maintain >>>>>>>> upstream static routing between providers, one tunnel over the >>>>>>>> interwebs >>>>>>>> and one tunnel over our network since our providers are geographically >>>>>>>> isolated. >>>>>>>> I'm having a hard time figuring out if eoip is up and coming or >>>>>>>> dying, everything I read says its new but the documents are old, >>>>>>>> mikrotik >>>>>>>> documents indicate it's proprietary but Cisco docs mention it. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> If you only see yourself as part of the team but you don't see your >>>>>> team as part of yourself you have already failed as part of the team. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> If you only see yourself as part of the team but you don't see your >>>>> team as part of yourself you have already failed as part of the team. >>>>> >>>> >>>> >>> >>> >> > > > -- > If you only see yourself as part of the team but you don't see your team > as part of yourself you have already failed as part of the team. > > -- If you only see yourself as part of the team but you don't see your team as part of yourself you have already failed as part of the team.
