Re: BGP attributes through IGP

[Saku Ytti]

On (2014-03-07 10:49 +1030), Glen Turner wrote:

> That's pretty much what the OSPF tag and the BGP's synchronisation with OSPF 
> were originally intended for.

1403 (1364) is historic and never referenced by OSPF standard. Original
intention for external tag is unspecified information carried between AS
borders.

> However it's pretty much a design misfeature and you'd be happier with iBGP 
> over a tunnel

Agreed. If this is common requirement, nothing stopping figuring out new
LSA/LSP to properly carry BGP information. Of course won't be solution for
near-term, unless OP controls the edge and uses open source implementation, in
which case he might send this information in opaque LSA.



-- 
  ++ytti

Re: BGP attributes through IGP

[Blake Dunlap]

Mpls, GRE, line gun...

At some point, you want to stop beginning technical designs with "Doctor!
Doctor! It hurts when I do this. What can I do?"

The answer doesn't generally change, no matter how many times it's asked.


-Blake


On Thu, Mar 6, 2014 at 6:19 PM, Glen Turner  wrote:

>
> Saku Ytti wrote:
> >
> > It's essentially abusing (some what well-defined and interoperable
> abuse) 32b
> > tag field for this purpose.
>
> That's pretty much what the OSPF tag and the BGP's synchronisation with
> OSPF were originally intended for.
>
> However it's pretty much a design misfeature and you'd be happier with
> iBGP over a tunnel
>
> -glen

Re: valley free routing?

[William Herrin]

On Thu, Mar 6, 2014 at 9:23 PM, Matthew Petach  wrote:
> On Wed, Mar 5, 2014 at 12:23 PM, William Herrin  wrote:
>> Can anyone tell me about a situation in which a route which was not
>> valley free was not a result of a misconfiguration or a bad actor? For
>> those who don't recall the terminology, a network path is valley free
>> if it crosses exactly zero or one free peering links when traveling
>> between the two endpoints.
>
>
> Isn't that the way most of the IPv6 internet ran
> for many years?   ISP A -> 6939 <- ISP B,
> settlement-free connections all around?  It's
> what established 6939 as the core of the
> IPv6 internet.

Hi Matthew,

By peering I mean a link on which the two participants offer and
accept substantially fewer routes than "the rest of the Internet."
Usually only the routes for each participant's respective customers.
The clever folks at HE provided full IPv6 transit as a loss leader
which enhanced their market position (put them on the map quite
frankly). That's not a "valley" in this context.

I'm really intrigued by the multiple reports of RENs creating a sort
of shadow network where other RENs are permitted to cross their
internal backbone at no cost but not access their general Internet
transit. That does seem to be a valley. Is anybody outside the
Research and Education industry doing this sort of thing?

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: valley free routing?

[Matthew Petach]

On Wed, Mar 5, 2014 at 12:23 PM, William Herrin  wrote:

> Hi folks,
>
> Can anyone tell me about a situation in which a route which was not
> valley free was not a result of a misconfiguration or a bad actor? For
> those who don't recall the terminology, a network path is valley free
> if it crosses exactly zero or one free peering links when traveling
> between the two endpoints.
>

Isn't that the way most of the IPv6 internet ran
for many years?   ISP A -> 6939 <- ISP B,
settlement-free connections all around?  It's
what established 6939 as the core of the
IPv6 internet.

Matt


>
> Thanks,
> Bill Herrin
>
>
> --
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004
>
>

Re: BGP attributes through IGP

[Glen Turner]

Saku Ytti wrote:
> 
> It's essentially abusing (some what well-defined and interoperable abuse) 32b
> tag field for this purpose.

That's pretty much what the OSPF tag and the BGP's synchronisation with OSPF 
were originally intended for.

However it's pretty much a design misfeature and you'd be happier with iBGP 
over a tunnel

-glen

Re: BGP attributes through IGP

[Elliot Finley]

