Re: BGP hijack?

[Olivier Benghozi]

Same stuff (with our ASN and our prefixes) detected here, coming
from AS2027 (Milkywan), for a short time...

Le dim. 22 oct. 2023 à 17:18, Hank Nussbacher  a
écrit :

> We just had every single prefix in AS378 start being announced by AS2027.
>
> Every announcement by AS2027 is failing RPKI yet being propagated a bit.
> Is this yet another misbehaving device or an actual attack?
>

-- 
*Ce message et toutes les pièces jointes (ci-après le "message") sont 
établis à l’intention exclusive des destinataires désignés. Il contient des 
informations confidentielles et pouvant être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de détruire le message. Toute utilisation de 
ce message non conforme à sa destination, toute diffusion ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
de l'émetteur*

Re: Telia Not Withdrawing v6 Routes

[Olivier Benghozi]

One of the routing gears on the path don't like the large community inside 
those routes maybe ? :)
By the way we currently see 2620:6e:a002::/48 at LINX LON1 from Choopa and HE...

> Le 16 nov. 2020 à 04:44, Matt Corallo  a écrit :
> 
> Yea, I did try that on that test prefix but it just stuck around anyway.. I 
> don't care too much, its just some stale test prefix.
> 
> Sadly, I now see it again with 2620:6e:a002::/48, which, somewhat more 
> impressively, is now generating a routing loop Ashburn <-> NYC, and has 
> always been announced from other places has was dropped/re-announced as wel.
> 
> Must just be something with my particular prefixes, oh well.
> 
> Matt
> 
> On 11/15/20 10:40 PM, Olivier Benghozi wrote:
>> Probably a ghost route. Such thing happens :(
>> https://labs.ripe.net/Members/romain_fontugne/bgp-zombies
>> Their (nice) LG shows that it's still advertised from a router of theirs in 
>> Frankfurt (iBGP next hop :::2.255.251.224 – so by the way they use 6PE).
>> Your best option would probably be to re-advertise the exact same prefix, 
>> then re-withdraw it, then yell at Telia's NOC if it fails...
>> Some years ago we experienced something similar (it was a router of TI 
>> Sparkle still advertising a prefix of us in Asia to their clients, that they 
>> were previously receiving from our former transit GTT – we were advertising 
>> it in Europe...).
>>> Le 16 nov. 2020 à 02:58, Matt Corallo  a écrit :
>>> 
>>> Has anyone else experienced issues where Telia won't withdraw (though will 
>>> happily accept an overriding) prefixes for the past week, at least?
>>> 
>>> eg 2620:6e:a003::/48 was a test prefix and should not now appear in any 
>>> DFZ, has not been announced for a few days at least, but shows up in 
>>> Telia's LG and RIPE RIS as transiting Telia. Telia's LG traceroute doesn't 
>>> of course, go anywhere, traces die immediately after a hop or with a !N.
>>> 
>>> Wouldn't be a problem except that I needed to withdraw another route due to 
>>> a separate issue which wouldn't budge out of Telia's tables until it was 
>>> replaced with something else of higher pref.
>>> 
>>> Matt

Re: Telia Not Withdrawing v6 Routes

[Olivier Benghozi]

Probably a ghost route. Such thing happens :(

https://labs.ripe.net/Members/romain_fontugne/bgp-zombies

Their (nice) LG shows that it's still advertised from a router of theirs in 
Frankfurt (iBGP next hop :::2.255.251.224 – so by the way they use 6PE).

Your best option would probably be to re-advertise the exact same prefix, then 
re-withdraw it, then yell at Telia's NOC if it fails...


Some years ago we experienced something similar (it was a router of TI Sparkle 
still advertising a prefix of us in Asia to their clients, that they were 
previously receiving from our former transit GTT – we were advertising it in 
Europe...).


> Le 16 nov. 2020 à 02:58, Matt Corallo  a écrit :
> 
> Has anyone else experienced issues where Telia won't withdraw (though will 
> happily accept an overriding) prefixes for the past week, at least?
> 
> eg 2620:6e:a003::/48 was a test prefix and should not now appear in any DFZ, 
> has not been announced for a few days at least, but shows up in Telia's LG 
> and RIPE RIS as transiting Telia. Telia's LG traceroute doesn't of course, go 
> anywhere, traces die immediately after a hop or with a !N.
> 
> Wouldn't be a problem except that I needed to withdraw another route due to a 
> separate issue which wouldn't budge out of Telia's tables until it was 
> replaced with something else of higher pref.
> 
> Matt

Re: rfc4271 ORIGIN/path of default route, should the value be 0 or 2?

[Olivier Benghozi]

