Re: [AFMUG] BGP history

2017-07-14 Thread Steve
Also if you use Mikrotik you can log BGP information that takes place.  Any 
keepalives, updates and such.  I just sort through things in splunk or another 
central logging program to narrow down what happened.  

-- 
Steven Kenney
Network Operations Manager
WaveDirect Telecommunications
http://www.wavedirect.net
(519)737-WAVE (9283)

- Original Message -
From: "Steve Jones" <thatoneguyst...@gmail.com>
To: "af" <af@afmug.com>
Sent: Wednesday, July 12, 2017 10:05:42 AM
Subject: [AFMUG] BGP history

I don't know how to use these looking glasses and understand what I'm
seeing, probably pretty simple.
what we have is two upstreems we peer with. Our ASN consists of a /22 we
announce as /24s, two on each provider (bad, I know) what happened this
morning was one upstream seems to have gotten some mud in their pudding and
the interwebs couldn't get to those two /24. Because I'm pretty good at
finding ways to ensure all my practices are bad our network DNS resolvers
were on those two /24 also, so pretty much all our customers are pissed

I ultimately disabled all my static routes internally, added the two /24 to
the provider that wasn't smoking crack and dropped my ospf default route on
the bad router and killed the peering session.

when I added the two, before anything else, it brought everyone back up,
they were going out bad peer 1 and in good guy peer 2, So had I been
running full /22 on both peers I assume we wouldn't have known there was an
issue other than problem calls for stuff that doesn't like assymetric
paths, probably would have resulted in hours of troubleshooting before I
looked at BGP

I get bgpmon alerts, but have received none this morning


how can I look back historically to see what of mine was being announced
where and by whom?

and whats the best free or low cost monitoring that I can get good alerts
on?

This may turn out not to have been a BGP issue, the upstream may have just
stubbed their toe


Re: [AFMUG] BGP history

2017-07-12 Thread Steve Jones
yep
Im tempted sometimes to backhaul to my house and connect us to my mediacom
home connection, its more reliable than the fiber we pay too much for

On Wed, Jul 12, 2017 at 12:52 PM, Micah Miller <mi...@nbson.com> wrote:

> Steve,
> At bit OT but Is one of your peers mediacom by chance?
>
> On Wed, Jul 12, 2017 at 9:30 AM, Larry Smith <lesm...@ecsis.net> wrote:
> > http://bgplay.routeviews.org
> >
> > On Wed July 12 2017 09:07, Mike Hammett wrote:
> >> RIPE Stat
> >> Route Views
> >>
> >>
> >>
> >> -
> >> Mike Hammett
> >> Intelligent Computing Solutions
> >>
> >> Midwest Internet Exchange
> >>
> >> The Brothers WISP
> >>
> >>
> >>
> >>
> >> - Original Message -
> >>
> >> From: "Steve Jones" <thatoneguyst...@gmail.com>
> >> To: af@afmug.com
> >> Sent: Wednesday, July 12, 2017 9:05:42 AM
> >> Subject: [AFMUG] BGP history
> >>
> >>
> >>
> >> I don't know how to use these looking glasses and understand what I'm
> >> seeing, probably pretty simple. what we have is two upstreems we peer
> with.
> >> Our ASN consists of a /22 we announce as /24s, two on each provider
> (bad, I
> >> know) what happened this morning was one upstream seems to have gotten
> some
> >> mud in their pudding and the interwebs couldn't get to those two /24.
> >> Because I'm pretty good at finding ways to ensure all my practices are
> bad
> >> our network DNS resolvers were on those two /24 also, so pretty much all
> >> our customers are pissed
> >>
> >>
> >> I ultimately disabled all my static routes internally, added the two
> /24 to
> >> the provider that wasn't smoking crack and dropped my ospf default
> route on
> >> the bad router and killed the peering session.
> >>
> >>
> >> when I added the two, before anything else, it brought everyone back up,
> >> they were going out bad peer 1 and in good guy peer 2, So had I been
> >> running full /22 on both peers I assume we wouldn't have known there
> was an
> >> issue other than problem calls for stuff that doesn't like assymetric
> >> paths, probably would have resulted in hours of troubleshooting before I
> >> looked at BGP
> >>
> >>
> >> I get bgpmon alerts, but have received none this morning
> >>
> >>
> >>
> >>
> >> how can I look back historically to see what of mine was being announced
> >> where and by whom?
> >>
> >>
> >> and whats the best free or low cost monitoring that I can get good
> alerts
> >> on?
> >>
> >>
> >> This may turn out not to have been a BGP issue, the upstream may have
> just
> >> stubbed their toe
> >
> > --
> > Larry Smith
> > lesm...@ecsis.net
>
>
>
> --
> Micah Miller
> Network/Server Administrator
> Network Business Systems, Inc.
> Phone: 309-944-8823
>