iBGP over GRE?



On Thu, Mar 6, 2014 at 2:58 PM, Bryan Ashley  wrote:

> so this scenario was a much more scaled down version of the actual
> topology.  Basically I have a "gap" of routers that I don't manage or have
> access to in between mine running eBGP.  We are collecting some metrics and
> doing monitoring on the AS-PATH of the routes received, among other
> attributes, for both ends so losing some of this information is a problem.
>  Again, I know the right answer here is to run iBGP across the IGP and I am
> fighting that fight but it got me looking for alternative solutions and
> figured I would see if anyone else ever had to come up with a creative
> solution before.
>
>
> On Thu, Mar 6, 2014 at 4:09 PM, Saku Ytti  wrote:
>
> > On (2014-03-06 10:37 -0500), Bryan Ashley wrote:
> >
> > > My searches have come up a little short however I found a couple
> > references
> > > to using automatic-tag and as-path tag to carry this through.  I cant
> > seem
> > > to find any Junos reference information on this so wanted to reach out
> to
> > > the ether and see if others have faced this situation before or have
> any
> > > other recommendations on solutions.
> >
> > I don't think JunOS supports this.
> >
> > It's bit of hack at any rate. It's not transporting AS_PATH, it's
> > transporting
> > single 16b ASN.
> > It's essentially abusing (some what well-defined and interoperable abuse)
> > 32b
> > tag field for this purpose.
> >
> > Maybe you could try to do some of this manually, set some tags, which
> > trigger
> > 'set then origin x', as-path-expand/prepend might be more challenging.
> > Recommendation for solution might be easier with rationale why you need
> to
> > transport origin+aspath over IGP.
> >
> > --
> >   ++ytti
> >
> >
>

Re: BGP attributes through IGP

[Bryan Ashley]

so this scenario was a much more scaled down version of the actual
topology.  Basically I have a "gap" of routers that I don't manage or have
access to in between mine running eBGP.  We are collecting some metrics and
doing monitoring on the AS-PATH of the routes received, among other
attributes, for both ends so losing some of this information is a problem.
 Again, I know the right answer here is to run iBGP across the IGP and I am
fighting that fight but it got me looking for alternative solutions and
figured I would see if anyone else ever had to come up with a creative
solution before.


On Thu, Mar 6, 2014 at 4:09 PM, Saku Ytti  wrote:

> On (2014-03-06 10:37 -0500), Bryan Ashley wrote:
>
> > My searches have come up a little short however I found a couple
> references
> > to using automatic-tag and as-path tag to carry this through.  I cant
> seem
> > to find any Junos reference information on this so wanted to reach out to
> > the ether and see if others have faced this situation before or have any
> > other recommendations on solutions.
>
> I don't think JunOS supports this.
>
> It's bit of hack at any rate. It's not transporting AS_PATH, it's
> transporting
> single 16b ASN.
> It's essentially abusing (some what well-defined and interoperable abuse)
> 32b
> tag field for this purpose.
>
> Maybe you could try to do some of this manually, set some tags, which
> trigger
> 'set then origin x', as-path-expand/prepend might be more challenging.
> Recommendation for solution might be easier with rationale why you need to
> transport origin+aspath over IGP.
>
> --
>   ++ytti
>
>

Re: BGP attributes through IGP

[Saku Ytti]

On (2014-03-06 10:37 -0500), Bryan Ashley wrote:

> My searches have come up a little short however I found a couple references
> to using automatic-tag and as-path tag to carry this through.  I cant seem
> to find any Junos reference information on this so wanted to reach out to
> the ether and see if others have faced this situation before or have any
> other recommendations on solutions.

I don't think JunOS supports this.

It's bit of hack at any rate. It's not transporting AS_PATH, it's transporting
single 16b ASN.
It's essentially abusing (some what well-defined and interoperable abuse) 32b
tag field for this purpose.