Debatable, certainly, as the Origin attribute should probably be considered as 
dead/obsolete and therefore it is probably a good practice to always set/reset 
it to internal.
A number of networks already do this (including level3 by example).

After all, the origin attribute was only designed to allow a «smooth» 
transition between EGP and BGP (that is, it was useful during a few years for a 
few networks several decades ago).

> Le 7 juil. 2020 à 15:47, Saku Ytti  a écrit :
> 
> Debatable, but:
> Internal is more accurate if you redistribute default from routing
> protocol, such as static.
> Unknown is more accurate if you just generate it in BGP, without having it.
> 
> Functional difference is best-path selection algorithm. Origin can be
> used to bypass hot-potato policies of peers, by forcing them to carry
> packets longer inside their network. If your policy is hot-potato,
> then you should reset Origin on received external routes.

Re: breakout

[Olivier Benghozi]

Hi,

yep, that's the right way to work cleanly, just add a «special patch panel» 
instead of dealing with plenty of additional wires.

We use such method to do 10GE with routers modules full of QSFP+ configured as 
4x10. On our side we went for a modular Huber+Suhner solution, 1 U with a 
maximum of 18 MTP (from 18 QSFP+) internally wired to 72 LC duplex.
I searched a bit before choosing this, it looks like this was (still is ?) the 
denser solution.

They are divided in modules of 3 MTP to 12 LC-duplex (wired accordingly to the 
QSFP+ / MTP8 pairing):
https://ecatalog.hubersuhner.com/product/E-Catalog/Fiber-optics/Fiber-management-systems/Modules/ITD-12-LCUD-03-08CF-SM-NS-00WW
 


They go inside some various chassis, we use their 1U one than can host 6 of 
such modules:
https://ecatalog.hubersuhner.com/product/E-Catalog/Fiber-optics/Fiber-management-systems/Chassis/IANOS-STD-CHASSIS-FLX-1U-2G-T4
 


We use them since 2017: https://twitter.com/OBenghozi/status/885528976801837057 



regards,
Olivier

> Le 9 janv. 2020 à 17:29, Baldur Norddahl  a écrit :
> 
>  Hello
> 
> In my opinion the "nice" way of breaking out QSFP into 10G is something like 
> this:
> 
> https://www.fs.com/de-en/products/43552.html 
>  
> 
> 40GBASE-PLR4 to 10GBASE-LR Breakout Panel 1U Rack-Mount, 24x LC Quad, 12x MTP 
> Elite (0.35dB IL), Single Mode
> 
> You connect your QSFP module using a MTP cable to the breakout panel. That 
> particular panel will accept up to 12x MTP connections (12 QSFP ports) which 
> equals 48x 10G LR 10 km single mode. 
> 
> If you don't need quite that many breakouts this solution is also available 
> in smaller cassettes:
> 
> https://www.fs.com/de-en/products/68401.html 
>  
> 
> MTP-8 to 4x LC Duplex, 8 Fibres OS2 Single Mode FHD MTP Cassette
> 
> That will terminate one MTP cable (1 QSFP port).
> 
> I prefer the panel solution over breakout cables because the later assumes 
> all the connections are going the same place. Also the panel solution will 
> appear as an extension of the switch or router. Mentally it is simply extra 
> ports on a separate panel.
> 
> Regards,
> 
> Baldur 

Re: MX10003 rack size

[Olivier Benghozi]

Hi,

here it does fit in 600x1000 racks (APC & Minkels), with everything plugged, 
airfilter/frontpanel installed, doors closed.
Front door / front rails / rear rails / rear door: 15cm / 72cm / 12cm


> Le 6 août 2019 à 14:50, im  a écrit :
> 
> In my case, MX10003 needs 13cm gap between front-door and fron-panel,
> and needs 10cm gap between back-door and back-panel.
> 
> You need at least 120cm depth.

Re: Mx204 alternative

[Olivier Benghozi]

By the way they now say in this KB article that they implemented a «high 
performance mode» for MX204 / MX10003 with some «set chassis fpc slot 
high-performance-mode».
Anyone wiling to test? :)

> Le 2 sept. 2019 à 15:23, Denys Fedoryshchenko  a 
> écrit :
> 
> From snabbco discussion, issue #1013, "If you read Intel datasheets then the 
> minimum packet rate they are guaranteeing is 64B for 10G (82599), 128B for 
> 40G (XL710), and 256B for 100G (FM10K)."
> 
> But "hardware", ASIC enabled routers such as MX might be not better and even 
> need some tuning.
> https://kb.juniper.net/InfoCenter/index?page=content=KB33477=METADATA
> "On summit MX204 and MX10003 platforms, the line rate frame size is 119 byte 
> for 10/40GbE port and 95 byte for 100GbE port."

