Re: "Tactical" /24 announcements

[Mark Tinka]

On 8/12/21 19:19, William Herrin wrote:


A originates 10.0.0.0/16 to paid transit C
B originates 10.0.1.0/24 also to paid transit C
C offers both routes to D. D discards 10.0.1.0/24 from the RIB based
on same-next-hop


Yeah, discarding from RIB is not the idea. It's discarding from FIB.

RIB is always globally converged.

Mark.

Re: "Tactical" /24 announcements

[Mark Tinka]

On 8/12/21 19:17, Amir Herzberg wrote:



Hi Hank, I think you're right, it could result in sub-optimal routing 
and in particular, in your AS not being used for these subprefixes 
(the traffic will go instead to a competing provider who sent the 
subprefix), hence, as you said, sub-optimal routing.


Incorrect - you hold the full table in RIB, which is what you offer to 
your downstream customers.


It's the FIB which wouldn't have the route, but would still be able to 
forward the traffic to a router that knows better.


Downstream customers are none the wiser.

Mark.

Re: "Tactical" /24 announcements

[Mark Tinka]

On 8/12/21 16:42, Tom Hill wrote:



I'm glad to hear a vendor has implemented a useful knob. Which vendor?


BGP-SD (Selective Download) from Cisco since about 2013.

I know both Juniper and Nokia have their versions as well.

It's nothing new.

Mark.

Re: The great Netflix vpn debacle!

[Mike Hammett]

https://thebrotherswisp.com/index.php/geo-and-vpn/ 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "John Alcock"  
To: nanog@nanog.org 
Sent: Friday, August 13, 2021 2:11:16 PM 
Subject: The great Netflix vpn debacle! 

Well, 


It happened. I have multiple subscribers calling in. They can not access 
Netflix. 


Any contacts on list for Netflix that I can use to get my up blocks 
whitelisted? 


John 

Re: "Tactical" /24 announcements

[Baldur Norddahl]

On Fri, Aug 13, 2021 at 10:53 PM Amir Herzberg  wrote:

>
> I think it isn't the same.
>

I am still not sure but maybe I misunderstood what you originally said. It
is probably not important.


> I think that the NANOG (or in general, operators) community may do well to
> state the `/24 rule' clearly in a BCP, preferably an RFC. A mismatch in the
> most-specific rule can definitely allow different problems (and attacks).
> As mentioned above, RIPE has essentially done this (although could be more
> explicit). I've seen a similar /48 rule for IPv6, btw.
>

I am not sure how big a problem this is. We only had this one case that I
described and it was easily fixed by allowing that one prefix from our
transit. The peer also offered to fix their announcement. But we did not
run with it for very long because we only reduced our routing table to
debug a different problem.

Maybe we could have a community or other mechanism to mark the few routes
that can not be dropped in exchange for a default route.

For all the stub networks out there we should be able to aggressively
filter routes without much harm.

Regards,

Baldur

Re: "Tactical" /24 announcements

[Amir Herzberg]

Tom, I also referred to the same text from 7454! But Baldur is right: the
text does NOT clearly state that announcement more specific than /24
should be filtered.

If you allow different operators to filter at different lengths, you can
get disconnections. We never like to standards to be fixed to some number,
but this seems necessary (to me).
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
 https://sites.google.com/site/amirherzberg/applied-crypto-textbook





On Fri, Aug 13, 2021 at 5:05 PM Tom Beecher  wrote:

> I think that the NANOG (or in general, operators) community may do well to
>> state the `/24 rule' clearly in a BCP, preferably an RFC.
>>
>
> https://datatracker.ietf.org/doc/html/rfc7454
>
> 6.1.3 .
>> Prefixes That Are Too Specific
>> Most ISPs will not accept advertisements beyond a certain level of
>> specificity (and in return, they do not announce prefixes they
>> consider to be too specific). That acceptable specificity is decided
>> for each peering between the two BGP peers. Some ISP communities
>> have tried to document acceptable specificity. This document does
>> not make any judgement on what the best approach is, it just notes
>> that there are existing practices on the Internet and recommends that
>> the reader refer to them. As an example, the RIPE community has
>> documented that, at the time of writing of this document, IPv4
>> prefixes longer than /24 and IPv6 prefixes longer than /48 are
>> generally neither announced nor accepted in the Internet [20
>> ] [21
>> ].
>>These values may change in the future.
>
>
> On Fri, Aug 13, 2021 at 4:54 PM Amir Herzberg 
> wrote:
>
>> On Fri, Aug 13, 2021 at 12:50 PM Baldur Norddahl <
>> baldur.nordd...@gmail.com> wrote:
>>
>>>
>>> On Fri, Aug 13, 2021 at 3:54 AM Amir Herzberg 
>>> wrote:
>>>
 On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl <
 baldur.nordd...@gmail.com> wrote:

>
>
> On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg 
> wrote:
>
>> Bill, I beg to respectfully differ, knowing that I'm just a
>> researcher and working `for real' like you guys, so pls take no offence.
>>
>> I don't think A would be right to filter these packets to 10.0.1.0/24;
>> A has announced 10.0.0.0/16 so should route to that (entire) prefix,
>> or A is misleading its peers.
>>
>
> You are right that it is wrong but it happens. Some years back I tried
> a setup where we wanted to reduce the size of the routing table. We 
> dropped
> everything but routes received from peers and added a default to one of 
> our
> IP transit providers. This should have been ok because either we had a
> route to a peer or the packet would go to someone who had the full routing
> table, yes?
>

 Baldur, thanks, but, sorry, this isn't the same, or I miss something.

>>>
>>> I think it is exactly the same? Our peer is advertising a prefix for
>>> which they will not route all addresses covered. Is that route not then a
>>> lie? Should they not have exploded the prefix so they could avoid covering
>>> the part of the prefix they will not accept traffic to? (ps: not arguing
>>> they should!)
>>>
>>
>> I think it isn't the same. This scenario, of an AS selling part of its IP
>> block, e.g., 10.0.1.0/24, and continuing to announce the block, e.g.,
>> 10.0.0.0/16, is the classical example used (e.g. by me) to explain the
>> `most specific' rule. Due to `most specific', it is considered, imho, legit
>> to continue to announce 10.0.0.0/16; if 10.0.1.0/24 is reachable,
>> traffic will route to it anyway due to `more specific', so no problem; and
>> if 10.0.1.0/24 isn't reachable, then anyway no harm done...
>>
>> By dropping a legit 10.0.1.0/24 announcement, you may - and in the cited
>> example, did - break connectivity, imho. And quite unnecessarily, too.
>>
>>>
>>>
 If I get you right, you dropped all announcements from _providers_
 except making one provider your default gateway (essentially, 0.0.0.0/0).
 But this is very different from what I understood from what Bill wrote.
 Your change could (and, from what you say next, did) cause a problem if one
 of these announcements you dropped from providers was a legit subprefix of
 a prefix announced by one of your peers, causing you to route to the peer
 traffic whose destination is in the subprefix.

>>>
>>> Your understanding is correct. But this is just the way we ended up in
>>> that situation. Does not change the fact that we got a route from a peer
>>> that we 

Re: "Tactical" /24 announcements

[Tom Beecher]

>
> I think that the NANOG (or in general, operators) community may do well to
> state the `/24 rule' clearly in a BCP, preferably an RFC.
>

https://datatracker.ietf.org/doc/html/rfc7454

6.1.3 .
> Prefixes That Are Too Specific
> Most ISPs will not accept advertisements beyond a certain level of
> specificity (and in return, they do not announce prefixes they
> consider to be too specific). That acceptable specificity is decided
> for each peering between the two BGP peers. Some ISP communities
> have tried to document acceptable specificity. This document does
> not make any judgement on what the best approach is, it just notes
> that there are existing practices on the Internet and recommends that
> the reader refer to them. As an example, the RIPE community has
> documented that, at the time of writing of this document, IPv4
> prefixes longer than /24 and IPv6 prefixes longer than /48 are
> generally neither announced nor accepted in the Internet [20
> ] [21
> ].
>These values may change in the future.


On Fri, Aug 13, 2021 at 4:54 PM Amir Herzberg  wrote:

> On Fri, Aug 13, 2021 at 12:50 PM Baldur Norddahl <
> baldur.nordd...@gmail.com> wrote:
>
>>
>> On Fri, Aug 13, 2021 at 3:54 AM Amir Herzberg 
>> wrote:
>>
>>> On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl <
>>> baldur.nordd...@gmail.com> wrote:
>>>


 On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg 
 wrote:

> Bill, I beg to respectfully differ, knowing that I'm just a researcher
> and working `for real' like you guys, so pls take no offence.
>
> I don't think A would be right to filter these packets to 10.0.1.0/24;
> A has announced 10.0.0.0/16 so should route to that (entire) prefix,
> or A is misleading its peers.
>

 You are right that it is wrong but it happens. Some years back I tried
 a setup where we wanted to reduce the size of the routing table. We dropped
 everything but routes received from peers and added a default to one of our
 IP transit providers. This should have been ok because either we had a
 route to a peer or the packet would go to someone who had the full routing
 table, yes?

>>>
>>> Baldur, thanks, but, sorry, this isn't the same, or I miss something.
>>>
>>
>> I think it is exactly the same? Our peer is advertising a prefix for
>> which they will not route all addresses covered. Is that route not then a
>> lie? Should they not have exploded the prefix so they could avoid covering
>> the part of the prefix they will not accept traffic to? (ps: not arguing
>> they should!)
>>
>
> I think it isn't the same. This scenario, of an AS selling part of its IP
> block, e.g., 10.0.1.0/24, and continuing to announce the block, e.g.,
> 10.0.0.0/16, is the classical example used (e.g. by me) to explain the
> `most specific' rule. Due to `most specific', it is considered, imho, legit
> to continue to announce 10.0.0.0/16; if 10.0.1.0/24 is reachable, traffic
> will route to it anyway due to `more specific', so no problem; and if
> 10.0.1.0/24 isn't reachable, then anyway no harm done...
>
> By dropping a legit 10.0.1.0/24 announcement, you may - and in the cited
> example, did - break connectivity, imho. And quite unnecessarily, too.
>
>>
>>
>>> If I get you right, you dropped all announcements from _providers_
>>> except making one provider your default gateway (essentially, 0.0.0.0/0).
>>> But this is very different from what I understood from what Bill wrote.
>>> Your change could (and, from what you say next, did) cause a problem if one
>>> of these announcements you dropped from providers was a legit subprefix of
>>> a prefix announced by one of your peers, causing you to route to the peer
>>> traffic whose destination is in the subprefix.
>>>
>>
>> Your understanding is correct. But this is just the way we ended up in
>> that situation. Does not change the fact that we got a route from a peer
>> that we believed we could use, but turns out part of that announcement was
>> a lie.
>>
>
> Was not a lie, as I explained.
>
>>
>> Consider that everyone filters received routes. The most common is to
>> filter at the /24 level but nowhere is there a RFC stating that /24 is
>> anything special.
>>
>
> Oh that's a point I was quite annoyed with for years - who said one should
> drop prefixes longer than /24 ??? And I searched for it, and indeed found
> no RFC. But I did find it mentioned in some BCPs!
> Unfortunately and stupidly, I didn't save these sources, but I did a quick
> google now and found
>
>
> https://nsrc.org/workshops/2018/linx103-bgp/networking/peering-ixp/en/presentations/05-BGP-BCP.pdf
>
> But that was years ago, and indeed, I also found mention in RFC 7454:
>
>
>> 6.1.3 .  Prefixes 
>> That Are Too Specific
>>
>> 

Re: "Tactical" /24 announcements

[Amir Herzberg]

On Fri, Aug 13, 2021 at 12:50 PM Baldur Norddahl 
wrote:

>
> On Fri, Aug 13, 2021 at 3:54 AM Amir Herzberg 
> wrote:
>
>> On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl <
>> baldur.nordd...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg 
>>> wrote:
>>>
 Bill, I beg to respectfully differ, knowing that I'm just a researcher
 and working `for real' like you guys, so pls take no offence.

 I don't think A would be right to filter these packets to 10.0.1.0/24;
 A has announced 10.0.0.0/16 so should route to that (entire) prefix,
 or A is misleading its peers.

>>>
>>> You are right that it is wrong but it happens. Some years back I tried a
>>> setup where we wanted to reduce the size of the routing table. We dropped
>>> everything but routes received from peers and added a default to one of our
>>> IP transit providers. This should have been ok because either we had a
>>> route to a peer or the packet would go to someone who had the full routing
>>> table, yes?
>>>
>>
>> Baldur, thanks, but, sorry, this isn't the same, or I miss something.
>>
>
> I think it is exactly the same? Our peer is advertising a prefix for which
> they will not route all addresses covered. Is that route not then a lie?
> Should they not have exploded the prefix so they could avoid covering the
> part of the prefix they will not accept traffic to? (ps: not arguing they
> should!)
>