Maybe you could try to do some of this manually, set some tags, which trigger
'set then origin x', as-path-expand/prepend might be more challenging.
Recommendation for solution might be easier with rationale why you need to
transport origin+aspath over IGP.

-- 
  ++ytti

BGP attributes through IGP

[Bryan Ashley]

Greetings all - first time caller long time listener.

I came across a scenario the other day which got my wheels turning a bit
and wanted to reach out and see how others are handling this besides what I
would think to be the obvious.

Scenario: R1->R2->R3->R4
R1->R2 eBGP
R2->R3 OSPF
R3->R4 eBGP

Essentially what I want to do is be able to carry BGP attributes through
OSPF so that remote end sees the full AS-PATH, ORIGIN, etc.  The easy
answer here is iBGP across OSPF however the wrinkle is this can't be done.
 Its a long story and one in which we are currently fighting however
suffice it to say for the moment this option is out.

My searches have come up a little short however I found a couple references
to using automatic-tag and as-path tag to carry this through.  I cant seem
to find any Junos reference information on this so wanted to reach out to
the ether and see if others have faced this situation before or have any
other recommendations on solutions.

Responses on or off list is much appreciated.

Network anomaly survey - evaluation and results

[Jan Rejchrt]

Dear network experts,

few months ago we conducted a survey regarding network anomalies.
We'd like to provide you with our findings that you can find at RIPE Labs page:

https://labs.ripe.net/Members/jan_rejchrt/network-anomaly-detection-2013-survey-evaluation

I'd like to thank all the participants.



Best regards,

 Jan Rejchrt

On behalf of CSIRT-MU

-- 
Mgr. Jan Rejchrt   rejc...@ics.muni.cz
Security Department, CSIRT-MU grouphttp://csirt.muni.cz
Institute of Computer Science, Masaryk University, Brno, Czech Republic
PGP Key ID: 0x9B5724C8




signature.asc
Description: OpenPGP digital signature

Re: fiber optics patchcords - supplier nearby Atlanta,GA

[Jiri Prochazka]

Thanks to all who replied here & off list.

We have already made an order on Cablesandkits.com.



Jiri

Dne 6.3.2014 14:00, Jiri Prochazka napsal(a):

Hello list,

we're deploying a new rack/technology in Atlanta,GA and we are out of
reserves of optical patchcords.

We need to get another few pieces (combinations of most used connectors
like LC/SC/E2000 and lenghts).


Could you please point me to some eshop in the US, where we can get them?

Ideally with possibility to pay over PayPal and delivery time to
Atlanta,GA in two working days. Normally, we would ship them from
Europe, but we do not want to risk the delay which could be caused by
customs.


Thank you!



Jiri Prochazka

Re: valley free routing?

[Randy Bush]

once upon a time, provider A and provider P were having a peering war,
and provider V provided valley transit for P's prefixes to A.  it was
not meant to be seen publicly, but the traceroutes were posted to nanog,
or maybe it was com-priv at the time.

this is far from the only time this has happened.

randy

fiber optics patchcords - supplier nearby Atlanta,GA

[Dale Rumph]

On Mar 6, 2014 8:22 AM, "Jiri Prochazka" 
wrote:
>
> Hello list,
>
> we're deploying a new rack/technology in Atlanta,GA and we are out of
reserves of optical patchcords.
>
> We need to get another few pieces (combinations of most used connectors
like LC/SC/E2000 and lenghts).
>
>
> Could you please point me to some eshop in the US, where we can get them?
>
> Ideally with possibility to pay over PayPal and delivery time to
Atlanta,GA in two working days. Normally, we would ship them from Europe,
but we do not want to risk the delay which could be caused by customs.
>
>
> Thank you!
>
>
>
> Jiri Prochazka
>
>
http://www.cablesandkits.com/ is located in buford GA, also
monoprice.comis a good estore for patch cables.

Re: fiber optics patchcords - supplier nearby Atlanta,GA