Re: Juniper BGP Convergence Time

[Olivier Benghozi]

Yep, feature naming in JunOS...
In fact I meant «Provider Edge Link Protection», which is only for VPN (and 
Labeled Unicast), and that applies here (eBGP paths are protected using iBGP 
paths).

> Le 24 mai 2018 à 13:39, Vincent Bernat <ber...@luffy.cx> a écrit :
> 
> ❦ 24 mai 2018 12:36 +0200, Olivier Benghozi <olivier.bengh...@wifirst.fr> :
> 
>> I wonder if this convergence time issue wouldn't be a typical mission for 
>> «BGP PIC Edge for MPLS Layer 3 VPNs».
>> But it would be necessary to migrate the DFZ to a VPN MPLS (and
>> configure composite nexthop and BGP PIC / «Provider Edge Link
>> Protection»).
> 
> BGP PIC is also available with IP now:
> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/bgp-configuring-bgp-pic-for-inet.html
> 
> I've asked the question two years ago on j-nsp. Here is the thread:
> https://lists.gt.net/nsp/juniper/57149
> 
> There is a step by step guide about in the middle of the guide. I didn't
> have the right version to test at the time. I didn't try again since
> then.

Re: Juniper BGP Convergence Time

[Olivier Benghozi]

I wonder if this convergence time issue wouldn't be a typical mission for «BGP 
PIC Edge for MPLS Layer 3 VPNs».
But it would be necessary to migrate the DFZ to a VPN MPLS (and configure 
composite nexthop and BGP PIC / «Provider Edge Link Protection»).

> Le 24 mai 2018 à 09:20, Vincent Bernat  a écrit :
> 
> This feature is already enabled on MX with MPC cards.
> 
> ――― Original Message ―――
> From: Adam Kajtar 
> Sent: 23 mai 2018 23:21 -0400
> Subject: Re: Juniper BGP Convergence Time
> To: Mark Tinka
> Cc: nanog@nanog.org
> 
>> Hello again:
>> 
>> I've tried using the default route, adjusting bgp timers, and mutlipath.
>> Unfortunately, these changes haven't helped much. Juniper support hasn't
>> been very helpful also. Although, I think I might have found the solution.
>> 
>> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/forwarding-indirect-next-hop.html
>> 
>> Let me know what you think.
>> 
>> On Tue, May 22, 2018, 4:03 AM Mark Tinka  wrote:
>> 
>>> 
>>> 
>>> On 16/May/18 18:59, Phil Lavin wrote:
>>> 
>>> Ask if they will configure BFD for you. I’ve not found many transit
>>> providers that will, but it’s worth a shot and it will lower failure
>>> detection to circa 1 second.
>>> 
>>> We've tended to shy away from it, but we have 2 customers we've done it
>>> for.

Re: MTU to CDN's

[Olivier Benghozi]

And also:

When the router generates the ICMP by punting the packet to its CPU and such 
traffic is - legitimately - rate-limited to avoir crashing the router.

When the ICMP is sourced by a private IP on the router for various legitimate 
reasons (not enough public IPv4 addresses, from within a VRF, or whatever), 
while packets from private IPs are legitimately filtered when entering the 
target network.


> Le 19 janv. 2018 à 15:05, Mikael Abrahamsson  a écrit :
> 
> On Fri, 19 Jan 2018, Mike Hammett wrote:
> 
>> Other than people improperly blocking ICMP, when does PMTUD not work? Honest 
>> question, not troll.
> 
> Mismatch of MTU interface settings between interfaces, mismatch of MTU 
> between L3 devices and intermediate L2 devices, anycast services, ECMP based 
> services where the ICMP error is delivered to the wrong node.
> 
> So yes, there are plenty reasons that PMTUD doesn't work without anyone doing 
> it because of ill will or incompetence.

Re: connection to ix

[Olivier Benghozi]

Sure, plenty of people use such service.

If you have much traffic, you'll rely on one dedicated port for each IX, and 
maybe one full 10G wave or more toward each one (so the remote service is only 
transport, you have your own port at each IX).

If not, you'll use ethernet over MPLS service for remote peering, provided by 
guys like IX-Reach, who will provide you shared bandwidth over their own 
connection at each IX, delivered on one single port (or more) toward you.
It's shared bandwidth, so you must trust the provider network, in case of DDoS 
on its ports your traffic will be at risk, you don't see if the remote port is 
down.
But the price can be quite more interesting, you don't have to deal with the 
remote physical interco, and so on.

Now, you have to find someone providing remote peering to the IXs you want, to 
check the price...

