[j-nsp] juniper-nsp Digest, Vol 111, Issue 31
Chris Gapske
cgapske at paducahpower.com
Thu Feb 23 11:15:12 EST 2012
I have been buying my Optics from enfoPoint contact tom at enfopoint.com
They have served me well and at a much lower price than the Standard Premium Juniper priced optics.
This is not meant as an advisement but informational content. They have totally built me any optic I have needed.
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of juniper-nsp-request at puck.nether.net
Sent: Thursday, February 23, 2012 7:52 AM
To: juniper-nsp at puck.nether.net
Subject: juniper-nsp Digest, Vol 111, Issue 31
Send juniper-nsp mailing list submissions to
juniper-nsp at puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/juniper-nsp
or, via email, send a message with subject or body 'help' to
juniper-nsp-request at puck.nether.net
You can reach the person managing the list at
juniper-nsp-owner at puck.nether.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of juniper-nsp digest..."
Today's Topics:
1. Re: Set MED in BGP to IGP metric for iBGP NEXT-HOP router
(Jeff Wheeler)
2. Re: Junos MPLS/LDP L2circuit label issue (Mark Tinka)
3. Re: Only announce BGP learned networks (Chris Kawchuk)
4. Re: Set MED in BGP to IGP metric for iBGP NEXT-HOP router
(Paul Zugnoni)
5. Re: Sources for SFP+ optics (Daniel Roesen)
6. IS-IS routes not installed (Kevin Wormington)
7. Re: Sources for SFP+ optics (Robert Juric)
8. Re: Sources for SFP+ optics (Tim Jackson)
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Feb 2012 20:29:54 -0500
From: Jeff Wheeler <jsw at inconcepts.biz>
To: Paul Zugnoni <paul.zugnoni at onlive.com>
Cc: juniper-nsp <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] Set MED in BGP to IGP metric for iBGP NEXT-HOP
router
Message-ID:
<CAPWAtbL5Z+_NYZXTLJsZDYtXwKvhacxSUWiMgDK6+tP=tRhWfg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Feb 21, 2012 at 7:25 PM, Paul Zugnoni <paul.zugnoni at onlive.com> wrote:
> I'm looking to set the MED on routes exported to eBGP peers to reflect
> the IGP metric to the BGP protocol next-hop
I did not see any replies to your question. Apologies if you already figured this out yourself.
set metric igp already does what you describe. You will also want to read the documentation on `set metric minimum-igp` which is often what folks really want.
Keep in mind that the MED will be set to the IGP metric to the protocol next-hop, NOT "the address of the router it learned the route from." You used both phrasings in your post. So for example, if you have a route reflector in your AS, a route may be learned from an RR but the metric will obviously not be based on the path to the RR, but the path to the next-hop.
--
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts
------------------------------
Message: 2
Date: Thu, 23 Feb 2012 11:33:37 +0800
From: Mark Tinka <mtinka at globaltransit.net>
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Junos MPLS/LDP L2circuit label issue
Message-ID: <201202231133.37568.mtinka at globaltransit.net>
Content-Type: text/plain; charset="us-ascii"
On Wednesday, February 22, 2012 10:45:20 PM Scott Harvanek
wrote:
> I've tried many different traceoptions but nothing has
> proven useful in generating an error message that can be
> acted upon. Does anyone have any ideas on why a label
> that exists both on the l2circuit and in mpls.0 would
> not be getting inserted into the ldp database such as
> this?
Can we see the Cisco side as well? That should be:
#sh mpls l2transport vc 777 detail
Cheers,
Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20120223/e0a5c8e7/attachment-0001.sig>
------------------------------
Message: 3
Date: Thu, 23 Feb 2012 17:55:44 +1100
From: Chris Kawchuk <juniperdude at gmail.com>
To: Patrick Okui <pokui at psg.com>
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Only announce BGP learned networks
Message-ID: <74B412F8-D41E-41A6-9A36-D1D332C14F7D at gmail.com>
Content-Type: text/plain; charset=us-ascii
On 2012-02-23, at 1:25 AM, Patrick Okui wrote:
> Well, apart from l3vpns you'll typically want to have your
> infrastructure addresses in your IGP and "internet/customer" addresses
> in BGP. Default AD of 20 for eBGP in IOS means you'll believe an
> advertisement from an external AS before say an OSPF or ISIS one for
> the same exact prefix.[*]
Serendipitous timing of this discussion. Dunno if you guys watch the AUSNOG list.
Major outage in Telstra (AS1221) Australia today:
http://www.smh.com.au/technology/technology-news/internet-crashes-for-telstra-customers-20120223-1tpqq.html
A peer of Telstra ended up re-advertising all of Telstra's own routes back to Telstra as if it originated in the Peers ASN. (a BGP -> OSPF -> BGP redistribution most likely happened)
If eBGP is better than IS-IS/OSPF, then all Telstra traffic (including routes to their own website and their own primary DNSs) went to the peer. Traffic ended up ping-pong'ing between the Peer and Telstra until TTL Expired. (I happen to be a Telstra xDSL subscriber as well at home - got a few traceroutes that looked like this).
Naturally a prefix-limit would have helped; or a route-filter prefix-list... alas apparently neither of these were in effect.
Fun and excitement down under... I have a feeling everyone is re-checking their BGP stanzas with a fine toothed comb today. =)
- Chris.
------------------------------
Message: 4
Date: Thu, 23 Feb 2012 07:23:24 +0000
From: Paul Zugnoni <paul.zugnoni at onlive.com>
To: Jeff Wheeler <jsw at inconcepts.biz>
Cc: juniper-nsp <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] Set MED in BGP to IGP metric for iBGP NEXT-HOP
router
Message-ID: <4C4C57FD-4533-4113-BA61-B9059F2AB1EE at onlive.com>
Content-Type: text/plain; charset="us-ascii"
Hi Jeff -
Thanks for the reply. Until your email, I hadn't solved it. I was getting stuck, in part, because it appears the command does /not/ have an effect on the MED when used as an import policy applied to the iBGP neighbor (at least when using ISIS level 2 metrics). I had it configured first as an import policy and troubleshooting it that way before emailing for help last night. Secondly, I hadn't yet tried clearing the BGP neighbor, and curiously found this to update my eBGP peer with the updated metric after the right export policy was applied: clear bgp neighbor 10.1.1.1 soft-minimum-igp
We're on the same page re: metric minimum-igp; thanks for the distinction on the RR advertised route, too.
Paul Zugnoni
On Feb 22, 2012, at 17:29 , Jeff Wheeler wrote:
On Tue, Feb 21, 2012 at 7:25 PM, Paul Zugnoni <paul.zugnoni at onlive.com<mailto:paul.zugnoni at onlive.com>> wrote:
I'm looking to set the MED on routes exported to eBGP peers to reflect the IGP metric to the BGP protocol next-hop
I did not see any replies to your question. Apologies if you already
figured this out yourself.
set metric igp already does what you describe. You will also want to
read the documentation on `set metric minimum-igp` which is often what
folks really want.
Keep in mind that the MED will be set to the IGP metric to the
protocol next-hop, NOT "the address of the router it learned the route
from." You used both phrasings in your post. So for example, if you
have a route reflector in your AS, a route may be learned from an RR
but the metric will obviously not be based on the path to the RR, but
the path to the next-hop.
--
Jeff S Wheeler <jsw at inconcepts.biz<mailto:jsw at inconcepts.biz>>
Sr Network Operator / Innovative Network Concepts
------------------------------
Message: 5
Date: Thu, 23 Feb 2012 11:31:43 +0100
From: Daniel Roesen <dr at cluenet.de>
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Sources for SFP+ optics
Message-ID: <20120223103143.GA318 at srv03.cluenet.de>
Content-Type: text/plain; charset=us-ascii
On Wed, Feb 22, 2012 at 02:27:40PM -0600, Robert Juric wrote:
> Juniper also has only tested and verified their equipment with their
> optics. If you want to know without doubt that it will work, go
> straight to the source.
"Without doubt" will give you surprises. See PR/486951 for extended
fun with certain revision of Juniper-premium-price-sold Picolight/JDSU
XFPs with links not coming up anymore. Or the desaster with early
revision of Methode Elec. SFP-T which had a bad physical design of
the locking/ejection mechanics so you were almost unable to remove
them from without damaging the DPC.
Bottom line: we had far less trouble with 3rd party transceivers than
with Juniper premium priced transceivers.... for a fraction of cost.
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
------------------------------
Message: 6
Date: Thu, 23 Feb 2012 05:11:15 -0600
From: Kevin Wormington <kworm at sofnet.com>
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] IS-IS routes not installed
Message-ID: <4F461ED3.706 at sofnet.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I have a lab setup with three nodes (2 M7i and 1 EX4200) in the
following topology (forgive the bad ascii art):
M7i1 <--> EX
\ /
\ /
M7i2
The links between them are all gige going through layer2 switches with a
VLAN 302 that all devices are a member of and VLAN 300 which is only the
link between M7i2 and EX. IS-IS adjacencies form between all the
devices and routes are propogated as expected when all links are up. If
I break the link between M7i1 & EX by removing the EX from the VLAN
between them then after convergence time from the EX I see the correct
routes to M7i1 coming through via M7i2 and on M7i1 I see the correct
route to EX via M7i2. However, if I instead break the connection
between the EX and M7i2 then from M7i1 I see the correct routes coming
from the EX and M7i2, but on the EX I don't see the routes to M7i2
coming via M7i1 and on M7i2 I don't see the routes from EX coming via
M7i1. On M7i2 and EX the IS-IS database does show the TLVs of the
routes...they are just not installed into the routing table. By routes
I mean a few directly connect routes and the loopback /32s.
The method I used to simulate a link failure was to remove either VLAN
from the trunk port of the EX.
This is a single level (level2 only) single area setup. As to why the
crazy vlan setup and secondary IP config you will see below...trying to
mock up something that sort of exists in the real world as part of a
transition. I must be missing something simple. Any pointers would be
appreciated.
Thanks
Kevin
Config snippets:
EX
kevin at ex> show configuration protocols isis
export isis-export;
level 1 disable;
interface lo0.0 {
passive;
}
interface vlan.300;
interface vlan.302;
kevin at ex> ...cy-options policy-statement isis-export
term term-1 {
from {
route-filter 0.0.0.0/0 exact;
}
then reject;
}
term term-2 {
from protocol static;
then accept;
}
term term-3 {
from protocol direct;
then accept;
}
kevin at ex> show configuration interfaces lo0
unit 0 {
family inet {
address 10.10.10.242/32;
}
family iso {
address 49.0001.0100.1001.0242.0001.00;
}
}
kevin at ex> show configuration interfaces vlan unit 300
family inet {
description "M7i2 link"
address 10.10.10.231/28;
}
family iso;
kevin at ex> show configuration interfaces vlan unit 302
description "M7i1 link";
family inet {
address 10.20.20.10/30;
}
family iso;
M7i1
kevin at m7i1> show configuration protocols isis
export isis-export;
level 1 disable;
interface ge-1/0/0.0;
interface lo0.0 {
passive;
}
kevin at m7i1> ...cy-options policy-statement isis-export
term term-1 {
from {
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term term-2 {
from protocol static;
then accept;
}
term term-3 {
from protocol direct;
then accept;
}
kevin at m7i1> show configuration interfaces ge-1/0/0
description "Link to M7i2 and EX";
unit 0 {
family inet {
address 10.20.20.6/30;
address 10.20.20.9/30;
}
family iso;
}
kevin at m7i1> show configuration interfaces lo0
unit 0 {
family inet {
address 10.20.20.32/32;
}
family iso {
address 49.0001.0100.2002.0032.0001.00;
}
}
M7i2
kevin at m7i2> show configuration protocols isis
export isis-export;
level 1 disable;
interface ge-1/3/0.300;
interface ge-1/3/0.302;
interface lo0.0 {
passive;
}
kevin at m7i1> ...cy-options policy-statement isis-export
term term-1 {
from {
route-filter 0.0.0.0/0 exact;
}
then reject;
}
term term-2 {
from protocol static;
then accept;
}
term term-3 {
from protocol direct;
then accept;
}
kevin at m7i2> show configuration interfaces ge-1/3/0 unit 300
description "EX Link";
vlan-id 300;
family inet {
address 10.10.10.228/28;
}
family iso;
kevin at m7i2> show configuration interfaces ge-1/3/0 unit 302
description "M7i1 Link";
vlan-id 302;
family inet {
address 10.20.20.5/30;
}
family iso;
kevin at m7i2> show configuration interfaces lo0
unit 0 {
family inet {
address 10.10.10.240/32;
}
family iso {
address 49.0001.0100.1001.0240.0001.00;
}
}
------------------------------
Message: 7
Date: Thu, 23 Feb 2012 07:46:51 -0600
From: Robert Juric <robert.juric at gmail.com>
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Sources for SFP+ optics
Message-ID:
<CABq8KQ=TwgsVx0bYD4Er=DMBa36cG-2q-FfCZZSN-SLPRJyE8g at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Thanks for the insights. Which 3rd party transceivers have you had the best
luck with then?
Robert
On Thu, Feb 23, 2012 at 4:31 AM, Daniel Roesen <dr at cluenet.de> wrote:
> On Wed, Feb 22, 2012 at 02:27:40PM -0600, Robert Juric wrote:
> > Juniper also has only tested and verified their equipment with their
> > optics. If you want to know without doubt that it will work, go
> > straight to the source.
>
> "Without doubt" will give you surprises. See PR/486951 for extended
> fun with certain revision of Juniper-premium-price-sold Picolight/JDSU
> XFPs with links not coming up anymore. Or the desaster with early
> revision of Methode Elec. SFP-T which had a bad physical design of
> the locking/ejection mechanics so you were almost unable to remove
> them from without damaging the DPC.
>
> Bottom line: we had far less trouble with 3rd party transceivers than
> with Juniper premium priced transceivers.... for a fraction of cost.
>
>
> Best regards,
> Daniel
>
> --
> CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
------------------------------
Message: 8
Date: Thu, 23 Feb 2012 07:53:00 -0600
From: Tim Jackson <jackson.tim at gmail.com>
To: Robert Juric <robert.juric at gmail.com>
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Sources for SFP+ optics
Message-ID:
<CAK19Y1dqggeR7sD6Uqkj6---i8bHmhsQWeJhhWzMuPwpC0GESw at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Personally I've never had a single issue with Finisar, Fujitsu, or Opnext.
SFP, SFP+, or XFP.
On Thu, Feb 23, 2012 at 7:46 AM, Robert Juric <robert.juric at gmail.com> wrote:
> Thanks for the insights. Which 3rd party transceivers have you had the best
> luck with then?
>
> Robert
>
> On Thu, Feb 23, 2012 at 4:31 AM, Daniel Roesen <dr at cluenet.de> wrote:
>
>> On Wed, Feb 22, 2012 at 02:27:40PM -0600, Robert Juric wrote:
>> > Juniper also has only tested and verified their equipment with their
>> > optics. If you want to know without doubt that it will work, go
>> > straight to the source.
>>
>> "Without doubt" will give you surprises. See PR/486951 for extended
>> fun with certain revision of Juniper-premium-price-sold Picolight/JDSU
>> XFPs with links not coming up anymore. Or the desaster with early
>> revision of Methode Elec. SFP-T which had a bad physical design of
>> the locking/ejection mechanics so you were almost unable to remove
>> them from without damaging the DPC.
>>
>> Bottom line: we had far less trouble with 3rd party transceivers than
>> with Juniper premium priced transceivers.... for a fraction of cost.
>>
>>
>> Best regards,
>> Daniel
>>
>> --
>> CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
------------------------------
_______________________________________________
juniper-nsp mailing list
juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
End of juniper-nsp Digest, Vol 111, Issue 31
********************************************
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
More information about the juniper-nsp
mailing list