[joel jaeggli]

On 3/6/14, 1:00 PM, Jiri Prochazka wrote:
> Hello list,
> 
> we're deploying a new rack/technology in Atlanta,GA and we are out of
> reserves of optical patchcords.
> 
> We need to get another few pieces (combinations of most used connectors
> like LC/SC/E2000 and lenghts).
> 
> 
> Could you please point me to some eshop in the US, where we can get them?
> 
> Ideally with possibility to pay over PayPal and delivery time to
> Atlanta,GA in two working days. Normally, we would ship them from
> Europe, but we do not want to risk the delay which could be caused by
> customs.

cables and kits is local to atlanta

http://www.cablesandkits.com/

when I was  standing up a large footprint in atl I worked with the local
graybar among other suppliers.

> 
> Thank you!
> 
> 
> 
> Jiri Prochazka
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: fiber optics patchcords - supplier nearby Atlanta,GA

[Joshua McDonald]

Not sure about the PayPal requirement, but Cables and Kits is local to
Atlanta.

http://www.cablesandkits.com

Josh

> On Mar 6, 2014, at 8:21, Jiri Prochazka  
> wrote:
>
> Hello list,
>
> we're deploying a new rack/technology in Atlanta,GA and we are out of 
> reserves of optical patchcords.
>
> We need to get another few pieces (combinations of most used connectors like 
> LC/SC/E2000 and lenghts).
>
>
> Could you please point me to some eshop in the US, where we can get them?
>
> Ideally with possibility to pay over PayPal and delivery time to Atlanta,GA 
> in two working days. Normally, we would ship them from Europe, but we do not 
> want to risk the delay which could be caused by customs.
>
>
> Thank you!
>
>
>
> Jiri Prochazka
>
>

fiber optics patchcords - supplier nearby Atlanta,GA

[Jiri Prochazka]

Hello list,

we're deploying a new rack/technology in Atlanta,GA and we are out of 
reserves of optical patchcords.


We need to get another few pieces (combinations of most used connectors 
like LC/SC/E2000 and lenghts).



Could you please point me to some eshop in the US, where we can get them?

Ideally with possibility to pay over PayPal and delivery time to 
Atlanta,GA in two working days. Normally, we would ship them from 
Europe, but we do not want to risk the delay which could be caused by 
customs.



Thank you!



Jiri Prochazka

Re: DNS Resolving issues. So for related just to Cox. But could be larger.

[Paul S.]

OP is actually the owner of it as per ARIN whois data.

-- Paul

On 3/6/2014 午後 09:41, Nick Hilliard wrote:

On 06/03/2014 12:14, bmann...@vacation.karoshi.com wrote:

On Wed, Mar 05, 2014 at 07:52:10AM -0500, Rob Seastrom wrote:

to secondary nameservers.  Speaking of that...

;; ADDITIONAL SECTION:
ns1.nineplanetshosting.com. 172800 IN   A   199.73.57.122
ns2.nineplanetshosting.com. 172800 IN   A   199.73.57.122

I think OP ought to approach his hoster with a cluebat.  Not just on
the same subnet but the same address?  Really.

-r


haven't you heard about "anycast"??

rs probably has.  The owner of 199.73.57.122, probably not.

Nick

Re: DNS Resolving issues. So for related just to Cox. But could be larger.

[Rob Seastrom]

Nick Hilliard  writes:

>>  haven't you heard about "anycast"??
>
> rs probably has.  The owner of 199.73.57.122, probably not.

indeed.  there are many pieces of evidence that this is not an anycast
prefix.  proof is left as an exercise to those who can perform
traceroutes from multiple continents, run nmap -sP, log into
route-views, or do some combination of the above.

-r

Re: DNS Resolving issues. So for related just to Cox. But could be larger.

[Nick Hilliard]