> Le 18 janv. 2018 à 13:24, Rudolph Daniel  a écrit :
> 
> How do i remotely connect to an ix?
> In the en. speaking caribbean we have probably six to eight small national
> ixps. I want to be present at all of them, & its been suggested i can make
> some cost savings by remote connection using mpls.  Is this a viable
> option? Is there a disadvantage in doing this? Thx.
> 
> Rudi

Re: Foundry FastIron

[Olivier Benghozi]

By the way, Foundry/Brocade small/campus switches were sold by Broadcom to 
Ruckus, not to Extreme (who bought the bigger switch/routers).

https://support.ruckuswireless.com/product_families/21-ruckus-icx-campus-switches
 


https://support.ruckuswireless.com/product_families/23-_eol-fastiron-products 


Of course, as it is an end of life product in their shopping bag, I wouldn't 
expect much :)


> On 29 dec. 2017 at 09:19, Mike O'Connor  wrote :
> 
>> A client of mine has some Foundry FastIron Edge X424HFs.
>> 
>> Brocade and Extreme don't seem overly ambitious to help.
>> 
> Brocade EOL'ed those old FESX-4 switches themselves on 03/31/2011, 
> with EOS in 2016.  This was before Brocadecom spun off to Extreme.

Re: Chinese websites loading slower recently?

[Olivier Benghozi]

I can confirm, several customers complaining of being suddenly unable to access 
baidu/weibo and so on
Same conclusion ensues.

> On 20 oct. 2017 at 23:27, Tianhao Xiao  wrote :
> 
> The National Congress[0] just happened, and the Chinese government does
> make a very big deal out of it. I know that many universities were asked
> to temporarily block inbound HTTP traffic, which even affected open
> source mirrors during that time. 
> 
> With all this going on it is only natural that something restrictive
> happened to the rest of the international network. I'm not exactly sure
> what has been done, but it is very likely that it is not your problem.
> 
> 
> On Fri, 20 Oct 2017, at 08:51, Simon Lockhart wrote:
>> 
>> Is anyone else seeing an increase in problems related to Chinese
>> websites?

Re: Point 2 point IPs between ASes

[Olivier Benghozi]

Well, /112 is not a stupid option (and is far smarter than /64): it contains 
the whole last nibble of an IPv6, that is x:x:x:x:x:x:x:1234.
You always put 1 or 2 at the end, and if needed you are still able to address 
additional stuff would the point-to-point link become a LAN.
And you don't throw away billions of addresses like with /64.

> On 29 jun 2017 at 02:32, William Herrin  wrote :
> 
> On Wed, Jun 28, 2017 at 8:01 PM, Aaron Gould  wrote:
> 
>> I think this is funny... I have (4) 10 gig internet connections and here's
>> the maskings for my v6 dual stacking...
>> 
>> /126 - telia
>> /64  - att
>> /112 - cogent
>> /127 - twc/charter/spectrum
> 
> 112... Could be worse I suppose. They could have picked 113.

Re: Long AS Path

[Olivier Benghozi]

Yes, we had this kind of stuff in our logs:

Jun 20 08:15:25  cr-co-01-pareq2-re0 rpd[9656]: %DAEMON-3: Prefix Send failed ! 
x:x:186.177.176.0/23 (label 19) bgp_rt_trace_too_big_message:1213 path 
attribute too big. Cannot build update.

The AS path we have here is currently 12956 262206 262206 262197...

> On 21 june 2017 at 01:12, James Braunegg  wrote :
> 
> Just wondering if anyone else saw this yesterday afternoon ?
> 
> Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH= AS_SEQ(2) 
> 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 
> 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 
> 23456 23456 23456 23456 ... attribute length (567) More than configured 
> MAXAS-LIMIT
> 
> Someone is having fun, creating weird and wonderful long AS paths based 
> around AS 23456, we saw the same pattern of data from numerous upstream 
> providers.

Re: Lille, France

[Olivier Benghozi]

There's also Eurafibre, I guess.

> Le 25 mai 2017 à 08:15, Jérôme Fleury  a écrit :
> 
> SFR (soon to be renamed Altice) and Orange for sure have metropolitan
> networks in Lille.
> 
> There might be others depending on your needs.
> 
> On Wed, May 24, 2017 at 12:03 PM, Rod Beck 
> wrote:
> 
>> I am looking for insight into which carriers have metropolitan or last
>> mile networks in this city. Preferably connected to Paris.

Re: google ipv6 routes via cogent

[Olivier Benghozi]

Due to various peering disputes (notably with Hurricane Electric) Cogent just 
don't have all the routes in IPv6 (and should be regarded as a partial IPv6 
transit only).
One should not rely only on Cogent for its transit, anyway :)
Don't count on any improvement soon. It was already discussed here one year 
ago...

