- mice-discuss - lists.micemn.net

DocuMNtray

by David Farmer

This is a great DocuMNtray about the Minnesota Tech Industry both historic and where it going in the future. http://www.documntary.com/ We should have a like to this on the MICE page. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

Oct. 11, 2016

Minutes

by Richard Laager

Did anyone take minutes at the last user group meeting? If so, can I get a copy of the draft minutes for the website? -- Richard

Oct. 10, 2016

Re: BFD support on BGP sessions

by Andrew Hoyos

> > On Oct 7, 2016, at 5:07 PM, Andrew Hoyos <hoyosa(a)gmail.com> wrote: > >> >> On Oct 7, 2016, at 4:47 PM, Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: >> >> protocol bfd { >> interface "bce1" { >> min rx interval 20 ms; >> min tx interval 50 ms; >> idle tx interval 300 ms; >> passive; >> }; >> neighbor 206.108.255.3; >> neighbor 206.108.255.4; >> neighbor 206.108.255.5; >> neighbor 206.108.255.6; >> neighbor 206.108.255.7; >> neighbor 206.108.255.8; >> .... >> } > > Based on http://bird.network.cz/?get_doc&f=bird-6.html, I’d suggest something a bit less aggressive like 500ms x 3. I know a number of us here are using similar timer settings with good luck. idle tx would seem to not be required since it’s in passive mode (so it won’t send packets to a neighbor until it gets one first) > > protocol bfd { > interface "bce1" { > interval 500 ms; > multiplier 3 > passive; > }; And for the neighbors, you’d want to tie these to the BGP sessions rather than creating direct sessions inside 'protocol bfd'. If you add the ‘bfd’ switch to BGP sessions, it will dynamically create the BFD sessions, and tie BGP state to BFD. -- Andrew Hoyos hoyosa(a)gmail.com

Oct. 7, 2016

Re: BFD support on BGP sessions

by Andrew Hoyos

> On Oct 7, 2016, at 4:47 PM, Doug McIntyre <merlyn(a)IPHOUSE.NET> wrote: > > protocol bfd { > interface "bce1" { > min rx interval 20 ms; > min tx interval 50 ms; > idle tx interval 300 ms; > passive; > }; > neighbor 206.108.255.3; > neighbor 206.108.255.4; > neighbor 206.108.255.5; > neighbor 206.108.255.6; > neighbor 206.108.255.7; > neighbor 206.108.255.8; > .... > } Based on http://bird.network.cz/?get_doc&f=bird-6.html, I’d suggest something a bit less aggressive like 500ms x 3. I know a number of us here are using similar timer settings with good luck. idle tx would seem to not be required since it’s in passive mode (so it won’t send packets to a neighbor until it gets one first) protocol bfd { interface "bce1" { interval 500 ms; multiplier 3 passive; }; -- Andrew Hoyos hoyosa(a)gmail.com

Oct. 7, 2016

Re: BFD support on BGP sessions

by Doug McIntyre

On Fri, Oct 07, 2016 at 04:30:22PM -0500, James Stahr wrote: > For MICE though, it would be *great* if one of the route servers could be > setup with BFD support that way everyone could benefit and withdraw routes > faster once it was rolled out to both. It still wouldn't insure that A can > talk directly to B, only bilateral peering can solve that. BIRD appears to > have a "passive" setting for it too, so it wouldn't try to do BFD unless the > other side initiated. So, something like this? protocol bfd { interface "bce1" { min rx interval 20 ms; min tx interval 50 ms; idle tx interval 300 ms; passive; }; neighbor 206.108.255.3; neighbor 206.108.255.4; neighbor 206.108.255.5; neighbor 206.108.255.6; neighbor 206.108.255.7; neighbor 206.108.255.8; .... } And then likewise for the IPv6 daemon? -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Oct. 7, 2016

Re: BFD support on BGP sessions

by James Stahr

