you are touching on something interesting...
by default, bgp is a slower reacting process, which in your case you are using
as an advantage, but can also be a disadvantage.
however by the same token you OSPF is supposed to be faster reacting.. on one
hand you are expecting the fast reaction of the OSPF to hide underlying (l2)
issues, but on the other hand you are making the case that BGP is stable..
Yes from a routing table change basis that would be true, however if there are
l2 issues causing ospf to change paths, you would be seeing actual issues on
the physical path...
Quiet possible that by the time someone notices or tries to identify it , the
problem may not be visible.
it has it's pro's and con's
Interesting ...
Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232
Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
> From: "Bruce Robertson" <br...@pooh.com>
> To: af@afmug.com
> Sent: Saturday, August 27, 2016 6:26:09 PM
> Subject: Re: [AFMUG] (OSPF + ibgp) / formerly Mikrotik OSPF weirdness
> More elucidation: This assumes you're using router loopback addresses as your
> next hops. BGP doesn't care how you get to your loopbacks, just so that you
> *can* get to them. If your network is designed with redundant paths to each
> loopback, and the state of those paths is handled by OSPF, BGP will never know
> there was a link state change, and your customers won't drop a packet.
> (Assuming, of course, that OSPF can instantly recognize that a link is down -
> no problem with point-to-point Ethernet-type interfaces, but there are some
> OSPF enhancements that solve that problem for link layers that don't give an
> instant indication of problems.)
> On 08/27/2016 03:19 PM, Bruce Robertson wrote:
>> But why even go there? OSPF is a *link state* protocol. BGP is designed for
>> passing prefixes around *regardless* of the link state. Use each protocol for
>> what it was meant for, and happiness will ensue. Do you really want customer
>> reachability information propagating throughout your entire network? All you
>> need is OSPF propagating link state, which is relatively a much smaller size
>> of
>> possibilities. BGP then stays stable, and doesn't even notice the change.
>> What
>> if one router has hundreds of customers with unique (non-pool) customers on
>> it?
>> OSPF will propagate *all* of these customers on every link state change. BGP
>> won't send a single update.
>> On 08/26/2016 03:01 PM, Faisal Imtiaz wrote:
>>> >> As you grow, you'll find it won't scale well.
>>> Care to elaborate more on this ?
>>> By definition it is pointed out that putting hundreds of routers or
>>> hundreds of
>>> routes are a weak point of OSPF, however there are many different techniques
>>> available to manage that.
>>> Regards.
>>> Faisal Imtiaz
>>> Snappy Internet & Telecom
>>> 7266 SW 48 Street
>>> Miami, FL 33155
>>> Tel: 305 663 5518 x 232
>>> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
>>>> From: "Bruce Robertson" <br...@pooh.com>
>>>> To: af@afmug.com
>>>> Sent: Friday, August 26 , 2016 5:23:14 PM
>>>> Subject: Re: [AFMUG] (OSPF + ibgp) / formerly Mikrotik OSPF weirdness
>>>> As you grow, you'll find it won't scale well.
>>>> On 08/26/2016 02:21 PM, George Skorup wrote:
>>>>> I do redist with OSPF. It works fine if you know what you're doing. MT
>>>>> OSPF used
>>>>> to act really stupid until ROS v6.27 or thereabouts.
>>>>> On 8/26/2016 2:16 PM, Faisal Imtiaz wrote:
>>>>>> So just for the sake of a technical discussion...
>>>>>> In your opinion, what is the merit of such a config (osfp + ibgp) ?
>>>>>> It can be argued that such a config,
>>>>>> a) Still depends on OSPF functioning.
>>>>>> b) Layer an additional dynamic protocol on top of it (ibgp)
>>>>>> c) Requires additional Routers (route reflectors).
>>>>>> If the merit of such an approach is to manage manage OSFP behavior in a
>>>>>> more
>>>>>> granular fashion, Why not use the those features as they are available
>>>>>> in OSPF
>>>>>> / Best Practices...
>>>>>> (OSFP best practices, suggest that, don't advertise connected or static
>>>>>> routes,
>>>>>> setup all interfaces as passive, and control prefix advertisements via
>>>>>> the
>>>>>> network section of OSPF).
>>>>>> OSPF also tends to be the most common denominator (protocol) across
>>>>>> different
>>>>>> mfg. Bgp being the 2nd.
>>>>>> Regards
>>>>>> Faisal Imtiaz
>>>>>> Snappy Internet & Telecom
>>>>>> 7266 SW 48 Street
>>>>>> Miami, FL 33155
>>>>>> Tel: 305 663 5518 x 232
>>>>>> Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
>>>>>>> From: "Jesse DuPont" <jesse.dup...@celeritycorp.net>
>>>>>>> To: af@afmug.com
>>>>>>> Sent: Friday, August 26 , 2016 12:03:58 AM
>>>>>>> Subject: Re: [AFMUG] Mikrotik OSPF weirdness
>>>>>>> Right, PTP and loopback prefixes are distributed with OSPF (and possibly
>>>>>>> management subnets for radios) and "access" network prefixes
>>>>>>> (customer-facing)
>>>>>>> are distributed via iBGP.
>>>>>>> I have two of my routers configured as BGP route reflectors and all
>>>>>>> other
>>>>>>> routers peer with only these two; this solves the full mesh and provides
>>>>>>> redundancy.
>>>>>>> Jesse DuPont
>>>>>>> Network Architect
>>>>>>> email: jesse.dup...@celeritycorp.net
>>>>>>> Celerity Networks LLC
>>>>>>> Celerity Broadband LLC
>>>>>>> Like us! facebook.com / celeritynetworksllc
>>>>>>> Like us! facebook.com /celeritybroadband
>>>>>>> On 8/25/16 8:40 PM, David Milholen wrote:
>>>>>>>> He may have meant only have the ptp and loopback addresses listed in
>>>>>>>> networks
>>>>>>>> On 8/25/2016 9:31 PM, Mike Hammett wrote:
>>>>>>>>> I've heard this concept a few times now. I'm not sure how only using
>>>>>>>>> OSPF for
>>>>>>>>> the loopbacks works.
>>>>>>>>> -----
>>>>>>>>> Mike Hammett
>>>>>>>>> Intelligent Computing Solutions
>>>>>>>>> Midwest Internet Exchange
>>>>>>>>> The Brothers WISP
>>>>>>>>> From: "Bruce Robertson" <br...@pooh.com>
>>>>>>>>> To: af@afmug.com
>>>>>>>>> Sent: Thursday, August 25 , 2016 6:28:43 PM
>>>>>>>>> Subject: Re: [AFMUG] Mikrotik OSPF weirdness
>>>>>>>>> I've said it before, and been argued with... this is one of many
>>>>>>>>> reasons why you
>>>>>>>>> use iBGP to distribute {customer, dynamic pool, server subnets,
>>>>>>>>> anything}
>>>>>>>>> routes, and use OSPF *only* to distribute router loopback
>>>>>>>>> addresses.� All
>>>>>>>>> your weird OSPF problems will go away.� My apologies if I'm
>>>>>>>>> misunderstanding
>>>>>>>>> the problem, but my point still stands.
>>>>>>>>> On 08/25/2016 10:22 AM, Robert Haas wrote:
>>>>>>>>>> Alright, this problem has raised it head again on my network since I
>>>>>>>>>> started to
>>>>>>>>>> renumber some PPPoE pools.
>>>>>>>>>> Customer gets a new IP address via PPPoE x.x.x.208/32 (from
>>>>>>>>>> x.x.x.192/27 pool).
>>>>>>>>>> Customer can�t surf and I can�t ping them from my office:
>>>>>>>>>> �
>>>>>>>>>> [office] � [Bernie Router] � [Braggcity Router] � [Ross
>>>>>>>>>> Router] � [Hayti
>>>>>>>>>> Router] � [customer]
>>>>>>>>>> �
>>>>>>>>>> A traceroute from my office dies @ the Bernie router but I am not
>>>>>>>>>> getting any
>>>>>>>>>> type of ICMP response from the Bernie router ie no ICMP Host
>>>>>>>>>> Unreachable/Dest
>>>>>>>>>> unreachable etc � just blackholes after my office router.
>>>>>>>>>> A traceroute from the Customer to the office again dies at the
>>>>>>>>>> Bernie router
>>>>>>>>>> with no type of response.
>>>>>>>>>> �
>>>>>>>>>> Checking the routing table on the Bernie router shows a valid route
>>>>>>>>>> pointing to
>>>>>>>>>> the Braggcity router. It is also in the OSPF LSA�s.
>>>>>>>>>> --
>>>>>>>>>> Another customer gets x.x.x.207/32 and has no issue at all.
>>>>>>>>>> �
>>>>>>>>>> --
>>>>>>>>>> Force the original customer to a new ip address of x.x.x.205/32 and
>>>>>>>>>> the service
>>>>>>>>>> starts working again.
>>>>>>>>>> �
>>>>>>>>>> --
>>>>>>>>>> �
>>>>>>>>>> Now � even though there is no valid route to x.x.x.208/32 in the
>>>>>>>>>> routing table
>>>>>>>>>> � traffic destined to the x.x.x.208/32 IP is still getting
>>>>>>>>>> blackholed.. I
>>>>>>>>>> should be getting a Destination host unreachable from the Bernie
>>>>>>>>>> router.
>>>>>>>>>> �
>>>>>>>>>> This is correct the correct response .206 is not being used and
>>>>>>>>>> there is no
>>>>>>>>>> route to it:
>>>>>>>>>> C:\Users\netadmin>ping x.x.x.206
>>>>>>>>>> �
>>>>>>>>>> Pinging x.x.x.206 with 32 bytes of data:
>>>>>>>>>> Reply from y.y.y.1: Destination host unreachable.
>>>>>>>>>> Reply from y.y.y.1: Destination host unreachable.
>>>>>>>>>> �
>>>>>>>>>> Ping statistics for x.x.x.206:
>>>>>>>>>> ��� Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
>>>>>>>>>> �
>>>>>>>>>> C:\Users\netadmin>tracert 74.91.65.206
>>>>>>>>>> �
>>>>>>>>>> Tracing route to host-x.x.x.206.bpsnetworks.com [x.x.x.206]
>>>>>>>>>> over a maximum of 30 hops:
>>>>>>>>>> �
>>>>>>>>>> � 1���� 6 ms���� 6 ms���� 7 ms� z.z.z.z
>>>>>>>>>> � 2���� 6 ms���� 6 ms���� 6 ms�
>>>>>>>>>> y.bpsnetworks.com
>>>>>>>>>> [y.y.y.1]
>>>>>>>>>> � 3� y.bpsnetworks.com [y.y.y.1] �reports: Destination host
>>>>>>>>>> unreachable.
>>>>>>>>>> �
>>>>>>>>>> Trace complete.
>>>>>>>>>> �
>>>>>>>>>> This is what I see to x.x.x.208 even though it is not being used and
>>>>>>>>>> there is no
>>>>>>>>>> route to it.
>>>>>>>>>> C:\Users\netadmin>ping x.x.x.208
>>>>>>>>>> �
>>>>>>>>>> Pinging x.x.x.208 with 32 bytes of data:
>>>>>>>>>> Request timed out.
>>>>>>>>>> Request timed out.
>>>>>>>>>> �
>>>>>>>>>> Ping statistics for x.x.x.208:
>>>>>>>>>> ��� Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
>>>>>>>>>> �
>>>>>>>>>> C:\Users\netadmin>tracert x.x.x.208
>>>>>>>>>> �
>>>>>>>>>> Tracing route to host-x.x.x.208.bpsnetworks.com [x.x.x.208]
>>>>>>>>>> over a maximum of 30 hops:
>>>>>>>>>> �
>>>>>>>>>> � 1���� 6 ms���� 6 ms���� 6 ms� z.z.z.z
>>>>>>>>>> � 2���� *������� *�������
>>>>>>>>>> *����
>>>>>>>>>> Request timed out.
>>>>>>>>>> � 3���� *������� *���� ^C
>>>>>>>>>> �
>>>>>>>>>> --
>>>>>>>>>> �
>>>>>>>>>> I�ve verified there is no firewall that would affect the traffic
>>>>>>>>>> � I even
>>>>>>>>>> put an accept rule in the forward chain for both the source and
>>>>>>>>>> destination of
>>>>>>>>>> x.x.x.208 and neither increment at all. So the traffic is not even
>>>>>>>>>> making out
>>>>>>>>>> of the routing flow and into the firewall..
>>>>>>>>>> �
>>>>>>>>>> Any pointers are where to start troubleshooting next?
>>>>>>>> --
>> !DSPAM:2,57c2120a133141907616528!