> On 25 feb. 2017 at 16:49, Aaron  wrote :
> 
> Cogent is telling me that I can't route through cogent to get to google ipv6
> routes (particularly the well known dns addresses 2001:4860:4860::88xx)
> because google decided not to advertise those route to one of their mutual
> peers.
> 
> Anyone know anything about this ?  .and why it happened and when it will be
> resolved ?

Re: Juniper Advertise MED on EBGP session.

[Olivier Benghozi]

What metric do you intend to advertise to an eBGP peer?

iBGP MED to eBGP MED ? MED being a non-transitive attribute, I guess it's not 
expected to work if you don't explicitly set a MED in the export policy (you 
might rely on setting and matching communities for that) or on the peer group.
It's not be expected to work on Cisco without explicitly setting the MED, 
either.

IGP metric to MED ? It seems to just work as is here, at least for RIP and OSPF 
(as long as you don't do anything to the MED in your export policy): RIP metric 
and OSPF metric  are exported spontaneously as MED (when using OSPF E2 routes, 
beware of the static aspect of their metric).


Olivier


> On 21 feb. 2017 at 16:26, Leo Bicknell  wrote:
> 
> I tried to pull an old trick out of my playbook this morning and
> failed.  I'd like to advertise BGP Metrics on an EBGP session,
> specifically the existing internal metrics.  I know how to do this
> on a Cisco, but I tried on a Juniper and it seems to be impossible.
> 
> I can set a metric in a policy, or put a default metric on the
> session as a whole, or even set it to IGP.  But none of those are
> what I want.  I want the existing metrics advertised as-is, just
> like would be done over an IBGP session.  After an hour of reading
> documentation and trying a few things, I'm starting to think it
> may be impossible on JunOS.

Re: Help interpret a strange traceroute?

[Olivier Benghozi]

Hi Randy,


ECMP loadbalancing is most frequently done on layer3+layer4 headers, and 
unixlike traceroute use UDP with increasing destination port number for each 
packet (usually starting at 33434), which allows to see the different available 
paths, as wrote William.

Would you want/need to stick to only one traceroute path, you may use ICMP 
traceroute instead of UDP traceroute (no port in ICMP, so only layer 3 
available to loadbalance, so all packets will go through the same interface).

Usually it is achieved by using traceroute -I yourdest
Windows tracert is ICMP only traceroute by the way. MTR tool is also ICMP based 
by default.

Keep in mind that it looses some useful information, though (since you see only 
one path and don't decide which).
So, you can also use UDP traceroute with fixed port (by example 33434 with no 
port increase), and try again the same traceroute with another destport (with 
fixed port too, by example 33435), which would display two different paths in a 
more readable way. RTFM is required since the options depend on your traceroute 
particular specie :)


Olivier

> On 31 oct. 2016 à 20:42, William Herrin  wrote :
> 
> On Mon, Oct 31, 2016 at 3:33 PM, Randy  wrote:
>> Any idea how a traceroute (into my network) could end up this fubar'd?
>> Discovered this wierd routing while investigating horrendously slow speeds
>> (albeit no packet loss) to a particular ISP abroad.
> 
> Hi Randy,
> 
> This is per-packet load balancing. In the forward path the alternates
> are different lengths but the traceroute stops as soon as at least one
> of the paths reaches the destination.
> 
> The return path is also engaged in per-packet load balancing but the
> paths are all the same length.

Re: IPv6 automatic reverse DNS

[Olivier Benghozi]

Already available: KnotDNS.

https://www.knot-dns.cz/docs/2.x/html/configuration.html#synth-record-automatic-forward-reverse-records
 



Olivier


> On 29 oct. 2016 à 01:02, Baldur Norddahl  wrote :
> 
> It should be simple to build a DNS server that will automatically generate a 
> hostname value for every reverse lookup received, and also be able to parse 
> that hostname value to return the correct IPv6 address on forward lookups.
> 
> Does any DNS server have that feature? Should we have it? Why not?

Re: Optical transceiver question

[Olivier Benghozi]

It's a bit like car fuel efficiency values, even with reputable brands :)

In this industry, the number of kms for such optics is a best case 
approximation of the combination of (most notably) those elements:
worst case power budget, capability to deal with chromatic scattering on this 
length without compensation, with perfect fiber attenuation values without 
connectors/splicings (by the way, per km attenuation depends of the type of 
fiber ; so it's really possible to have less than 0.4dB/km even near 1310nm).

I confirm it's normal for several optics of the same model to have a large 
panel of Tx values as soon as they are within the guaranteed Tx range.
The actual value of Tx is only guaranteed to be somewhere within the Tx range 
shown in the specs (and it will vary/lower during the life of the optic). So 
the power budget of an optic is the value in the worst case.


If you cannot OTDR the link (or just put a known source at one side and a power 
meter at the other side), then you have to estimate: take the length and the 
attenuation per km for the wavelength, add attenuation values for connectors 
(crossconnects, patches) and current splicings and so on, take a margin (at 
least 3dB let's say ?) for later splicings or small defects, and then you 
obtain the minimum power budget.

10 years later, this page is still relevant:
http://www.cisco.com/c/en/us/support/docs/optical-networking/ons-15454-sonet-multiservice-provisioning-platform-mspp/27042-max-att-27042.html
 



Anyway, you must not use the km value for anything else than sorting the 
answers before looking at the specs :)




> Le 7 sept. 2016 à 22:23, Frank Bulk  a écrit :
> 
> We recently purchased some generic optics from a reputable reseller that
> were marketed to reach 60 km.
> 
> But what we found, based on the spec sheets, is that it could only reach
> that distance if the optics were transmitting on the high side of the
> transmit power range. 
> 
> For example, if the TX range was 0 to +5 dBm and minimum RX power was -20
> dB, the designed optical budget should be no more than 20 dB (0 - -20).
> Based on the wavelength the appropriate loss would be 0.4 dB/km and results
> in only 50 km, not 60 km.  To get 60 km it would need 24 dB of link margin,
> and that would only be attainable if it was transmitting on the high side,
> at +4 dBm.
> 
> Is it an industry practice to market distance based on the hot optics, not
> on the worst case, which is minimum TX power?
> 
> Frank
> 

Re: Experience Brocade ICX7750 and other vendor SFP

[Olivier Benghozi]

I don't know if ICX behave like the FCX, but on those equipments, 
other_vendor_SFPs work perfectly (Finisar, Skylane CWDM 70km, at least).
However the brocade won't let you use optical-monitor on them if they are 
standard coded, so you won't be able to check optical values (tx/rx dBm 
levels and so on). Having the other_vendor_SFP coded as a Brocade SFP will do 
the trick however.

 Le 31 mars 2015 à 14:44, Joe McLeod jmcl...@musfiber.net a écrit :
 
 +1 on Brocade ICX 6610 with other vendor's optics.  We're using the 6610's as 
 aggregation route/switches with a mix of Cisco, Alcatel, and 3rd party optics 
 (one of which is a 10G BiDi) and have had no issues.
 
 Thanks,
 Joe
 
 -Original Message-
 From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jordan Medlen
 Sent: Tuesday, March 31, 2015 8:09 AM
 To: Florian Figula
 Cc: nanog@nanog.org
 Subject: Re: Experience Brocade ICX7750 and other vendor SFP
 
 I use the ICX 6610's which I believe run the same code train. I use other 
 vendor optics to light 3 spans of dark fiber, one of which is 60km, so I have 
 Axiom 80km optics in production there. I have had no issues. I also use the 
 VDX series switches with other vendor optics and no issues.
 
 Jordan Medlen
 Network Engineer
 Bisk Education 
 
 Sent from my iPhone
 
 On Mar 31, 2015, at 05:55, Florian Figula flor...@figula.de wrote:
 
 Hi all,
 
 does anyone have experiences regarding Brocade ICX7750 and other vendors SFP.
 
 Information will be helpful for planing new infrastructure and costs.
 
 Thanks to all!

Re: BGPMON Alert Questions

[Olivier Benghozi]

... and same here.

Indosat looks now to have developed a solid experience in BGP prefix hijack 
mess (last time was in 2011).

Olivier

 On 4/2/14, 11:51, Joseph Jenkins wrote:
 So I setup BGPMON for my prefixes and got an alert about someone in
 Thailand announcing my prefix.  Everything looks fine to me and I've
 checked a bunch of different Looking Glasses and everything announcing
 correctly.
 
 I am assuming I should be contacting the provider about their
 misconfiguration and announcing my prefixes and get them to fix it.  Any
 other recommendations?
 
 
 
 Same here for one of my /21s. Origin of AS4761 through AS4651.
 
 ~Seth
 

Re: 7206 VXR NPE-G1 throughput

[Olivier Benghozi]

Cisco once implemented and released this feature to use the second core of the 
NPE-G1, most notably to manage the BRAS  en/decapsulations tasks for 
LAC/LNS/PTA (PPPoE, L2TP...), effectively offering such 1.6 factor.
It was called MPF, and was released in special 12.3-YM IOS (in 2004/2005 I 
guess).
The first core was still running normal IOS while the second core was running 
a dedicated microcode (acting as some sort of data plane).

However several features were not available, and it was quite buggy and 
unstable (unless you only used the very minimum features implemented in the MPF 
microcode: no MSS adjust, no ACL for PPP sessions...).
It was quickly deprecated anyway.
http://www.cisco.com/en/US/prod/collateral/routers/ps341/prod_end-of-life_notice0900aecd8067dd9f.html


Le 10 févr. 2014 à 21:38, Mark Tinka mark.ti...@seacom.mu a écrit :

 On Monday, February 10, 2014 07:58:16 PM Nick Hilliard 
 wrote:
 
 in fact, the npe-g1 uses a BCM1250 which is a dual CPU
 unit but vanilla IOS is not able to use the second CPU
 for packet forwarding.  Unsubstantiated rumour claimed
 that modular IOS (QNX kernel) could push about 1.6x the
 throughput of vanilla IOS, as it was smp capable.  Pity
 it was never released.
 
 Haha, you remind me of PXF (although that was the NSE-100 
 and NSE-150).
 
 Mark.

Re: carrier comparison

[Olivier Benghozi]

Hi Faisal,

 You might have to deploy some other means of (script ?) to bring your BGP 
 session down from the 'broken' Service Provider.
 
 To the best of my knowledge, BGP does not have any mechanism to determine 
 broken connectivity upstream past the router you are BGP session is up with.

Well, technically there's BFD that might do the trick. But of course it won't 
be available; it's not usually, so specially with Cogent... :)
But maybe its link was just overloaded in fact.


-- 
Olivier

Re: carrier comparison

[Olivier Benghozi]

Hi Vlade,

Well, if you are trying to balance the incoming traffic load with local-pref 
attribute, I can understand your disappointment :)
Since it doesn't work at all this way: local-pref is local to an AS and deals 
with outgoing traffic only.

 B)  We have our own AS and IP space. I advertise them to both Cogent and our 
 other ISP. I use the local preference attribute to share the load for 
 incoming traffic between both ISPs. In the last 5 outages over the last few 
 years, this has happened twice. I'm waiting on the RFO so I can further 
 investigate why this happened. I think someone mentioned this in a post a few 
 months ago too.


