Re: RIP Justification
On Thu, 30 Sep 2010 01:15:45 -0500 William McCall wrote: > On Wed, Sep 29, 2010 at 7:31 PM, Christopher Gatlin > wrote: > > Using BGP to exchange routes between these types of untrusted networks is > > like using a sledgehammer to crack a nut. BGP was designed for unique AS's > > to peer in large scale networks such as the internet. A far cry from > > business partners exchanging dynamic routes for fault tolerance. > > But on the flipside, arguing that we're providing this business parter > service with no sort of broadcast mechanism, does the complexity > actually increase between a proper implementation of BGP versus > properly implementing RIP for the same scenario? > > Consider this example: > 2 business partners terminating on the same device, we are advertising > 1 prefix to both and receiving 1 prefix from each. Each has redundant > connections to another router. > > Goals: > 1) Prevent BP A from advertising routes owned by BP B and vice-versa > 2) Advertise only the single prefix to the BPs > 3) No broadcast medium, so we'll need neighbor statements > 4) Prefix advertised to peers originates from IGP > > Mentally configuring this (in cisco terms), it seems about the same in > terms of config complexity. Filtering the prefixes from each of the > neighbors is required and the ACL to do this looks kind of nasty in > RIP. Also, you'll need to redistribute from the IGP and add either an > egress distribute list or a route map on the redistribution into RIP. > Finally, redistribute back into the IGP for the received prefixes. > > BGP gives a slightly nicer-looking policy with a route map for each of > the neighbors and policy building features that make scaling the > solution slightly easier since route-maps can be reused and attached > to the neighbor through whatever mechanism you want. And no > funky-looking ACLs to describe how to accept prefixes and no need to > redistribute from the IGP. Also, if choosing to run iBGP between > redundant nodes, its quite a bit more simplified to set metrics to > determine primary and redundant paths since this can be done on the > same ingress policy. > > > On Wed, Sep 29, 2010 at 10:19 PM, Chris Woodfield > wrote: > > (or, ghod forbid, multiple OSPF processes redistributing between each > > other...) > > > I think I have an anxiety disorder from this sort of "design".. > > On Wed, Sep 29, 2010 at 11:29 PM, Mark Smith > wrote: > > How do you prevent those business partners spoofing specific > > route announcements within the RIP update, intentionally or otherwise, > > such as a default route, causing either outages or attracting traffic > > towards their networks that shouldn't be? > > Ingress filtering for prefixes can be performed with RIP. It just > looks really funky compared to route maps for neighbors in BGP. > The best place to configure the prefix filtering would be on admission to the routing domain, rather than on exit. To achieve any sort of accurate route filtering in a RIP environment you'd have to maintain ingress route filters on all of the business partner routers. That'd be much harder to maintain accurately due to the number of business partner routers than a single per-business customer inbound route filter on a couple of BGP Route Reflectors/Servers. Those business customers may not trust you to operate their routers, so your routing accuracy is dependent on how well administered those business partner routers are maintained, which is likely to be very inconsistently. If you were operating the business peering exchange as a paid third party, and were providing SLAs for the service, then you wouldn't be in control of something that is essential to maintaining the quality and availability of the service. > > [...] I don't worry to much about the specific > > scenarios the tool was designed for - if the chosen tool provides the > > most appropriate and relevant benefits for an acceptable cost, > > the original design scenario doesn't matter. > > True that BGP is generally better in most external routing instances. > But there are other cost factors involved with doing BGP - fear and > knowledge. A lot of less experienced folk out there are outright > afraid of the concepts behind BGP and/or do not have the requisite > skills to maintain it. Then they're not the right people to be operating this network because they're not competent to. It sounds a bit like you're justifying people saying "I want to be paid to be an expert in this field, but I don't want to actually be an expert." I find this cop-out extremely irritating. You either know what you're doing or you don't, and if you don't, you shouldn't be selling yourself as somebody who does. > That shouldn't justify bad design decisions, > but it often does. Plus, it could be postulated that proper > implementation of RIP in the same scenario would be hindered by the > lack of knowledge still. > > Also, it should be pointed out that there are security products and > othe
Re: RIP Justification
> I think BGP is better for that job, ultimately because it was > specifically designed for that job, but also because it's now > available > in commodity routers for commodity prices e.g. Cisco 800 series. +1 - for me, if I need a dynamic routing protocol between trust / administrative domains, it's BGP unless there's a good reason not to. I find it more straightforward to work with (albeit slightly more up-front to configure it and get it right) than anything else - the information available is a very clear "who am I talking to?" / "what routes do I send them?" / "what routes do they send me?". Plus I can work through the route-selection process by hand from the information displayed, and have it make sense. Regards, Tim.
BGP next-hop
Hi all, Is there an easy way to see which iBGP routes are not being selected due to next-hop not being in IGP? Before and after IGP route added shown below, note both are marked as valid.. -- BEFORE IGP-- AS5000_LA#show ip bgp BGP table version is 5, local router ID is 10.0.0.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * i100.10.0.0/1610.0.0.100100 0 2000 3000 ? *> 10.0.0.6 0 1000 3000 3000 ? -- AFTER IGP-- AS5000_LA#show ip bgp BGP table version is 6, local router ID is 10.0.0.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path *>i100.10.0.0/1610.0.0.100100 0 2000 3000 ? * 10.0.0.6 0 1000 3000 3000 ? Cheers Heath ps. I've posted this to cisco-nsp also (a day ago) - so apologies in advance if you are on both and seeing it twice.
RE: BGP next-hop
Yes, I believe the command is "show ip bgp rib-failure". This shows routes that are in the BGP table, theoretically eligible to be used as actual traffic-forwarding routes, but are failing to be inserted into the Routing Information Base (RIB) for one reason or another. I don't have a lab router handy to lab it up, and of course on my normal production router it comes up empty (lists column headers, but no routes) because I don't have any edge cases on there right now. But I think this is what you want. -- Jeff Saxe Network Engineer, Blue Ridge InternetWorks Charlottesville, VA From: Heath Jones [hj1...@gmail.com] Sent: Thursday, September 30, 2010 5:49 AM To: nanog@nanog.org Subject: BGP next-hop Hi all, Is there an easy way to see which iBGP routes are not being selected due to next-hop not being in IGP? Before and after IGP route added shown below, note both are marked as valid.. -- BEFORE IGP-- AS5000_LA#show ip bgp BGP table version is 5, local router ID is 10.0.0.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * i100.10.0.0/1610.0.0.100100 0 2000 3000 ? *> 10.0.0.6 0 1000 3000 3000 ? -- AFTER IGP-- AS5000_LA#show ip bgp BGP table version is 6, local router ID is 10.0.0.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path *>i100.10.0.0/1610.0.0.100100 0 2000 3000 ? * 10.0.0.6 0 1000 3000 3000 ? Cheers Heath ps. I've posted this to cisco-nsp also (a day ago) - so apologies in advance if you are on both and seeing it twice.
Re: BGP next-hop
Cheers Jeff. I thought i'd give that a go, but it doesnt seem to be working for some reason! (This is without next-hop in IGP) AS5000_LA#show ip bgp BGP table version is 3, local router ID is 10.0.0.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path *> 100.10.0.0/1610.0.0.6 0 1000 3000 3000 ? * i 10.0.0.100100 0 2000 3000 ? AS5000_LA#show ip bgp rib-failure NetworkNext Hop RIB-failure RIB-NH Matches AS5000_LA# AS5000_LA#show ip bgp 100.10.0.0 BGP routing table entry for 100.10.0.0/16, version 3 Paths: (2 available, best #1, table Default-IP-Routing-Table) Flag: 0x820 Advertised to update-groups: 2 1000 3000 3000 10.0.0.6 from 10.0.0.6 (10.0.0.13) Origin incomplete, localpref 100, valid, external, best 2000 3000 10.0.0.10 (inaccessible) from 10.0.0.2 (10.0.0.9) Origin incomplete, metric 0, localpref 100, valid, internal >From the detail view, the route is marked as inaccessible. Perhaps this is the only way to get to it.. Heath
Re: RIP Justification
On 9/29/2010 3:20 PM, Jesse Loggins wrote: What are your views of when and where the RIP protocol is useful? Home networks when dual NAT isn't being used. It's also the perfect protocol for v6 on home networks where multiple home routers might be connected in a variety of ways. Shocked I didn't even see v6 mentioned in the thread (though you did clarify v2, which isn't the v6 implementation). :( Jack
Re: RIP Justification
On Sep 30, 2010, at 6:27 AM, Jack Bates wrote: > On 9/29/2010 3:20 PM, Jesse Loggins wrote: >> What are your views of when and >> where the RIP protocol is useful? > > Home networks when dual NAT isn't being used. It's also the perfect protocol > for v6 on home networks where multiple home routers might be connected in a > variety of ways. > I have no NAT whatsoever in my home network. RIP is not at all useful in my scenario. I have multiple routers in my home network. They use a combination of BGP and OSPFv3. > Shocked I didn't even see v6 mentioned in the thread (though you did clarify > v2, which isn't the v6 implementation). :( > If your network is of a scale where it exceeds the utility of static, then, it is almost certainly of a scale and topology where it exceeds the utility of RIP. Owen
Re: RIP Justification
One would assume you aren't doing this for nostalgic reasons. At least I would hope that! Like anything, if you decide to vary outside the 'accepted norms', then have a reason for it! Understand your technology, understand your topology (re: before about RIP not needing peered neighbors whereas OSPF does) and you may have your justification. If it's for nostalgia or "just because", then I'd say everyone agrees that RIP has passed its usefulness! Scott On 9/29/10 11:32 PM, Chris Woodfield wrote: > On Sep 29, 2010, at 6:14 PM, Scott Morris wrote: > >> But anything, ask why you are using it. To exchange routes, yes... but >> how many. Is sending those every 30 seconds good? Sure, tweak it. But >> are you gaining anything over static routes? > For simple networks, RIP(v2, mind you) works fine. You're correct that the > number of advertisements sent over the wire every 30 seconds won't scale, but > with today's routers and bandwidths it takes quite a lot to start to cause > issues. > > The real nail in RIP's coffin is that with most (if not all) routers out > there today, it's no more work to turn on and configure OSPF than it is to do > RIP, and OSPF will help you scale much better as you go without being too > complex for the simpler setups as well. As such, it really doesn't make sense > to go with RIP for mere nostalgia's sake. If you have a specific reason not > to run OSPF, fine, but those reasons are few and far between. > > -C >
Re: RIP Justification
On 9/30/10 12:57 AM, Mark Smith wrote: On Thu, 30 Sep 2010 14:13:11 +1000 Julien Goodwin [1] wrote: On 30/09/10 13:42, Mark Smith wrote: One of the large delays you see in OSPF is election of the designated router on multi-access links such as ethernets. As ethernet is being very commonly used for point-to-point non-edge links, you can eliminate that delay and also the corresponding network LSA by making OSPF treat the link as a point-to-point link e.g. int ethernet0 ip ospf network point-to-point If your implementation doesn't support point-to-point mode for an interface, point-to-multipoint mode on an ethernet would achieve something somewhat equivalent. Do any implementations go point-to-point automatically if an ethernet has a /30 or /31 mask? Don't know. Nope. Not Cisco anyway. NDC-R1-CustA(config)#int f0/0 NDC-R1-CustA(config-if)#ip addr 10.111.1.1 255.255.255.254 % Warning: use /31 mask on non point-to-point interface cautiously NDC-R1-CustA(config-if)# *Sep 30 15:18:22.710: %OSPF-5-ADJCHG: Process 1, Nbr 10.133.1.2 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached NDC-R1-CustA(config-if)# NDC-R1-CustA(config-if)#do sh ip o i f0/0 | i Type|Address Internet Address 10.111.1.1/31, Area 0 Process ID 1, Router ID 192.168.1.1, Network Type BROADCAST, Cost: 1 NDC-R1-CustA(config-if)# HTH, Scott On 9/30/10 12:57 AM, Mark Smith wrote: On Thu, 30 Sep 2010 14:13:11 +1000 Julien Goodwin [2] wrote: On 30/09/10 13:42, Mark Smith wrote: One of the large delays you see in OSPF is election of the designated router on multi-access links such as ethernets. As ethernet is being very commonly used for point-to-point non-edge links, you can eliminate that delay and also the corresponding network LSA by making OSPF treat the link as a point-to-point link e.g. int ethernet0 ip ospf network point-to-point If your implementation doesn't support point-to-point mode for an interface, point-to-multipoint mode on an ethernet would achieve something somewhat equivalent. Do any implementations go point-to-point automatically if an ethernet has a /30 or /31 mask? Don't know. If you want to see what interface model OSPF is using, on a Cisco you use show ip ospf interface The interface type for loopback interfaces can be a bit surprising and the consequences a bit unexpected if you're intentionally or otherwise not using a /32 prefix length on one. Regards, Mark. References 1. mailto:na...@studio442.com.au 2. mailto:na...@studio442.com.au
Re: RIP Justification
On 9/30/2010 8:46 AM, Owen DeLong wrote: I have no NAT whatsoever in my home network. RIP is not at all useful in my scenario. I have multiple routers in my home network. They use a combination of BGP and OSPFv3. Except you must configure those things. The average home user cannot. If your network is of a scale where it exceeds the utility of static, then, it is almost certainly of a scale and topology where it exceeds the utility of RIP. While it is possible for a router to create static routes automatically based on DHCPv6 assignment information, this has no loop prevention and is suboptimal depending on the configuration that things get plugged in. I'm not talking good network design here. I'm talking, buy box, plug in wherever it fits. Things should work. Jack
Re: BGP next-hop
In a message written on Thu, Sep 30, 2010 at 10:49:17AM +0100, Heath Jones wrote: > Is there an easy way to see which iBGP routes are not being selected > due to next-hop not being in IGP? I have suggested more than a few times to vendors that the command: show bgp ipv4 unicast 100.10.0.0/16 why-chosen Would be insanely useful. Yes, you can recreate the 7+ BGP decision steps in your mind by running a pile of show commands, but when you're trying to figure out several odd routes at the same time this is very hard to keep in your head and very labor intensive. The box knows why it chose the route, and should be able to show that to you. Of course most boxes can't show you outgoing BGP communities either. *sigh* Is it really too hard to ask to get a show bgp neighbor ... advertised that shows ALL of the attributes? -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpN5zeQJ0dwC.pgp Description: PGP signature
Re: RIP Justification
On Thu, Sep 30, 2010 at 3:38 AM, Mark Smith wrote: > On Thu, 30 Sep 2010 01:15:45 -0500 > William McCall wrote: > >> On Wed, Sep 29, 2010 at 7:31 PM, Christopher Gatlin >> wrote: >> > Using BGP to exchange routes between these types of untrusted networks is >> > like using a sledgehammer to crack a nut. BGP was designed for unique AS's >> > to peer in large scale networks such as the internet. A far cry from >> > business partners exchanging dynamic routes for fault tolerance. >> >> But on the flipside, arguing that we're providing this business parter >> service with no sort of broadcast mechanism, does the complexity >> actually increase between a proper implementation of BGP versus >> properly implementing RIP for the same scenario? >> >> Consider this example: >> 2 business partners terminating on the same device, we are advertising >> 1 prefix to both and receiving 1 prefix from each. Each has redundant >> connections to another router. >> >> Goals: >> 1) Prevent BP A from advertising routes owned by BP B and vice-versa >> 2) Advertise only the single prefix to the BPs >> 3) No broadcast medium, so we'll need neighbor statements >> 4) Prefix advertised to peers originates from IGP >> >> Mentally configuring this (in cisco terms), it seems about the same in >> terms of config complexity. Filtering the prefixes from each of the >> neighbors is required and the ACL to do this looks kind of nasty in >> RIP. Also, you'll need to redistribute from the IGP and add either an >> egress distribute list or a route map on the redistribution into RIP. >> Finally, redistribute back into the IGP for the received prefixes. >> >> BGP gives a slightly nicer-looking policy with a route map for each of >> the neighbors and policy building features that make scaling the >> solution slightly easier since route-maps can be reused and attached >> to the neighbor through whatever mechanism you want. And no >> funky-looking ACLs to describe how to accept prefixes and no need to >> redistribute from the IGP. Also, if choosing to run iBGP between >> redundant nodes, its quite a bit more simplified to set metrics to >> determine primary and redundant paths since this can be done on the >> same ingress policy. >> >> >> On Wed, Sep 29, 2010 at 10:19 PM, Chris Woodfield >> wrote: >> > (or, ghod forbid, multiple OSPF processes redistributing between each >> > other...) >> > >> I think I have an anxiety disorder from this sort of "design".. >> >> On Wed, Sep 29, 2010 at 11:29 PM, Mark Smith >> wrote: >> > How do you prevent those business partners spoofing specific >> > route announcements within the RIP update, intentionally or otherwise, >> > such as a default route, causing either outages or attracting traffic >> > towards their networks that shouldn't be? >> >> Ingress filtering for prefixes can be performed with RIP. It just >> looks really funky compared to route maps for neighbors in BGP. >> > > The best place to configure the prefix filtering would be on admission > to the routing domain, rather than on exit. To achieve any sort of > accurate route filtering in a RIP environment you'd have to maintain > ingress route filters on all of the business partner routers. That'd be > much harder to maintain accurately due to the number of business > partner routers than a single per-business customer inbound route filter > on a couple of BGP Route Reflectors/Servers. > > Those business customers may not trust you to operate their routers, so > your routing accuracy is dependent on how well administered those > business partner routers are maintained, which is likely to be very > inconsistently. If you were operating the business peering exchange as a > paid third party, and were providing SLAs for the service, then you > wouldn't be in control of something that is essential to maintaining > the quality and availability of the service. > Agreed, but rarely is this option presented. For this reason, the operator must still protect the network from other's misconfiguration, etc. >> > [...] I don't worry to much about the specific >> > scenarios the tool was designed for - if the chosen tool provides the >> > most appropriate and relevant benefits for an acceptable cost, >> > the original design scenario doesn't matter. >> >> True that BGP is generally better in most external routing instances. >> But there are other cost factors involved with doing BGP - fear and >> knowledge. A lot of less experienced folk out there are outright >> afraid of the concepts behind BGP and/or do not have the requisite >> skills to maintain it. > > Then they're not the right people to be operating this network because > they're not competent to. > > It sounds a bit like you're justifying people saying "I want to be paid > to be an expert in this field, but I don't want to actually be an > expert." I find this cop-out extremely irritating. You either know what > you're doing or you don't, and if you don't, you shouldn't be selling > yourself as som
Re: LISP Works - Re: Facebook Issues/Outage in Southeast?
Dear Cameron & everybody, On Wed, Sep 29, 2010 at 8:32 PM, Job W. J. Snijders wrote: >>> The fact that LISP does help in IPv6 Transition solutions (due to its >>> inherent AF agnostic design), is compelling. As you say, real end 2 end is >>> the goal - and LISP helps here, regardless of the AF. (you'll will still >>> want to do multi-homing in IPv6, and ingress TE, and mobility, etc.). Have you already joined the LISP Beta Network? All you need is a router that can run the LISP images (871, 1841, 2821, 7200 etc) It's completely open, and the guys behind lisp-supp...@external.cisco.com can hook you up for free, provide you with everything you need: beta image, a block of public ipv4/ipv6 space and configuration guides, although it's only about 10 lines of config. :-) You could use LISP at home, like I do, and get some hands on experience - enjoy the net behind LISP! http://lisp4.cisco.com/ provides more information. Kind regards, Job Snijders
Re: RIP Justification
On Wed, 29 Sep 2010 13:20:48 -0700 Jesse Loggins wrote: > OSPF. It seems that many Network Engineers consider RIP an old > antiquated protocol that should be thrown in back of a closet "never > to be seen or heard from again". Some even preferred using a more > complex protocol like OSPF instead of RIP. I am of the opinion that Complexity depending on your perspective. The implementation might be more complicated to code, but by and large the major implementations after years of experience seem to be very stable now. If the physical topology and stability is increasingly "interesting", RIP may be a more complex protocol to use and troubleshoot than OSPF. In essence, dealing with loops and topology changes in RIP involves a set of incomplete and unsatisfactory hacks for more than the simplest of environments. > every protocol has its place, which seems to be contrary to some > engineers way of thinking. This leads to my question. What are your > views of when and where the RIP protocol is useful? Please excuse me > if this is the incorrect forum for such questions. As an implementation of distance vector, its at least useful as a teaching tool about routing theory, history and implementations. John
Re: BGP next-hop
On Thu, 2010-09-30 at 07:01 -0700, Leo Bicknell wrote: > I have suggested more than a few times to vendors that the command: > > show bgp ipv4 unicast 100.10.0.0/16 why-chosen > > Would be insanely useful. +1 for that, in a similar manner to packet-tracer on ASAs. Peter
Re: RIP Justification
Dynamic routing is hard, let's go shopping. Seriously though, I can't think of a topology I've ever encountered where RIP would have made more sense than OSPF or BGP, or if you're really die-hard, IS-IS. Let it die... My $0.02, -Jack On Thu, Sep 30, 2010 at 11:53 AM, John Kristoff wrote: > On Wed, 29 Sep 2010 13:20:48 -0700 > Jesse Loggins wrote: > > > OSPF. It seems that many Network Engineers consider RIP an old > > antiquated protocol that should be thrown in back of a closet "never > > to be seen or heard from again". Some even preferred using a more > > complex protocol like OSPF instead of RIP. I am of the opinion that > > Complexity depending on your perspective. The implementation might be > more complicated to code, but by and large the major implementations > after years of experience seem to be very stable now. If the physical > topology and stability is increasingly "interesting", RIP may be a more > complex protocol to use and troubleshoot than OSPF. In essence, > dealing with loops and topology changes in RIP involves a set of > incomplete and unsatisfactory hacks for more than the simplest of > environments. > > > every protocol has its place, which seems to be contrary to some > > engineers way of thinking. This leads to my question. What are your > > views of when and where the RIP protocol is useful? Please excuse me > > if this is the incorrect forum for such questions. > > As an implementation of distance vector, its at least useful as a teaching > tool about routing theory, history and implementations. > > John > >
Re: OSPFv3 Authentication
Hi, I received 12 responses for the query that i had put up. o 1 response stated that the provider was using IS-IS for IPv6 and not using any authentication. o 7 responses where OSPFv3 was being used without any authentication. o 2 responses where OSPFv3 is being used with authentication o 2 responses where they were using OSPFv2 with authentication turned on. I asked the 7 people who had replied in negative about why they were not using authentication with OSPFv3. 5 responded stating a mix of the following reasons: o IPsec not available on all platforms o IPsec required interoperability testing, which was perceived as a hassle o Troubleshooting becomes much harder. OSPF operation should be kept as simple as possible, especially when used in the core. o Complex configuration o Required coordination between different boxes which is a deterrent. o IPSec on some platforms requires a special license which can be expensive. o Unsure of how well is the IPsec implemented on the boxes Cheers, Manav On Tue, Sep 28, 2010 at 5:33 AM, Manav Bhatia wrote: > Hi, > > I am doing a survey and was interested in knowing if network operators > are using OSPFv3 with authentication [RFC 4552] turned on? I know that > most providers turn on authentication with OSPFv2, but given that > OSPFv3 needs IPsec integration and can thus get little cumbersome to > configure, wanted to understand if a similar % of folks also turn on > authentication for OSPFv3? > > You can unicast me your responses (if you dont wish to share it on the > list) and i will collate all data and post a summary on the list. > > Cheers, Manav >
Re: RIP Justification
RIP cannot also be used for traffic engineering; so if you want MPLS then you MUST use either OSPF or ISIS. RIP, like any other distance vector protocol, converges extremely slowly - so if you want faster convergence then you have to use one of ISIS or OSPF. Glen
RE: RIP Justification
> -Original Message- > From: Jack Carrozzo > Sent: Thursday, September 30, 2010 9:44 AM > To: John Kristoff > Cc: nanog@nanog.org > Subject: Re: RIP Justification > > Dynamic routing is hard, let's go shopping. > > Seriously though, I can't think of a topology I've ever encountered > where > RIP would have made more sense than OSPF or BGP, or if you're really > die-hard, IS-IS. Let it die... > > My $0.02, > > -Jack The one and only place I have used RIPv2 and RIPng is for distributing igp information on links between BGP routers. Say I have a cluster of such routers with some /30 links (for IPv4) to transit, peers and each other. Basically I run RIP with "redistribute connected" on them and only running on the internal interfaces connecting the routers. All RIP is doing at that point is providing an igp path to the BGP next hop. There is really no need to run OSPF for that and frankly I don't WANT OSPF running there for other reasons.
L3 Issues this Morning?
Hello All, This is my first time writing to this list and wanted to check if anyone experienced issues with L3 circuits between 12:50 ET and 13:05 ET. All our core backbone circuits re-converged and we saw a significant drop in traffic. Regards, Khurram
Re: L3 Issues this Morning?
Learn something new everyday, that's awesome. We've got several data centers between San Diego, Denver, Tulsa, Chicago, Washington DC. All of the circuit's between those POP's , and all are L3, just dropped traffic. On Thu, Sep 30, 2010 at 11:35 AM, James Smith wrote: > None Down here in Canada > > Sent from my iPhone > > On Sep 30, 2010, at 2:32 PM, Khurram Khan wrote: > >> Hello All, >> >> This is my first time writing to this list and wanted to check if >> anyone experienced issues with L3 circuits between 12:50 ET and 13:05 >> ET. All our core backbone circuits re-converged and we saw a >> significant drop in traffic. >> >> Regards, >> >> Khurram >> > -- Please use the following public key for encrypted transport. —–BEGIN PGP SIGNATURE—– Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGZO+K6ECuipL6LVERAjSvAJsFslrQU61la+yCqD2bfDSW/OGKigCg0QOK LQTWZQDmFma6eh7onZfi99A= =LlU0 —–END PGP SIGNATURE—–
Cogent security contact for non-BGP issue?
Can someone from Cogent responsible for security contact me? I'm seeing some troubles that appear to originate within Cogent itself. What I am seeing does not effect global BGP at all, it's some other area. Thanks in advance ...
Re: LISP Works - Re: Facebook Issues/Outage in Southeast?
Sorry guys, > Have you already joined the LISP Beta Network? All you need is a > router that can run the LISP images (871, 1841, 2821, 7200 etc) > > It's completely open, and the guys behind > lisp-supp...@external.cisco.com can hook you up for free, The correct address is lisp-supp...@cisco.com Kind regards, Job
Re: RIP Justification
On Sep 30, 2010, at 12:43 PM, Jack Carrozzo wrote: > Dynamic routing is hard, let's go shopping. > > Seriously though, I can't think of a topology I've ever encountered where > RIP would have made more sense than OSPF or BGP, or if you're really > die-hard, IS-IS. Let it die... But what about all of those students even now working on getting their Lab RIP routing to work ? Surely such a huge crowd-sourcing will solve any remaining problems with the protocol by the end of the term! Regards Marshall > > My $0.02, > > -Jack > > On Thu, Sep 30, 2010 at 11:53 AM, John Kristoff wrote: > >> On Wed, 29 Sep 2010 13:20:48 -0700 >> Jesse Loggins wrote: >> >>> OSPF. It seems that many Network Engineers consider RIP an old >>> antiquated protocol that should be thrown in back of a closet "never >>> to be seen or heard from again". Some even preferred using a more >>> complex protocol like OSPF instead of RIP. I am of the opinion that >> >> Complexity depending on your perspective. The implementation might be >> more complicated to code, but by and large the major implementations >> after years of experience seem to be very stable now. If the physical >> topology and stability is increasingly "interesting", RIP may be a more >> complex protocol to use and troubleshoot than OSPF. In essence, >> dealing with loops and topology changes in RIP involves a set of >> incomplete and unsatisfactory hacks for more than the simplest of >> environments. >> >>> every protocol has its place, which seems to be contrary to some >>> engineers way of thinking. This leads to my question. What are your >>> views of when and where the RIP protocol is useful? Please excuse me >>> if this is the incorrect forum for such questions. >> >> As an implementation of distance vector, its at least useful as a teaching >> tool about routing theory, history and implementations. >> >> John >> >> >
Re: RIP Justification
Yes, clearly the next crowd of CCNAs will save the world. You know what they say about giving CCNAs enable... -Jack On Thu, Sep 30, 2010 at 2:37 PM, Marshall Eubanks wrote: > > On Sep 30, 2010, at 12:43 PM, Jack Carrozzo wrote: > > > Dynamic routing is hard, let's go shopping. > > > > Seriously though, I can't think of a topology I've ever encountered where > > RIP would have made more sense than OSPF or BGP, or if you're really > > die-hard, IS-IS. Let it die... > > But what about all of those students even now working on getting their Lab > RIP routing to work ? > Surely such a huge crowd-sourcing will solve any remaining problems with > the protocol by the end of the term! > > Regards > Marshall > > > > > My $0.02, > > > > -Jack > > > > On Thu, Sep 30, 2010 at 11:53 AM, John Kristoff wrote: > > > >> On Wed, 29 Sep 2010 13:20:48 -0700 > >> Jesse Loggins wrote: > >> > >>> OSPF. It seems that many Network Engineers consider RIP an old > >>> antiquated protocol that should be thrown in back of a closet "never > >>> to be seen or heard from again". Some even preferred using a more > >>> complex protocol like OSPF instead of RIP. I am of the opinion that > >> > >> Complexity depending on your perspective. The implementation might be > >> more complicated to code, but by and large the major implementations > >> after years of experience seem to be very stable now. If the physical > >> topology and stability is increasingly "interesting", RIP may be a more > >> complex protocol to use and troubleshoot than OSPF. In essence, > >> dealing with loops and topology changes in RIP involves a set of > >> incomplete and unsatisfactory hacks for more than the simplest of > >> environments. > >> > >>> every protocol has its place, which seems to be contrary to some > >>> engineers way of thinking. This leads to my question. What are your > >>> views of when and where the RIP protocol is useful? Please excuse me > >>> if this is the incorrect forum for such questions. > >> > >> As an implementation of distance vector, its at least useful as a > teaching > >> tool about routing theory, history and implementations. > >> > >> John > >> > >> > > > >
Re: L3 Issues this Morning?
Not sure if this is related but my Level 3 BGP peer went down at 3:33:57 GMT for just over 6 hours. This was in the San Jose/Santa Clara area. Their reason was an OSPF problem. Zaid On 9/30/10 10:39 AM, "Khurram Khan" wrote: > Learn something new everyday, that's awesome. We've got several data > centers between San Diego, Denver, Tulsa, Chicago, Washington DC. All > of the circuit's between those POP's , and all are L3, just dropped > traffic. > > On Thu, Sep 30, 2010 at 11:35 AM, James Smith > wrote: >> None Down here in Canada >> >> Sent from my iPhone >> >> On Sep 30, 2010, at 2:32 PM, Khurram Khan wrote: >> >>> Hello All, >>> >>> This is my first time writing to this list and wanted to check if >>> anyone experienced issues with L3 circuits between 12:50 ET and 13:05 >>> ET. All our core backbone circuits re-converged and we saw a >>> significant drop in traffic. >>> >>> Regards, >>> >>> Khurram >>> >> > >
Frontier DSL Contact
Can someone from Frontier DSL (formally Verizon) please contact me off list? It appears Frontier DSL customers (at least in Ohio) can't access websites that we host. I have tried contacting the ISIS NOC, the Ohio NOC and the MCO and they were unable to assist. Or if there is anyone on the list using Frontier DSL if they could send me a traceroute to 208.2.209.110 and/or 208.2.213.96 that might also help me track down the issue. Thanks, Tony -- Tony Bunce: to...@go-concepts.com Sr. Programming Systems Administrator - GO Concepts Inc.
RE: RIP Justification
> Seriously though, I can't think of a topology I've ever encountered where RIP > would have made more sense than OSPF or BGP, or if you're really die-hard, > IS-IS. Let it die... I was just curious - why would IS-IS be more die-hard than OSPF or iBGP? Best Regards, Nathan Eisenberg
Re: RIP Justification
> > I was just curious - why would IS-IS be more die-hard than OSPF or iBGP? > It's like running apps on Solaris and Oracle these days instead of Linux and MySQL. Both options work if you know what you're doing, but it's way easier (and cheaper) to hire admins for the latter. When was the last time you ran into a younger neteng designing his topology who went "Yes! IS-IS!"? It works fine (very well in fact) but it's just less used. I know there are a lot of guys on here using IS-IS and I'm certainly not knocking it... -Jack
Re: RIP Justification
Maybe I WAY under-read the initial poster's question, but I was pretty sure he wasn't talking about running it as a CORE routing protocol or anything on the middle of their network where MPLS would be expected on top of it! If I missed it and he did intend that, then I'd certainly agree with you (among many other reasons why it would be a horrible idea)! ;) Scott On 9/30/10 12:59 PM, Glen Kent wrote: > RIP cannot also be used for traffic engineering; so if you want MPLS > then you MUST use either OSPF or ISIS. RIP, like any other distance > vector protocol, converges extremely slowly - so if you want faster > convergence then you have to use one of ISIS or OSPF. > > Glen > > >
AT&T Dry Pairs?
Has anyone had any luck lately getting dry pairs from AT&T? I'm in the Chicago area attempting to get a dry pair between two buildings (100ft apart) for some equipment, but when speaking to several folks at AT&T the response I get is "You want AT&T service without the service? That's not logical!". Had no problems 3-4 years ago getting these sorts of "circuits", but it appears it's gone the way of the dodo now. Any emails off-list are appreciated. -- Brandon Galbraith US Voice: 630.492.0464
Re: RIP Justification
On 9/30/2010 3:32 PM, Jack Carrozzo wrote: When was the last time you ran into a younger neteng designing his topology who went "Yes! IS-IS!"? It works fine (very well in fact) but it's just less used. Which makes no sense to me. I originally looked at both and thought OSPF to be inferior to IS-IS. That being said, OSPF is supported on more (and cheaper) hardware. IS-IS can have additional licensing with some hardware (where OSPF does not) and is often considered a "service provider" protocol by vendors. Jack
Re: RIP Justification
As it was explained to me, the main difference is that you can have $lots of prefixes in IS-IS without it falling over, whereas Dijkstra is far more resource-intensive and as such OSPF doesn't get too happy after $a_lot_less prefixes. Those numbers can be debated as you like, but I think if you were to redist bgp ospf on a lab machine you'd get the point. Disclaimer: I've never run IS-IS operationally, just in the lab. -Jack > Which makes no sense to me. I originally looked at both and thought OSPF to > be inferior to IS-IS. That being said, OSPF is supported on more (and > cheaper) hardware. IS-IS can have additional licensing with some hardware > (where OSPF does not) and is often considered a "service provider" protocol > by vendors. > > > Jack >
Re: AT&T Dry Pairs?
Years ago I managed to get a dry pair from Verizon for some homebrew DSL, but there was some telco specific term for the dry pair, like "series 7 alarm circuit" or something. AT&T may have their own term. -Ryan On Thu, Sep 30, 2010 at 4:52 PM, Brandon Galbraith < brandon.galbra...@gmail.com> wrote: > Has anyone had any luck lately getting dry pairs from AT&T? I'm in the > Chicago area attempting to get a dry pair between two buildings (100ft > apart) for some equipment, but when speaking to several folks at AT&T the > response I get is "You want AT&T service without the service? That's not > logical!". Had no problems 3-4 years ago getting these sorts of "circuits", > but it appears it's gone the way of the dodo now. Any emails off-list are > appreciated. > > -- > Brandon Galbraith > US Voice: 630.492.0464 >
RE: AT&T Dry Pairs?
> -Original Message- > From: Ryan Shea > Sent: Thursday, September 30, 2010 2:21 PM > To: Brandon Galbraith > Cc: nanog@nanog.org > Subject: Re: AT&T Dry Pairs? > > Years ago I managed to get a dry pair from Verizon for some homebrew > DSL, > but there was some telco specific term for the dry pair, like "series 7 > alarm circuit" or something. AT&T may have their own term. > > -Ryan > Just plain "alarm circuit" works in most cases but it has been a while here as well.
Re: BGP next-hop
i was recently bitten by a cousin of this research router getting an ebgp multi-hop full feed from 147.28.0.1 (address is relevant) it is on a lan with a default gateway 42.666.77.11 (address not relevant), so it has ip route 0.0.0.0 0.0.0.0 42.666.77.11 massive flapping results. it seems it gets the bgp route for 147.28.0.0/16 and then can not resolve the next hop. it would not recurse to the default exit. of course it was solved by ip route 147.28.0.0 255.255.0.0 42.666.77.11 but i do not really understand in my heart why i needed to do this. randy
Re: BGP next-hop
Because the path was broken everytime the bgp session was established and rewriting the routing table with more specific routes? - Original Message - From: "Randy Bush" To: "North American Network Operators Group" Sent: Thursday, 30 September, 2010 2:37:43 PM Subject: Re: BGP next-hop i was recently bitten by a cousin of this research router getting an ebgp multi-hop full feed from 147.28.0.1 (address is relevant) it is on a lan with a default gateway 42.666.77.11 (address not relevant), so it has ip route 0.0.0.0 0.0.0.0 42.666.77.11 massive flapping results. it seems it gets the bgp route for 147.28.0.0/16 and then can not resolve the next hop. it would not recurse to the default exit. of course it was solved by ip route 147.28.0.0 255.255.0.0 42.666.77.11 but i do not really understand in my heart why i needed to do this. randy
Re: BGP next-hop
i was recently bitten by a cousin of this research router getting an ebgp multi-hop full feed from 147.28.0.1 (address is relevant) it is on a lan with a default gateway 42.666.77.11 (address not relevant), so it has ip route 0.0.0.0 0.0.0.0 42.666.77.11 massive flapping results. it seems it gets the bgp route for 147.28.0.0/16 and then can not resolve the next hop. it would not recurse to the default exit. of course it was solved by ip route 147.28.0.0 255.255.0.0 42.666.77.11 but i do not really understand in my heart why i needed to do this. last time severall years ago on cisco I used a route-map to rewrite the next-hop. route-map xx-in permit 10 set ip next-hop 42.666.77.11 route-map xx-out permit 10 set ip next-hop x.x.x.x neighbor 147.28.0.1 remote-as yyy neighbor 147.28.0.1 ebgp-multihop 8 neighbor 147.28.0.1 route-map xx-in in neighbor 147.28.0.1 route-map xx-out out something like this.
Re: AT&T Dry Pairs?
If your sales contact don't know what an alarm circuit is, go find AT&T's tariff filed with your state's PUC. It will contain the name of the service. This will take some digging... Verizon Maryland calls this an "Intraexchange local channel, regular voice grade" and they go for $15.53/month. There are a plethora of different types of "dry pairs" that you can order depending on the signal bandwidth of the circuit and allowed attenuation. On Thu, Sep 30, 2010 at 4:52 PM, Brandon Galbraith < brandon.galbra...@gmail.com> wrote: > Has anyone had any luck lately getting dry pairs from AT&T? I'm in the > Chicago area attempting to get a dry pair between two buildings (100ft > apart) for some equipment, but when speaking to several folks at AT&T the > response I get is "You want AT&T service without the service? That's not > logical!". Had no problems 3-4 years ago getting these sorts of "circuits", > but it appears it's gone the way of the dodo now. Any emails off-list are > appreciated. > > -- > Brandon Galbraith > US Voice: 630.492.0464 >
Re: AT&T Dry Pairs?
If the buildings are a 100ft apart, can't you just go with a wireless connection? Speeds would probably be better and no monthly fee! On 09/30/2010 06:08 PM, Robert Johnson wrote: If your sales contact don't know what an alarm circuit is, go find AT&T's tariff filed with your state's PUC. It will contain the name of the service. This will take some digging... Verizon Maryland calls this an "Intraexchange local channel, regular voice grade" and they go for $15.53/month. There are a plethora of different types of "dry pairs" that you can order depending on the signal bandwidth of the circuit and allowed attenuation. On Thu, Sep 30, 2010 at 4:52 PM, Brandon Galbraith< brandon.galbra...@gmail.com> wrote: Has anyone had any luck lately getting dry pairs from AT&T? I'm in the Chicago area attempting to get a dry pair between two buildings (100ft apart) for some equipment, but when speaking to several folks at AT&T the response I get is "You want AT&T service without the service? That's not logical!". Had no problems 3-4 years ago getting these sorts of "circuits", but it appears it's gone the way of the dodo now. Any emails off-list are appreciated. -- Brandon Galbraith US Voice: 630.492.0464
Re: BGP next-hop
> last time severall years ago on cisco I used a route-map to rewrite the > next-hop. > route-map xx-in permit 10 > set ip next-hop 42.666.77.11 > route-map xx-out permit 10 > set ip next-hop x.x.x.x > > neighbor 147.28.0.1 remote-as yyy > neighbor 147.28.0.1 ebgp-multihop 8 > neighbor 147.28.0.1 route-map xx-in in > neighbor 147.28.0.1 route-map xx-out out > > something like this. as i showed, i knew how to hack out of the problem. and yes, there are many ways. the question is why i am in the corner in the first place. randy
Re: AT&T Dry Pairs?
On 9/30/2010 15:12, Bret Clark wrote: > If the buildings are a 100ft apart, can't you just go with a wireless > connection? Speeds would probably be better and no monthly fee! > Wireless is not the end all solution for everything. ~Seth
Re: AT&T Dry Pairs?
On Sep 30, 2010, at 6:30 PM, Seth Mattinen wrote: > On 9/30/2010 15:12, Bret Clark wrote: >> If the buildings are a 100ft apart, can't you just go with a wireless >> connection? Speeds would probably be better and no monthly fee! >> > > Wireless is not the end all solution for everything. Understood, but for $160 you can get equipment that acts as a L2 bridge with RJ45 and PoE at 50Mb/s duplex. (UBNT Nanobridge 5, they're $79 per and do 5Ghz 802.11n MCS-15 @ 40Mhz channels). Just trying to help :) You may now shoot the off-topic messenger. - Jared
Re: AT&T Dry Pairs?
On Thu, 30 Sep 2010 17:20:52 -0400, Ryan Shea wrote: AT&T may have their own term. The industry standard term is "UNE" (unbundled network element.) However, the sales drones may not recognize that either. --Ricky
Re: BGP next-hop
On Thu, Sep 30, 2010 at 07:01:19AM -0700, Leo Bicknell wrote: > I have suggested more than a few times to vendors that the command: > > show bgp ipv4 unicast 100.10.0.0/16 why-chosen > > Would be insanely useful. Been in JUNOS "show route" since day one, and IMHO is easily in the top 10 list of why I still buy Juniper instead of Cisco despite all the $%^&*ing bugs these days. -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: AT&T Dry Pairs?
On 9/30/2010 15:34, Jared Mauch wrote: > > On Sep 30, 2010, at 6:30 PM, Seth Mattinen wrote: > >> On 9/30/2010 15:12, Bret Clark wrote: >>> If the buildings are a 100ft apart, can't you just go with a wireless >>> connection? Speeds would probably be better and no monthly fee! >>> >> >> Wireless is not the end all solution for everything. > > Understood, but for $160 you can get equipment that acts as a L2 bridge with > RJ45 and PoE at 50Mb/s duplex. (UBNT Nanobridge 5, they're $79 per and do > 5Ghz 802.11n MCS-15 @ 40Mhz channels). > > Just trying to help :) > The biggest laugh I always got when I worked at the local university as a student were trouble tickets to the Faraday cage rooms because the campus wireless internet didn't work inside them. "But it's wireless!" "Yes, that's the problem. Please just use the damn cable." ~Seth
Re: RIP Justification
On 30 September 2010 22:11, Jack Carrozzo wrote: > As it was explained to me, the main difference is that you can have $lots of > prefixes in IS-IS without it falling over, whereas Dijkstra is far more > resource-intensive and as such OSPF doesn't get too happy after $a_lot_less > prefixes. Those numbers can be debated as you like, but I think if you were > to redist bgp ospf on a lab machine you'd get the point. Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because of the ISO addressing. Atleast thats my take on it.. RIPv2 is great for simple route injection. I'm talking really simple, just to avoid statics.
Re: RIP Justification
> Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because > of the ISO addressing. Atleast thats my take on it.. Sorry, my mistake. I'll go sit in my corner now... -Jack
Re: BGP next-hop
>> show bgp ipv4 unicast 100.10.0.0/16 why-chosen >> Would be insanely useful. > Been in JUNOS "show route" since day one, and IMHO is easily in the top > 10 list of why I still buy Juniper instead of Cisco despite all the > $%^&*ing bugs these days. Its interesting, I was heavy into cisco years back and then juniper for a while. Going back to cisco now is great (always good for me to keep my exposure up), but there is just so much unclear in it's CLI. It wasn't until going back that I realised. I guess they would have to balance keeping the old timers & scripts etc happy VS bringing in new features that make the output look different.. Do you keep something that isn't perfect but people know how to use, or change it and cause more issues than good? ps. Juniper has really gone to $h!t lately. There's a website called glassdoor.com that I found - go look up what employees have to say about it.. reflects exactly the support we were getting, even as as an 'elite' partner..
Re: RIP Justification
Haha It's all good :) You are right about IS-IS being less resource intensive than OSPF, and that it scales better! On 30 September 2010 23:50, Jack Carrozzo wrote: > >> >> Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because >> of the ISO addressing. Atleast thats my take on it.. > > Sorry, my mistake. I'll go sit in my corner now... > -Jack
Re: BGP next-hop
On Thu, Sep 30, 2010 at 11:56:06PM +0100, Heath Jones wrote: > > Its interesting, I was heavy into cisco years back and then juniper > for a while. Going back to cisco now is great (always good for me to > keep my exposure up), but there is just so much unclear in it's CLI. > It wasn't until going back that I realised. > > I guess they would have to balance keeping the old timers & scripts > etc happy VS bringing in new features that make the output look > different.. Do you keep something that isn't perfect but people know > how to use, or change it and cause more issues than good? Personally I still can't believe that it's the year 2010, and IOS still shows routes in classful notation (i.e. if it's in 192.0.0.0/3 and is a /24, the /24 part isn't displayed because it's assumed to be "Class C"). Of course I say that every year, and so far the only thing that has changed is the year I say it about. > ps. Juniper has really gone to $h!t lately. There's a website called > glassdoor.com that I found - go look up what employees have to say > about it.. reflects exactly the support we were getting, even as as an > 'elite' partner.. Don't get me started, I could complain for days and still not run out of material, but alas it doesn't accomplish anything. Sadly, many of the best Juniper people I know are incredibly disaffected, and are leaving (or have already left) in droves. I think the way I heard it put best was, "I'm convinced that $somenewexecfromcisco is actually on a secret 5 year mission to come over to Juniper, completely $%^* the company, and then go back to Cisco and get a big bonus for it". :) -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: BGP next-hop
> it seems it gets the bgp route for 147.28.0.0/16 and then can not > resolve the next hop. it would not recurse to the default exit. > > of course it was solved by > ip route 147.28.0.0 255.255.0.0 42.666.77.11 > but i do not really understand in my heart why i needed to do this. Neither do I, Randy. I have seen recursive routing done - perhaps on a juniper - i really cannot remember. Given that the packet would be originating from the device itself (not hardware forwarded), it would make sense that it should be able to perform a recursive lookup. I'd put it down to an implementation thing.. Unrelated, I was doing some thinking about a multihomed site and using BGP advertisments sent out one link (provider 1) to influence the sending of the advertisments out of the other link (provider 2). Long story short I needed to know how long bgp nlri's take to traverse the net, and subsequently have a paper that you co-authored open in another tab - well done! :)
Re: BGP next-hop
>> it seems it gets the bgp route for 147.28.0.0/16 and then can not >> resolve the next hop. it would not recurse to the default exit. >> >> of course it was solved by >> ip route 147.28.0.0 255.255.0.0 42.666.77.11 >> but i do not really understand in my heart why i needed to do this. > > Neither do I, Randy. a good friend at cisco says he will take the time to write up why in the next day or two. > I needed to know how long bgp nlri's take to traverse the net high variance randy
Re: BGP next-hop
On Sep 30, 2010, at 4:57 PM, Randy Bush wrote: >>> it seems it gets the bgp route for 147.28.0.0/16 and then can not >>> resolve the next hop. it would not recurse to the default exit. >>> >>> of course it was solved by >>>ip route 147.28.0.0 255.255.0.0 42.666.77.11 >>> but i do not really understand in my heart why i needed to do this. >> >> Neither do I, Randy. > > a good friend at cisco says he will take the time to write up why in the > next day or two. Only thing I can guess from the Cisco doc that says: "To prevent the creation of loops through oscillating routes, the multihop will not be established if the only route to the multihop peer is the default route (0.0.0.0)." Is that they think they're saving you from shooting yourself in the foot, if you learn the route to 147.28.0.0/16 via BGP (which your multihop peer address falls in), yet you have a default route of 0.0.0.0? But then you'd simply recursively look up the FIB route to the next hop in BGP... so I still don't get it. -b
Re: BGP next-hop
On Sep 30, 2010, at 5:37 PM, Randy Bush wrote: > i was recently bitten by a cousin of this > > research router getting an ebgp multi-hop full feed from 147.28.0.1 > (address is relevant) > > it is on a lan with a default gateway 42.666.77.11 (address not > relevant), so it has > >ip route 0.0.0.0 0.0.0.0 42.666.77.11 > > massive flapping results. > > it seems it gets the bgp route for 147.28.0.0/16 and then can not > resolve the next hop. it would not recurse to the default exit. > > of course it was solved by > >ip route 147.28.0.0 255.255.0.0 42.666.77.11 > > but i do not really understand in my heart why i needed to do this. > Looks like a classic race condition, in that 147.28/16, upon arrival, becomes a better route for the recursed next-hop (which really is a recursed lookup on your default) So you get 147.28/16 -> 147.28.0.1, and then 147.28.0.1 looks best through the learned route. Of course, this would appear to be a matter of how it is implemented. Because in fact, the 147 route isn't yet in the routing table, so your default should apply. The static seems to force a recursion to the 666 nh. I'll wait for your friend to send the implementation details, but from a glance, it looks like a defensive (lazy?) attempt to avoid a recursion loop during the update receive process. Btw, this will happen on a Juniper (or at least it used to). I'll have to check to confirm. Chris > randy >
Re: RIP Justification
I am with Scott on this one.. I took the initial question as a focus on the edge... not the CORE. RIP is perfect for the edge to commercial CPEs. Why would want to run OSPF/ISIS at the edge. I would hope that it would be common practice to not use RIP in the CORE peace -- Ruben Guerra - Sent from my Nokia N900 - Original message - > Haha It's all good :) > You are right about IS-IS being less resource intensive than OSPF, and > that it scales better! > > > > On 30 September 2010 23:50, Jack Carrozzo > mailto:j...@crepinc.com>> wrote: > > > > > > > > Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because > > > of the ISO addressing. Atleast thats my take on it.. > > > > Sorry, my mistake. I'll go sit in my corner now... > > -Jack >
Re: BGP next-hop
On Sep 30, 2010, at 3:37 PM, Randy Bush wrote: > it seems it gets the bgp route for 147.28.0.0/16 and then can not > resolve the next hop. it would not recurse to the default exit. > > of course it was solved by > >ip route 147.28.0.0 255.255.0.0 42.666.77.11 > > but i do not really understand in my heart why i needed to do this. Section 9.1.2.1 of RFC 4271 seems to address this. A few points from that section: - The BGP NEXT_HOP can not recursively resolve (directly or indirectly) through the BGP route. - Only the longest matching route should be considered when resolving the BGP NEXT_HOP. - Do not consider feasible routes that would become unresolvable if they were installed. --Stacy
Using crypto auth for detecting corrupted IGP packets?
Hi, I believe, based on what i have heard, that some operators turn on cryptographic authentication because the internet checksum that OSPF, etc use for packet sanity is quite weak and offers trifle little protection against lot of known errors like: - re-ordering of 2-byte aligned words - various bit flips that keep the 1s complement sum the same (e.g. 0x to 0x and vice versa) So a corrupted packet could still pass the ethernet CRC checks and IP and OSPF checksums. Or it could be valid till the ethernet CRC check is done and gets corrupted after that (PCI transmission errors, DMA errors, memory issues, line card corruption and last but not the least, CRCs and internet checksums could miss wire-corrupted packets) Currently an operator can do the following: - Use the poor internet checksum OR - Turn on cryptographic authentication in the routing protocols to catch all such bit errors which could be caused by line card corruption, etc. One can go through http://portal.acm.org/citation.cfm?id=294357.294364 to understand the issues with the internet checksums. I would be interested in knowing if operators use the cryptographic authentication for detecting the errors that i just described above. You could send me a mail offline and i will consolidate the responses and send a summary on the list in a few days time. Cheers, Manav
Re: Using crypto auth for detecting corrupted IGP packets?
On Thu, Sep 30, 2010 at 11:34 PM, Manav Bhatia wrote: > I would be interested in knowing if operators use the cryptographic > authentication for detecting the errors that i just described above. yes.
Re: Using crypto auth for detecting corrupted IGP packets?
On Sep 30, 2010, at 11:34 PM, Manav Bhatia wrote: > > I would be interested in knowing if operators use the cryptographic > authentication for detecting the errors that i just described above. Additionally, one might venture to understand the effects of such mechanisms and why knob's such as IS-IS's "ignore-lsp-errors" were added ~15 years ago. LSP corruption storms driven by receivers that purge corrupted LSPs and originators that re-originate and flood on receipt of said purged LSPs are very problematic and otherwise difficult to identify in practice. Coincidentally, it's also why logging LSPs that trigger such errors is important, whether you ignore them or propagate them. -danny
Re: Using crypto auth for detecting corrupted IGP packets?
Sent from my iThing On Oct 1, 2010, at 12:16 AM, Danny McPherson wrote: > > On Sep 30, 2010, at 11:34 PM, Manav Bhatia wrote: >> >> I would be interested in knowing if operators use the cryptographic >> authentication for detecting the errors that i just described above. > > Additionally, one might venture to understand the effects of such mechanisms > and > why knob's such as IS-IS's "ignore-lsp-errors" were added ~15 years ago. LSP > corruption storms driven by receivers that purge corrupted LSPs and > originators that > re-originate and flood on receipt of said purged LSPs are very problematic > and > otherwise difficult to identify in practice. > > Coincidentally, it's also why logging LSPs that trigger such errors is > important, whether > you ignore them or propagate them. I really wish there was a good way to (generically) keep a 4-6 hour buffer of all control-plane traffic on devices. While you can do that with some, the forensic value is immense when you have a problem. - Jared >
Re: NANOG Digest, Vol 32, Issue 119
Thu, 30 Sep 2010 14:22:07 + nanog-requ...@nanog.org fuream loqour : >If your network is of a scale where it exceeds the utility of static, >then, it is almost certainly of a scale >and topology where it exceeds the utility of RIP. I'd agree that RIP is old, aged, and we all can probably go on with personal horror stories of how a broadcast-only-based routing protocol created a small or large pocket of disaster alone or combined with some other technology below or above its layer in the stack. However, like some other speakers in this thread mentioned, situation + simplicity + engineering = success. RIP certainly has it's place in small pockets now, I still use it in places mostly just to float a few loopbacks or statics around with old equipment, or firewalls I don't trust doing a more robust routing protocol. I see routing protocols, operating systems too, as different tools. If the tool works, fits, and rarely breaks where it's used, cool - I like simple & predictable, which includes predictable failure as well as predictable success. RIP also has the advantage of being around for a long while, so most devices will "get it right" - more complex routing protocol code, found in other IGPs, etc. - exceptions / vendor implementations still rule. I've never done a multicast network with RIP though... *winks* =) /dmfh -- __| |_ __ / _| |_ 01100100 01101101 / _` | ' \| _| ' \01100110 01101000 \__,_|_|_|_|_| |_||_|dmfh(-2)dmfh.cx
Re: Using crypto auth for detecting corrupted IGP packets?
> > I really wish there was a good way to (generically) keep a 4-6 hour buffer of > all control-plane traffic on devices. While you can do that with some, the > forensic value is immense when you have a problem. > Buffering for 4-6 hours worth of control traffic is HUGE! What about mirroring your control traffic arriving on your network ports to some other dedicated port? Manav
Re: AS11296 -- Hijacked?
I received a nice email from a very polite graduate student just now, who shall remain nameless, and I decided that I wanted to give him the reply below, but also to post this all to NANOG too, so here it is. I hope this may ally some of the concern that has been expressed about me not being more forthcomeing about the details of this case. (And if anybody gives me a hard time about being ``off topic'' then I'm going to give him or her a knucke sandwich, because I was specifically asked... indeed badgered... to provide more explanation of, and more justification for my earlier posting, as the record in the archives of this list will clearly show.) The friendly graduate student wote: >I've been quietly following NANOG's little flamewar over this. I'm >interested in what techniques you used to arrive at your conclusion >regarding AS11296. > >Unfortunately for me, I'm not a network op. Instead, I am a PhD student >interested in all matters inter-domain. I hope you feel this is enough >to make me a worthy recipient. No, actually, it isn't. If I google you can I be _sure_ that you're not playing for the other team? Probably not. But the good news is that I have decided to be a bit less cagey generally, and specifically in my public comments about these things anyway, and to give out more confirming data bits anyway. And I'll be sending this letter on to the NANOG list soon, with your name redacted, of course. What follows below is information that could be gleened (if you know how) from whois.internic.net. It's all public info. I just rearrange it and print it out in a nice pretty way. (Of course knowing where to look within the vast IPv4 address space is also quite helpful, but I'm not going to get in to that.) The bottom line here is that if you get the whois records for the domains associated with the name servers in the list attached at the end, you'll see that they are all going to be ``fishy'' in some way, e.g. ``cloaked'' (aka ``privacy protected''), or else registered to some mystery fly-by night company that may or may not actually exist, or at any rate, the domains will all be registered to something sort-of stealthy... something which is intended to make the spammer behind all this a bit harder to find. Oh yea, and the snail mail addresses given in the WHOIS records for the domains will usually/often be tracable to UPS Store rental P.O. boxes... those are standard spammer favorites, because...as they well know... us spamfighters can't find out who really controls any one of those boxes without a subpoena... unlike USPS boxes, for instance. (All this is quite well known in the dank sleezy spammer undergound already, so I'm not hardly giving away any secrets here.) And in a similar vein, the contact phone numbers given in the whois records will quite typically be 1-800 or 1-888 or 1-877 or 1-866 toll-free numbers. No, the spammers are _not_ trying to save you money when you want to call them up to bitch to them about the fact that they sent you 8,372 spams in a row. Nope, again, they use the toll-free numbers for a very specific purpose, which is again to make it more difficult for anyone trying to track them down to find their actual physical location. Non-tollfree numbers are typically associated with a specific geographic vicinity (although even that is being substantially eroded by number portability). But the toll free numbers are truly and always utterly geographically anonymous. So spammers use them a lot, primarily in domain whois records. So here you are. You've got this s**t load of highly ``fishy'' name servers, and they are all planted firmly into IP space that (a) appears to have been allocated to a reputable name brand company... such as Seiko, in this case... *and* (b) the block in question, based on the RegDate: and Updated: fields of the block's ARIN whois record, apparently hasn't been touched for years... maybe even a decade or more... thus implying that the former owners of the block either have abandoned it years ago, or else they themselves went belly up and ceased to exist, probably during the Great Dot Com Crash of 2000. Add it all up and what does it spell? No, not heartburn... Hijack. See, there actually isn't any big mystery about any of this, except the part about how I came to focus on this particular set of IP blocks and/or the particular AS that was announcing routes to them. And about that part, I have nothing to say, except to tell these spammers (who are probably listening) what I always say... that spamming is THE most public of all crimes. If you really think that you an hide and be totally invisible, even while you blast MILLIONS of total strangers with your advertising, then you need to up your lithium, because the dosage you're on now clearly isn't doing the job. Oh, and one other small thing... Even though the spammers try to hide themselves, often times, they really don't try THAT hard, probably because most folks don't care enoug
RE: AS11296 -- Hijacked?
> -Original Message- > From: Ronald F. Guilmette [mailto:r...@tristatelogic.com] > Sent: Thursday, September 30, 2010 10:48 PM > To: nanog@nanog.org > Subject: Re: AS11296 -- Hijacked? > > 63.247.172.3 > ns1.tooplacedomain10tht.info > 63.247.172.4 > ns2.tooplacedomain10tht.info > 63.247.181.3 > ns1.steadyvolumebandw57.info > 63.247.181.4 > ns2.steadyvolumebandw57.info > 63.247.185.19 > ns1.magnumfourcompkriel.info > 63.247.185.20 > ns2.magnumfourcompkriel.info ... I would take more of an Occam's razor approach. If you have an AS that is supposedly an ISP in North Carolina or Ohio or wherever and first of all have only one way into their network (are they an ISP or are they simply reselling someone else's service?) and none of that connectivity traces back to their region of operation, and particularly where their name has been bought by or merged with someone else and that someone else is not announcing their AS and address blocks, then that is certainly cause for suspicion."Hijacking" of defunct resources is probably a widespread activity. Finding the hijacked resources of companies that liquidated in fairly public fashion is probably easier than finding resources for a company that has been "laundered" through several mergers over several years where the current company doesn't even realize that they "own" the resources of a company bought by a company they bought because of personnel turnover involved with layoffs and such. To the general population of this list: Have you worked for a company that has liquidated? Are those Internet resource registrations still in whois? Maybe you should inform ARIN so those resources can be reclaimed. I did that when I noticed that a company I once worked for that evaporated still had resources in the database. That is just ASKING for someone to announce those resources and nobody is probably going to blink an eye because the upstreams rarely check to see if the entity they are talking to are actually authorized to announce that space. You tell them the ASN and net blocks, the two jibe, upstream says OK. How much address space is being wasted in this way? G