Re: [AFMUG] BGP history

2017-07-12 Thread Micah Miller
Steve,
At bit OT but Is one of your peers mediacom by chance?

On Wed, Jul 12, 2017 at 9:30 AM, Larry Smith <lesm...@ecsis.net> wrote:
> http://bgplay.routeviews.org
>
> On Wed July 12 2017 09:07, Mike Hammett wrote:
>> RIPE Stat
>> Route Views
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>>
>> Midwest Internet Exchange
>>
>> The Brothers WISP
>>
>>
>>
>>
>> - Original Message -
>>
>> From: "Steve Jones" <thatoneguyst...@gmail.com>
>> To: af@afmug.com
>> Sent: Wednesday, July 12, 2017 9:05:42 AM
>> Subject: [AFMUG] BGP history
>>
>>
>>
>> I don't know how to use these looking glasses and understand what I'm
>> seeing, probably pretty simple. what we have is two upstreems we peer with.
>> Our ASN consists of a /22 we announce as /24s, two on each provider (bad, I
>> know) what happened this morning was one upstream seems to have gotten some
>> mud in their pudding and the interwebs couldn't get to those two /24.
>> Because I'm pretty good at finding ways to ensure all my practices are bad
>> our network DNS resolvers were on those two /24 also, so pretty much all
>> our customers are pissed
>>
>>
>> I ultimately disabled all my static routes internally, added the two /24 to
>> the provider that wasn't smoking crack and dropped my ospf default route on
>> the bad router and killed the peering session.
>>
>>
>> when I added the two, before anything else, it brought everyone back up,
>> they were going out bad peer 1 and in good guy peer 2, So had I been
>> running full /22 on both peers I assume we wouldn't have known there was an
>> issue other than problem calls for stuff that doesn't like assymetric
>> paths, probably would have resulted in hours of troubleshooting before I
>> looked at BGP
>>
>>
>> I get bgpmon alerts, but have received none this morning
>>
>>
>>
>>
>> how can I look back historically to see what of mine was being announced
>> where and by whom?
>>
>>
>> and whats the best free or low cost monitoring that I can get good alerts
>> on?
>>
>>
>> This may turn out not to have been a BGP issue, the upstream may have just
>> stubbed their toe
>
> --
> Larry Smith
> lesm...@ecsis.net



-- 
Micah Miller
Network/Server Administrator
Network Business Systems, Inc.
Phone: 309-944-8823


Re: [AFMUG] BGP history

2017-07-12 Thread Larry Smith
http://bgplay.routeviews.org