I think it isn't the same. This scenario, of an AS selling part of its IP
block, e.g., 10.0.1.0/24, and continuing to announce the block, e.g.,
10.0.0.0/16, is the classical example used (e.g. by me) to explain the
`most specific' rule. Due to `most specific', it is considered, imho, legit
to continue to announce 10.0.0.0/16; if 10.0.1.0/24 is reachable, traffic
will route to it anyway due to `more specific', so no problem; and if
10.0.1.0/24 isn't reachable, then anyway no harm done...

By dropping a legit 10.0.1.0/24 announcement, you may - and in the cited
example, did - break connectivity, imho. And quite unnecessarily, too.

>
>
>> If I get you right, you dropped all announcements from _providers_ except
>> making one provider your default gateway (essentially, 0.0.0.0/0). But
>> this is very different from what I understood from what Bill wrote. Your
>> change could (and, from what you say next, did) cause a problem if one of
>> these announcements you dropped from providers was a legit subprefix of a
>> prefix announced by one of your peers, causing you to route to the peer
>> traffic whose destination is in the subprefix.
>>
>
> Your understanding is correct. But this is just the way we ended up in
> that situation. Does not change the fact that we got a route from a peer
> that we believed we could use, but turns out part of that announcement was
> a lie.
>

Was not a lie, as I explained.

>
> Consider that everyone filters received routes. The most common is to
> filter at the /24 level but nowhere is there a RFC stating that /24 is
> anything special.
>

Oh that's a point I was quite annoyed with for years - who said one should
drop prefixes longer than /24 ??? And I searched for it, and indeed found
no RFC. But I did find it mentioned in some BCPs!
Unfortunately and stupidly, I didn't save these sources, but I did a quick
google now and found

https://nsrc.org/workshops/2018/linx103-bgp/networking/peering-ixp/en/presentations/05-BGP-BCP.pdf

But that was years ago, and indeed, I also found mention in RFC 7454:


> 6.1.3 .  Prefixes 
> That Are Too Specific
>
>Most ISPs will not accept advertisements beyond a certain level of
>specificity (and in return, they do not announce prefixes they
>consider to be too specific).  That acceptable specificity is decided
>for each peering between the two BGP peers.  Some ISP communities
>have tried to document acceptable specificity.  This document does
>not make any judgement on what the best approach is, it just notes
>that there are existing practices on the Internet and recommends that
>the reader refer to them.  As an example, the RIPE community has
>documented that, at the time of writing of this document, IPv4
>prefixes longer than /24 and IPv6 prefixes longer than /48 are
>generally neither announced nor accepted in the Internet [20 
> ] [21 
> ].
>These values may change in the future.
>
>
I also did an experiment that seemed to confirm that most ISPs filter
announcements more specific than /24.

I think that the NANOG (or in general, operators) community may do well to
state the `/24 rule' clearly in a BCP, preferably an RFC. A mismatch in the
most-specific rule can definitely allow different problems (and attacks).
As mentioned above, RIPE has essentially done this (although could be more
explicit). I've seen a similar /48 rule 

Re: The great Netflix vpn debacle!

[Phineas Walton]

geosupp...@netflix.com has been very responsive for us. Best of luck,
Netflix is always a hassle.

Phin

On Fri, Aug 13, 2021 at 8:13 PM John Alcock  wrote:

> Well,
>
> It happened. I have multiple subscribers calling in. They can not access
> Netflix.
>
> Any contacts on list for Netflix that I can use to get my up blocks
> whitelisted?
>
> John
>

The great Netflix vpn debacle!

[John Alcock]

Well,

It happened. I have multiple subscribers calling in. They can not access
Netflix.

Any contacts on list for Netflix that I can use to get my up blocks
whitelisted?