On 06/03/2014 12:14, bmann...@vacation.karoshi.com wrote:
> On Wed, Mar 05, 2014 at 07:52:10AM -0500, Rob Seastrom wrote:
>> to secondary nameservers.  Speaking of that...
>>
>> ;; ADDITIONAL SECTION:
>> ns1.nineplanetshosting.com. 172800 IN   A   199.73.57.122
>> ns2.nineplanetshosting.com. 172800 IN   A   199.73.57.122
>>
>> I think OP ought to approach his hoster with a cluebat.  Not just on
>> the same subnet but the same address?  Really.
>>
>> -r
>>
> 
>   haven't you heard about "anycast"??

rs probably has.  The owner of 199.73.57.122, probably not.

Nick

Re: valley free routing?

[Iljitsch van Beijnum]

> On 6 mrt. 2014, at 02:18, Joel Maslak  wrote:
> 
> I have never heard the term valley free.  Where does it come from?

This paper, which is a must-read for anyone interested in BGP:

Stable internet routing without global coordination
By Lixin Gao and Jennifer Rexford
http://dl.acm.org/citation.cfm?id=504612

Re: valley free routing?

[JÁKÓ András]

> It's that business deal I want to hear about. When A-B and B-C are
> free peering but the traffic goes A-B-C for some reason other than a
> misconfiguration or deliberate abuse. On or off list, I'd like to know
> about real-life use cases where folks do this on purpose.

As far as I understand some NRENs do that in Europe. Check out AS1853
and AS-ACONETTOVIX in the RIPE whois. "A" networks are the peers a VIX,
"B" is ACONET, "C" networks are CESNET, SANET, and PIONIER.

DTAG's looking glass shows this path to SANET:

sh ip bgp regexp _2607_
BGP table version is 0, local router ID is 217.239.38.165
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network  Next HopMetric LocPrf Weight Path
*>i147.175.0.0  194.25.5.150  100  0 1853 2607 i
*>i147.213.0.0  194.25.5.150  100  0 1853 2607 i
*>i147.232.0.0  194.25.5.150  100  0 1853 2607 i
*>i158.193.0.0  194.25.5.150  100  0 1853 2607 i
*>i158.195.0.0  194.25.5.150  100  0 1853 2607 i
*>i158.197.0.0  194.25.5.150  100  0 1853 2607 i
*>i192.108.130.0194.25.5.150  100  0 1853 2607 i
*>i192.108.131.0194.25.5.150  100  0 1853 2607 i
*>i192.108.132.0/23 194.25.5.150  100  0 1853 2607 i
*>i192.108.138.0194.25.5.150  100  0 1853 2607 i
*>i192.108.149.0194.25.5.150  100  0 1853 2607 i
*>i193.87.0.0/16194.25.5.150  100  0 1853 2607 i
*>i194.1.0.0/17 194.25.5.150  100  0 1853 2607 i
*>i194.160.0.0/16   194.25.5.150  100  0 1853 2607 i
Total number of prefixes 14

Regards,
András

Re: DNS Resolving issues. So for related just to Cox. But could be larger.

[bmanning]

On Wed, Mar 05, 2014 at 07:52:10AM -0500, Rob Seastrom wrote:
> 
> "Paul S."  writes:
> 
> > For all it's worth, it might be Cox ignoring TTLs and enforcing their
> > own update times instead.
> >
> > Wait 24-48 hours, and it should probably fix it all up.
> 
> Possibly.
> 
> > I'm not seeing anything majorly broken with your system except the SOA
> > EXPIRE being ridiculously large.
> 
> Nowhere even close to ridiculously large.  360 (1 hours, 41
> days) is the historical example value in RFC 1035.  It's a bit larger
> than current recommended practices (2-4 weeks) but I wouldn't fault
> anyone for using that value nor would I expect any nameserver software
> to malfunction when confronted it.  Besides, that value only matters
> to secondary nameservers.  Speaking of that...
> 
> ;; ADDITIONAL SECTION:
> ns1.nineplanetshosting.com. 172800 IN   A   199.73.57.122
> ns2.nineplanetshosting.com. 172800 IN   A   199.73.57.122
> 
> I think OP ought to approach his hoster with a cluebat.  Not just on
> the same subnet but the same address?  Really.
> 
> -r
> 