-- 
Olivier

Re: BRAS

[Olivier Benghozi]

Hi,

Le 11 déc. 2013 à 17:14, Nilesh Kahar nilesh.ka...@outlook.com a écrit :
 Also wanted to know about any other good BRAS product which can act fine for 
 LNS - LAC setup.

Ericsson SmartEdge
Cisco ASR1000

Re: Redundant multicast routing

[Olivier Benghozi]

Hi,

While anycast RP is better (redundancy is faster), it's not necessary: you can 
just use PIM-SM with BSR  2 RPs with hash-mask distribution for the layer 3 
redundancy.

By design, igmp snooping forwards all multicast traffic to mrouter ports (that 
is, all router interfaces with pim activated), so to stop useless traffic 
between the routers, it will be necessary to do something at the layer 2 level; 
you can remove some of this by using something like cisco's ip pim snooping 
dr-flood on the layer 2 part (on the receiving vlans).

regards,
Olivier



 Hi
 
 What's your recipe to implement redundant multicast (stub) routing?
 Let's think about the simplest scenario. We have 2 routers, R1 and R2
 and 3 ip networks. All 3 networks are directly connected to both
 routers and the routers are performing unicast routing between
 networks using VRRP as the redundancy protocol. Let's disregard L2
 redundancy here and assume it works. Same goes with igmp snoop.
 
 net1: 192.168.1.0/24, VRRP .254, R1 .1, R2 .2
 net2: 192.168.2.0/24, VRRP .254, R1 .1, R2 .2
 net3: 192.168.3.0/24, VRRP .254, R1 .1, R2 .2
 
 Say multicast source is in net1 and receiver in net2.
 
 If I did not need redundancy in multicast, I would just configure all
 interfaces on R1 as pim passive and it would (probably) work. But if I
 want the multicast routing to be redundant, what should I do?
 
 If I add the R2 interfaces as pim passive, the multicast is forwarded
 to net2 (and net3) twice because R1 and R2 do not know about each
 other. I tested this.
 If I configure all R1 and R2 interfaces as pim dense, the destination
 receives multicast fine, but it is flooded between R1 and R3 2 or 3
 times (because pim dense floods the multicast to all pim neighbors and
 R1 and R2 are pim neighbors in all 2 networks). So, core links are
 unnecessarily consumed. I tested this, too.
 
 One choice could be to use pim sparse and configure R1 and R2 to be
 anycast RPs using loopback interface and configure MSDP peering
 between them. But given the simplicity of the topology, this seems
 unnecessarily complex configuration. I have not tested this yet.
 
 Maybe MVR could be solution but I think it will cause stream
 multiplication too. I have not tested MVR yet either.
 
 I would like to keep the recipe as vendor agnostic as possible.
 
 Thanks for help :)
 