On 10/04/2016 8:35 PM, Michael Hare wrote: > Call it a Madison thing; AS 3128 would also like to BFD peer with interested parties. I like Andrew's "Y/N" column idea. > > -Michael > +1 on all counts.. For any of the folks also at MadIX, I'll do BFD with you there as well. Can we add BFD as a column on its' KB as well? For MICE though, it would be *great* if one of the route servers could be setup with BFD support that way everyone could benefit and withdraw routes faster once it was rolled out to both. It still wouldn't insure that A can talk directly to B, only bilateral peering can solve that. BIRD appears to have a "passive" setting for it too, so it wouldn't try to do BFD unless the other side initiated. -James > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Colin Baker > Sent: Tuesday, October 4, 2016 4:21 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] BFD support on BGP sessions > > On 04.10.2016 16:09, Andrew Hoyos wrote: > >> +1 to this. We (AS53597) will happy enable BFD to anyone that >> supports. Shoot us an email at noc(a)hoyosconsulting.com. >> >> Perhaps we can add a column to the participants page for a Y/N flag >> there? >> >> > Meee tooo > > Email peering(a)supranet.net (AS4150) and we'll be happy to get this > added. > >

Oct. 7, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Jeremy Lumby

As of 7:30AM, we are back to how we were yesterday afternoon. If you want to see the exact times I made the switch, both ports are graphed individually on http://micelg.usinternet.com/ on the last page of the copper switch graphs. I am not showing any loss to my USI customer since I made the switch back this morning (however I was prior to 7:30AM). From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Matthew Beckwell Sent: Wednesday, October 05, 2016 9:38 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G Participants Just to confirm...what port(s) are active right now for the new LAG at the moment? I'm currently getting >1% loss from the "new" 4200 (ge-0/0/15) over to USI on the 4500 (xe-0/0/14). I thought I ran the same test yesterday afternoon with no loss.. ~Matthew On Wed, Oct 5, 2016 at 7:40 AM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: For the time being, I am going to leave only the connection from the 4200 to the 4500 active since it has the most members, and therefore will show the least overall loss, while we determine our next step in troubleshooting this issue. To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Oct. 5, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Matthew Beckwell

Just to confirm...what port(s) are active right now for the new LAG at the moment? I'm currently getting >1% loss from the "new" 4200 (ge-0/0/15) over to USI on the 4500 (xe-0/0/14). I thought I ran the same test yesterday afternoon with no loss.. ~Matthew On Wed, Oct 5, 2016 at 7:40 AM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > For the time being, I am going to leave only the connection from the 4200 > to the 4500 active since it has the most members, and therefore will show > the least overall loss, while we determine our next step in troubleshooting > this issue. >

Oct. 5, 2016

Re: BFD support on BGP sessions

by Richard Laager

On 10/05/2016 07:17 AM, Colin Baker wrote: > Would have to be per session to be useful. I'm not aware of any IXPs > doing BFD on route servers - it's something worth discussing, and it may > be fine with fairly conservative timers, but I suspect members > interested in utilizing BFD will probably also want to set up bilateral > with those peers. I'm wondering if routers support configuring a BFD neighbor separately from a BGP neighbor and then using BFD for next-hop validation. I'm guessing not. So for those of you looking at using BFD, in addition to the bilateral peering, you'd need to filter the routes coming from the route servers and drop those of your BFD peers, right? Otherwise, when your session to the peer goes down, you'd still be hearing their routes from the route server. >> Colin, does Supranet support BFD for both AS4150 and AS5683, or just the >> former? > > 4150. You can actually remove 5683 from the website - it's not > currently connected and we likely won't be bringing it back. I've updated the website. The route servers will need to be updated too, and this frees up 206.108.255.28. -- Richard

Oct. 5, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Jeremy Lumby

Just to update everyone after yesterday's maintenance. After removing the 4200 from the virtual chassis, unfortunately I am still seeing loss when packets go between the 4500, and the 4550. The good news is removing the 4200 has improved it since the loss is now down to 0.06% on a 6 hour test (previously it was around 0.3%), unfortunately I am 100% sure it is real since I can shut down 1 of the two LAG ports at a time from the 4200, and the loss to the switch with the active lag port is always truly 0, and the other switch is 0.06% When I flip which port on the LAG is shutdown, then the loss flips to the other switch exactly as expected. For the time being, I am going to leave only the connection from the 4200 to the 4500 active since it has the most members, and therefore will show the least overall loss, while we determine our next step in troubleshooting this issue. Jeremy Lumby Minnesota VoIP 9217 17th Ave S Suite 216 Bloomington, MN 55425 Main: 612-355-7740 x211 Direct: 612-392-6814 EFax: 952-873-7425 jlumby(a)mnvoip.com

Oct. 5, 2016