haven't you heard about "anycast"??


/bill

Re: Fwd: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping

[María García]

I can't see the date... 😕
El mar 6, 2014 12:27 PM, "Matt Palmer"  escribió:

> On Wed, Mar 05, 2014 at 12:37:29PM +0100, María García wrote:
> > 2014-03-05 7:17 GMT+01:00 Matt Palmer :
> > > the 'goto
> > > cleanup' tests were introduced in 0fba2d90, way back in October 2003
> >
> > Where can you see that "the 'goto
> > cleanup' tests were introduced in 0fba2d90, way back in October 2003" ?
>
> In the git repo I linked to in my previous e-mail.
>
> - Matt
>
> --
> I have always wished that my computer would be as easy to use as my
> telephone. My wish has come true. I no longer know how to use my telephone.
> -- Bjarne Stroustrup
>
>
>

Re: Fwd: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping

[Matt Palmer]

On Wed, Mar 05, 2014 at 12:37:29PM +0100, María García wrote:
> 2014-03-05 7:17 GMT+01:00 Matt Palmer :
> > the 'goto
> > cleanup' tests were introduced in 0fba2d90, way back in October 2003
> 
> Where can you see that "the 'goto
> cleanup' tests were introduced in 0fba2d90, way back in October 2003" ?

In the git repo I linked to in my previous e-mail.

- Matt

-- 
I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my telephone.
-- Bjarne Stroustrup

Re: Novartis and Qwest AS209

[Christopher Morrow]

guessing that 209 registered some objects on behalf of novartis/customer?
novartis isn't qwest who's now centurylink anyway.

On Wed, Mar 5, 2014 at 2:02 PM, Jmac  wrote:
> All, I haven¹t posted something to Nanog in probably 10 years so forgive my
> ignorance on protocol.  I am sure this has been posted about but while I
> figure out how to search the archivesŠ.
>
> I see Ripe DB, Maxmind and many others have AS209 associated with the
> company Novartis.  Did I miss something because ARIN whois shows it
> different.  If this is wrong, it seems the source of the error is
> db.ripe.net.
>
> aut-num: AS209
>  num>
> as-name: ASN-QWEST-US
> descr:   NOVARTIS-DMZ-US
> admin-c: NOVN1-RIPE
>  =PERSON>
> tech-c:  NOVN2-RIPE
>  =PERSON>
> mnt-by:  NOVARTIS-MNT
>  pe=MNTNER>
> source:  RIPE # Filtered
>
> Thanks
> Jason
>
>

Novartis and Qwest AS209

[Jmac]

All, I haven¹t posted something to Nanog in probably 10 years so forgive my
ignorance on protocol.  I am sure this has been posted about but while I
figure out how to search the archivesŠ.

I see Ripe DB, Maxmind and many others have AS209 associated with the
company Novartis.  Did I miss something because ARIN whois shows it
different.  If this is wrong, it seems the source of the error is
db.ripe.net.

aut-num: AS209
 
as-name: ASN-QWEST-US
descr:   NOVARTIS-DMZ-US
admin-c: NOVN1-RIPE
 
tech-c:  NOVN2-RIPE
 
mnt-by:  NOVARTIS-MNT
 
source:  RIPE # Filtered

Thanks
Jason

Re: Fwd: [ PRIVACY Forum ] Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping

[María García]

2014-03-05 7:17 GMT+01:00 Matt Palmer :

> the 'goto
> cleanup' tests were introduced in 0fba2d90, way back in October 2003
>

Where can you see that "the 'goto
cleanup' tests were introduced in 0fba2d90, way back in October 2003" ?

*María García*