John

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 14 Aug, 2021

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  859233
Prefixes after maximum aggregation (per Origin AS):  325419
Deaggregation factor:  2.64
Unique aggregates announced (without unneeded subnets):  412951
Total ASes present in the Internet Routing Table: 71756
Prefixes per ASN: 11.97
Origin-only ASes present in the Internet Routing Table:   61685
Origin ASes announcing only one prefix:   25422
Transit ASes present in the Internet Routing Table:   10071
Transit-only ASes present in the Internet Routing Table:328
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  37
Max AS path prepend of ASN (141827)  33
Prefixes from unregistered ASNs in the Routing Table:  1073
Number of instances of unregistered ASNs:  1079
Number of 32-bit ASNs allocated by the RIRs:  36882
Number of 32-bit ASNs visible in the Routing Table:   30663
Prefixes from 32-bit ASNs in the Routing Table:  142443
Number of bogon 32-bit ASNs visible in the Routing Table:26
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:533
Number of addresses announced to Internet:   3039950336
Equivalent to 181 /8s, 49 /16s and 246 /24s
Percentage of available address space announced:   82.1
Percentage of allocated address space announced:   82.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  285549

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   230688
Total APNIC prefixes after maximum aggregation:   66041
APNIC Deaggregation factor:3.49
Prefixes being announced from the APNIC address blocks:  226129
Unique aggregates announced from the APNIC address blocks:91042
APNIC Region origin ASes present in the Internet Routing Table:   11835
APNIC Prefixes per ASN:   19.11
APNIC Region origin ASes announcing only one prefix:   3356
APNIC Region transit ASes present in the Internet Routing Table:   1676
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 37
Number of APNIC region 32-bit ASNs visible in the Routing Table:   6999
Number of APNIC addresses announced to Internet:  773842432
Equivalent to 46 /8s, 31 /16s and 230 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-147769
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:251416
Total ARIN prefixes after maximum aggregation:   115126
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   251019
Unique aggregates announced from the ARIN address blocks:119512
ARIN Region origin ASes present in the Internet Routing Table:18871
ARIN Prefixes per ASN:13.30
ARIN 

Re: "Tactical" /24 announcements

[William Herrin]

On Fri, Aug 13, 2021 at 9:49 AM Baldur Norddahl
 wrote:
> Our peer is advertising a prefix for which they will not route
> all addresses covered. Is that route not then a lie? Should
> they not have exploded the prefix so they could avoid covering
> the part of the prefix they will not accept traffic to? (ps: not arguing they 
> should!)

Hi Baldur,

You do understand the consequence of the position you're taking?
You're saying that when an ISP provides a /24 to a customer for
multihoming, a common practice throughout the history of the
commercial Internet, that ISP MUST also disaggregate the announcement
for the supernet that /24 is a part of, exploding the size of the BGP
table. If they don't, the overlapping announcement is a "lie" because
they don't always have a route to the /24.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: "Tactical" /24 announcements

[Baldur Norddahl]

On Fri, Aug 13, 2021 at 3:54 AM Amir Herzberg  wrote:

> On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl 
> wrote:
>
>>
>>
>> On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg 
>> wrote:
>>
>>> Bill, I beg to respectfully differ, knowing that I'm just a researcher
>>> and working `for real' like you guys, so pls take no offence.
>>>
>>> I don't think A would be right to filter these packets to 10.0.1.0/24;
>>> A has announced 10.0.0.0/16 so should route to that (entire) prefix, or
>>> A is misleading its peers.
>>>
>>
>> You are right that it is wrong but it happens. Some years back I tried a
>> setup where we wanted to reduce the size of the routing table. We dropped
>> everything but routes received from peers and added a default to one of our
>> IP transit providers. This should have been ok because either we had a
>> route to a peer or the packet would go to someone who had the full routing
>> table, yes?
>>
>
> Baldur, thanks, but, sorry, this isn't the same, or I miss something.
>

I think it is exactly the same? Our peer is advertising a prefix for which
they will not route all addresses covered. Is that route not then a lie?
Should they not have exploded the prefix so they could avoid covering the
part of the prefix they will not accept traffic to? (ps: not arguing they
should!)


> If I get you right, you dropped all announcements from _providers_ except
> making one provider your default gateway (essentially, 0.0.0.0/0). But
> this is very different from what I understood from what Bill wrote. Your
> change could (and, from what you say next, did) cause a problem if one of
> these announcements you dropped from providers was a legit subprefix of a
> prefix announced by one of your peers, causing you to route to the peer
> traffic whose destination is in the subprefix.
>

Your understanding is correct. But this is just the way we ended up in that
situation. Does not change the fact that we got a route from a peer that we
believed we could use, but turns out part of that announcement was a lie.

Consider that everyone filters received routes. The most common is to
filter at the /24 level but nowhere is there a RFC stating that /24 is
anything special. So what if I was to filter at a different level, say /20
? The same thing would happen, we would drop the "/24 exception route" and
use the route that is a lie.

Regards,

Baldur

Re: "Tactical" /24 announcements

[Sabri Berisha]

- On Aug 12, 2021, at 10:38 AM, Amir Herzberg amir.li...@gmail.com wrote:

Hi,

> I don't think A would be right to filter these packets to 10.0.1.0/24; A has 
> announced
> 10.0.0.0/16 so should route to that (entire) prefix, or A is misleading its 
> peers.

This is what it boils down to. If you don't want to route it, don't advertise 
it.

Thanks,

Sabri