On Wed July 12 2017 09:07, Mike Hammett wrote:
> RIPE Stat
> Route Views
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
>
> Midwest Internet Exchange
>
> The Brothers WISP
>
>
>
>
> - Original Message -
>
> From: "Steve Jones" <thatoneguyst...@gmail.com>
> To: af@afmug.com
> Sent: Wednesday, July 12, 2017 9:05:42 AM
> Subject: [AFMUG] BGP history
>
>
>
> I don't know how to use these looking glasses and understand what I'm
> seeing, probably pretty simple. what we have is two upstreems we peer with.
> Our ASN consists of a /22 we announce as /24s, two on each provider (bad, I
> know) what happened this morning was one upstream seems to have gotten some
> mud in their pudding and the interwebs couldn't get to those two /24.
> Because I'm pretty good at finding ways to ensure all my practices are bad
> our network DNS resolvers were on those two /24 also, so pretty much all
> our customers are pissed
>
>
> I ultimately disabled all my static routes internally, added the two /24 to
> the provider that wasn't smoking crack and dropped my ospf default route on
> the bad router and killed the peering session.
>
>
> when I added the two, before anything else, it brought everyone back up,
> they were going out bad peer 1 and in good guy peer 2, So had I been
> running full /22 on both peers I assume we wouldn't have known there was an
> issue other than problem calls for stuff that doesn't like assymetric
> paths, probably would have resulted in hours of troubleshooting before I
> looked at BGP
>
>
> I get bgpmon alerts, but have received none this morning
>
>
>
>
> how can I look back historically to see what of mine was being announced
> where and by whom?
>
>
> and whats the best free or low cost monitoring that I can get good alerts
> on?
>
>
> This may turn out not to have been a BGP issue, the upstream may have just
> stubbed their toe

-- 
Larry Smith
lesm...@ecsis.net


Re: [AFMUG] BGP history

2017-07-12 Thread Mike Hammett
RIPE Stat 
Route Views 



- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 




- Original Message -

From: "Steve Jones" <thatoneguyst...@gmail.com> 
To: af@afmug.com 
Sent: Wednesday, July 12, 2017 9:05:42 AM 
Subject: [AFMUG] BGP history 



I don't know how to use these looking glasses and understand what I'm seeing, 
probably pretty simple. 
what we have is two upstreems we peer with. Our ASN consists of a /22 we 
announce as /24s, two on each provider (bad, I know) what happened this morning 
was one upstream seems to have gotten some mud in their pudding and the 
interwebs couldn't get to those two /24. Because I'm pretty good at finding 
ways to ensure all my practices are bad our network DNS resolvers were on those 
two /24 also, so pretty much all our customers are pissed 


I ultimately disabled all my static routes internally, added the two /24 to the 
provider that wasn't smoking crack and dropped my ospf default route on the bad 
router and killed the peering session. 


when I added the two, before anything else, it brought everyone back up, they 
were going out bad peer 1 and in good guy peer 2, So had I been running full 
/22 on both peers I assume we wouldn't have known there was an issue other than 
problem calls for stuff that doesn't like assymetric paths, probably would have 
resulted in hours of troubleshooting before I looked at BGP 


I get bgpmon alerts, but have received none this morning 




how can I look back historically to see what of mine was being announced where 
and by whom? 


and whats the best free or low cost monitoring that I can get good alerts on? 


This may turn out not to have been a BGP issue, the upstream may have just 
stubbed their toe 


[AFMUG] BGP history

2017-07-12 Thread Steve Jones
I don't know how to use these looking glasses and understand what I'm
seeing, probably pretty simple.
what we have is two upstreems we peer with. Our ASN consists of a /22 we
announce as /24s, two on each provider (bad, I know) what happened this
morning was one upstream seems to have gotten some mud in their pudding and
the interwebs couldn't get to those two /24. Because I'm pretty good at
finding ways to ensure all my practices are bad our network DNS resolvers
were on those two /24 also, so pretty much all our customers are pissed

I ultimately disabled all my static routes internally, added the two /24 to
the provider that wasn't smoking crack and dropped my ospf default route on
the bad router and killed the peering session.

when I added the two, before anything else, it brought everyone back up,
they were going out bad peer 1 and in good guy peer 2, So had I been
running full /22 on both peers I assume we wouldn't have known there was an
issue other than problem calls for stuff that doesn't like assymetric
paths, probably would have resulted in hours of troubleshooting before I
looked at BGP

I get bgpmon alerts, but have received none this morning


how can I look back historically to see what of mine was being announced
where and by whom?

and whats the best free or low cost monitoring that I can get good alerts
on?

This may turn out not to have been a BGP issue, the upstream may have just
stubbed their toe