Re: IPTV and ASM

[Olivier Benghozi]

  For example Apple products don't support IGMPv3.

Implemented at last in 2011 (!) under OSX Lion, 10 years after Windows XP...
$ sysctl net.inet.igmp.default_version
net.inet.igmp.default_version: 3

Re: bgp update destroying transit on redback routers ?

[Olivier Benghozi]

Aha, it looks that our Quebecer friends from Hostlogistic (AS46609) have again 
been advertising their now famous funny aggregate with their mad Brocade 
router, since yesterday 10pm UTC (that is 5pm in Quebec)...
Same route to 206.125.164.0/22, same AGGREGATOR attribute full of 0.

At least I can say that the patched Ericsson's bgpd stopped reseting the 
sessions.


regards,
Olivier


Le 2 déc. 2011 à 23:14, Jeff Tantsura a écrit :

 Hi Alexandre,
 
 You are right, the behavior is exactly as per RFC4271 section 6:
 When any of the conditions described here are detected, a
 NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data 
 fields, is sent, and the BGP connection is closed.
 So because ASN 0 in AGGREGATOR is seen as a malformed UPDATE we send 3/9 and 
 close the connection.
 
 Ideally it should be treated as treat-as-withdraw as per 
 draft-chen-ebgp-error-handling, however please note - this is still a draft, 
 not a normative document and with all my support it takes time to implement.
 
 Once again, we understand the implications for our customers and hence going 
 to disable ASN 0 check.
 
 P.S. We have strong evidence that the update in question was caused by a bug 
 on a freshly updated router (I'm not going to disclose the vendor) 
 
 Regards,
 Jeff
 
 
 -Original Message-
 From: Alexandre Snarskii [mailto:s...@snar.spb.ru] 
 Sent: Friday, December 02, 2011 6:36 AM
 To: Jeff Tantsura
 Cc: nanog@nanog.org
 Subject: Re: bgp update destroying transit on redback routers ?
 
 On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote:
 Hi,
 
 Let me take it over from now on, I'm the IP Routing/MPLS Product 
 Manager at Ericsson responsible for all routing protocols.
 There's nothing wrong in checking ASN in AGGREGATOR, we don't really 
 want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 
 (draft-ietf-idr-as0-00) came into the worlds.
 
 This draft says that
 
 If a BGP speaker receives a route which has an AS number of zero in the 
 AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a 
 WITHDRAW. This same behavior applies to routes containing zero as the 
 Aggregator or AS4 Aggregator.
 
 but observed behaviour was more like following: 
 
 If a BGP speaker receives [bad route] it MUST close session immediately with 
 NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with 
 optional attribute'.

Re: bgp update destroying transit on redback routers ?

[Olivier Benghozi]

Alexandre Snarskii s...@snar.spb.ru wrote:
 AGGREGATOR is an optional transitive attribute of length 6.
 The attribute contains the last AS number that formed the
 aggregate route (encoded as 2 octets), followed by the IP
 address of the BGP speaker that formed the aggregate route
 (encoded as 4 octets).  Usage of this attribute is described
 in 5.1.7
 
 And what to do with 4-byte AS-numbers then? That would explain the 8 bytes.


Hi,

we also have some issues with this here, the update message the Redback logged 
is:

 
 
 
 
0049  02

002e
4001 01 00
4002 12   02   04   0513  0d1c  b611  b611
4003 04 50ef82c1
4006 00
c007 08 00    00
16 ce7d a4


The prefix is 206.125.164.0/22, AS-PATH is 1299 3356 46609 46609 (Telia, 
Level3, and finally Hostlogistic with one prepend).
The AGGREGATOR is full of 0. I guess this could be what bothers the 
Redback/Ericsson code.

I see the same route by other sessions, and the aggregator looks OK, since the 
sh bgp says:

206.125.164.0/22
[...]
8218 4436 46609 46609
[...]
  Origin incomplete, localpref 100, med 100, weight 100, external, best
  aggregator: 206.125.165.242, AS 46609, atomic-aggregate


So Hostlogistic route to Level3 is malformed (according to the RFC, the 
AGGREGATOR content is mandatory if the attribute is present), but their route 
to NLayer is OK. Or maybe a Level3 router has a problem?
Anyway, our Redback/Ericsson routers are the problem now, since the other 
vendors don't throw away the BGP sessions...
I've opened a case at Ericsson, still waiting for an answer :-/


regards,
Olivier Benghozi
Wifirst