Verisign wins an award...
Seeing as this didn't appear to hit NANOG yet - Our dear friends at Verisign won the Internet Villain of the year award at the UK ISPA awards last night for their presumption that they own the internet and the domain name system hijacking scandal. cheers, Ray Bellis -- Ray Bellis, MA(Oxon) - Technical Director community internet plc - ts.com Ltd Windsor House, 12 High Street, Kidlington, Oxford, OX5 2PJ tel: +44 1865 856000 email: [EMAIL PROTECTED] fax: +44 1865 856001 web: http://www.community.net.uk/
Re: Verisign wins an award...
Small clarification, this was award for year 2003. But I think they are planning on being nominated (and winning) this year as well ... On Fri, 20 Feb 2004, Ray Bellis wrote: Seeing as this didn't appear to hit NANOG yet - Our dear friends at Verisign won the Internet Villain of the year award at the UK ISPA awards last night for their presumption that they own the internet and the domain name system hijacking scandal. cheers, Ray Bellis
Re: Verisign wins an award...
Jeepers. VGRS beat out the RIAA, the UK form of Total Misinformation Stupidity, a member of Parliment known to be dumber than a post, and a band of looters. Pity they didn't post rankings and ballots. http://www.ispaawards.org.uk/categories/villain.htm
Re: Identifying IP address types (fwd)
Public reply, because private are blocked. http://www.ietf.org/internet-drafts/draft-stumpf-dns-mtamark-01.txt uses rev-dns TXT RRs to let admins document which IP addresses are supposed to act as MTA (as well as to document which addresses are supposed not to send mail). The difference is an ISP may permit any customer to act as an MTA. The ISP does not want to decide about what to permit or deny. But the ISP may be willing to provide more information about an address so other people can decide if they want to behave differently depending on the type of connection. For example, an IRC operator may decide not to permit anyone using a dynamic address to connect, or a Web site may want to send smaller pages to users on low bandwidth connections. In fact, you won't be able to reply to this email unless [EMAIL PROTECTED] enters @origin 53.34.199.in-addr.arpa _perm._stmp_srv.180 IN TXT 1 into the DNS for you. If an ISP permits every IP address to use any service, what does it accomplish? If an ISP didn't want to permit its users to access SMTP, the ISP would just block port 25 at the network layer.
Re: Anycast and windows servers
On Thu, 19 Feb 2004, Patrick W.Gilmore wrote: Honestly, I do not know about OSPF (or BGP) on Windows, however, you can just static route to the Windows box(es). Sure, if the OS hangs, the interface will stay up and the static route will still push bits at the dead box, but it will work (FSVO work). Besides, how often does Windows crash? snicker Hence the reason why I want the route to cease being advertised if the box fails. I'm trying to avoid putting yet another server load balancer box in front of the windows box to withdraw the route so a different working box will be closest. It may be an oxymoron, but I'm trying to make the windows service (if not a particular windows box) as reliable as possible without introducing more boxes than necessary.
The Cidr Report
This report has been generated at Fri Feb 20 21:47:50 2004 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
13-02-04131225 91573
14-02-04131314 91491
15-02-04131233 91647
16-02-04131350 91764
17-02-04131484 91764
18-02-04131572 91814
19-02-04131618 91835
20-02-04131753 91795
AS Summary
16600 Number of ASes in routing system
6654 Number of ASes announcing only one prefix
1385 Largest number of prefixes announced by an AS
AS7018 : ATTW ATT WorldNet Services
73517312 Largest address span announced by an AS (/32s)
AS568 : DISOUN DISO-UNRRA
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 20Feb04 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 131836918423999430.3% All ASes
AS4323 692 202 49070.8% TWC-34 Time Warner
Communications, Inc.
AS6197 733 299 43459.2% BNS-14 BellSouth Network
Solutions, Inc
AS7018 1385 967 41830.2% ATTW ATT WorldNet Services
AS701 1324 949 37528.3% UU UUNET Technologies, Inc.
AS7843 505 132 37373.9% ADELPH-13 Adelphia Corp.
AS27364 382 33 34991.4% ARMC Armstrong Cable Services
AS6198 545 214 33160.7% BNS-14 BellSouth Network
Solutions, Inc
AS4134 653 330 32349.5% CHINANET-BACKBONE
No.31,Jin-rong Street
AS22909 342 20 32294.2% CMCS Comcast Cable
Communications, Inc.
AS22773 344 35 30989.8% CXAB Cox Communications Inc.
Atlanta
AS9583 354 47 30786.7% SATYAMNET-AS Satyam Infoway
Ltd.,
AS1239 945 661 28430.1% SPRN Sprint
AS4355 385 101 28473.8% ERSD EARTHLINK, INC
AS17676 294 41 25386.1% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS1221 897 645 25228.1% ASN-TELSTRA Telstra Pty Ltd
AS6347 330 83 24774.8% SAVV SAVVIS Communications
Corporation
AS6478 268 39 22985.4% ATTW ATT WorldNet Services
AS25844 243 16 22793.4% SASMFL-2 Skadden, Arps, Slate,
Meagher Flom LLP
AS6140 357 134 22362.5% IMPSA ImpSat
AS14654 2164 21298.1% WAYPOR-3 Wayport
AS209716 505 21129.5% QWEST-4 Qwest
AS11305 242 41 20183.1% INTERL-80 Interland
Incorporated
AS2386 426 233 19345.3% ADCS-1 ATT Data
Communications Services
AS5668 346 158 18854.3% CIH-12 CenturyTel Internet
Holdings, Inc.
AS20115 608 422 18630.6% CHARTE-72 Charter
Communications
AS4519 203 20 18390.1% MAASCO Maas Communications
AS6327 207 29 17886.0% SHAWC-2 Shaw Communications
Inc.
AS9929 208 30 17885.6% CNCNET-CN China Netcom Corp.
AS4766 418 247 17140.9% KIX Korea Internet Exchange
for 96 World Internet
Exposition
AS15270 211 40 17181.0% PDP-14 PaeTec.net -a division
of PaeTecCommunications, Inc.
Total 14779 6677 810254.8% Top 30 total
Possible Bogus Routes
24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o Halifax
Cable Ltd.
63.0.0.0/8 AS705 UU UUNET Technologies, Inc.
64.46.0.0/18 AS7850 IHIGHW iHighway.net, Inc.
64.46.4.0/22 AS11711 TULARO TULAROSA COMMUNICATIONS
Re: Anycast and windows servers
Sean, Hence the reason why I want the route to cease being advertised if the box fails. I'm trying to avoid putting yet another server load balancer box in front of the windows box to withdraw the route so a different working box will be closest. It may be an oxymoron, but I'm trying to make the windows service (if not a particular windows box) as reliable as possible without introducing more boxes than necessary. You might be better not running the routing protocol on the Windows box, and run gated (or whatever) on some nearby Linux/BSD box which tests the availability of each of your windows box and introduces the appropriate route (i.e. a next-hop for the anycast address pointing at a normal IP address) into (a very local) BGP (running multipath) or other favorite routing protocol for each of the servers that are up. Alex
Re: Anycast and windows servers
At 05:43 AM 2/20/2004, you wrote: Hence the reason why I want the route to cease being advertised if the box fails. I'm trying to avoid putting yet another server load balancer box in front of the windows box to withdraw the route so a different working box will be closest. It may be an oxymoron, but I'm trying to make the windows service (if not a particular windows box) as reliable as possible without introducing more boxes than necessary. You haven't said what type of service you want to make as reliable as possible. It sounds like you want to use clustering or network load balancing. With clustering, you can have the service present on both machines and if the link between the two fails or if the service on the primary machine fails, the second machine will take over. You can also use shared Fiber-channel or SCSI devices between the two servers. You can also use network load balancing to share a non-transaction based service between servers. If you do it this way, you will get automatic load balancing to double the speed and capacity between the two or more servers in the NLB cluster since they all service requests all the time. In both cases, you will create a virtual IP address which receives all connections and both machines in the cluster will determine which machine handles each connection. This isn't hard and we do it all the time. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 Good will, like a good name, is got by many actions, and lost by one. - Francis Jeffrey
Re: Anycast and windows servers
At 05:43 AM 2/20/2004, you wrote: On Thu, 19 Feb 2004, Patrick W.Gilmore wrote: Honestly, I do not know about OSPF (or BGP) on Windows, however, you can just static route to the Windows box(es). Sure, if the OS hangs, the interface will stay up and the static route will still push bits at the dead box, but it will work (FSVO work). Besides, how often does Windows crash? snicker Hence the reason why I want the route to cease being advertised if the box fails. Connect the server(s) to APC MasterSwitch or equivalent hardware. Monitor the server box(es) for responsiveness. If/when it fails, the monitoring station can instruct the MasterSwitch to reboot (power cycle, really) the box. Stuff is pretty inexpensive (certainly less so than load balancers). I'm trying to avoid putting yet another server load balancer box in front of the windows box to withdraw the route so a different working box will be closest. It may be an oxymoron, but I'm trying to make the windows service (if not a particular windows box) as reliable as possible without introducing more boxes than necessary. My initial thought last night was in fact the use of load balancers. But then you need to think about redundant load balancers and so on.
RE: Anycast and windows servers
Depending on the service being provided, Microsoft has their own clustering solution which will perform failover. Sometimes choosing full vendor supported technologies is the easiest path. With Windows 2003 Server they even support geographically disperses failover. Info at: http://www.microsoft.com/windows2000/technologies/clustering/default.asp Gary -Original Message- From: Daniel Senie [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 6:39 AM To: Sean Donelan Cc: [EMAIL PROTECTED] Subject: Re: Anycast and windows servers At 05:43 AM 2/20/2004, you wrote: On Thu, 19 Feb 2004, Patrick W.Gilmore wrote: Honestly, I do not know about OSPF (or BGP) on Windows, however, you can just static route to the Windows box(es). Sure, if the OS hangs, the interface will stay up and the static route will still push bits at the dead box, but it will work (FSVO work). Besides, how often does Windows crash? snicker Hence the reason why I want the route to cease being advertised if the box fails. Connect the server(s) to APC MasterSwitch or equivalent hardware. Monitor the server box(es) for responsiveness. If/when it fails, the monitoring station can instruct the MasterSwitch to reboot (power cycle, really) the box. Stuff is pretty inexpensive (certainly less so than load balancers). I'm trying to avoid putting yet another server load balancer box in front of the windows box to withdraw the route so a different working box will be closest. It may be an oxymoron, but I'm trying to make the windows service (if not a particular windows box) as reliable as possible without introducing more boxes than necessary. My initial thought last night was in fact the use of load balancers. But then you need to think about redundant load balancers and so on.
Re: Anycast and windows servers
Given your initial question was, I think, about the OSPF implementation on windows - I used it on NT 4.0, when it was part of the routing and remote access option, to implement fault tolerant routing through some windows based firewalls. It worked fine then. So long as you minimize the services running on the windows box, it was stable enough. Have not used window servers since NT 4.0, but I don't imagine its gotten worse. Buhrmaster, Gary wrote: Depending on the service being provided, Microsoft has their own clustering solution which will perform failover. Sometimes choosing full vendor supported technologies is the easiest path. With Windows 2003 Server they even support geographically disperses failover. Info at: http://www.microsoft.com/windows2000/technologies/clustering/default.asp Gary -Original Message- From: Daniel Senie [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 6:39 AM To: Sean Donelan Cc: [EMAIL PROTECTED] Subject: Re: Anycast and windows servers At 05:43 AM 2/20/2004, you wrote: On Thu, 19 Feb 2004, Patrick W.Gilmore wrote: Honestly, I do not know about OSPF (or BGP) on Windows, however, you can just static route to the Windows box(es). Sure, if the OS hangs, the interface will stay up and the static route will still push bits at the dead box, but it will work (FSVO work). Besides, how often does Windows crash? snicker Hence the reason why I want the route to cease being advertised if the box fails. Connect the server(s) to APC MasterSwitch or equivalent hardware. Monitor the server box(es) for responsiveness. If/when it fails, the monitoring station can instruct the MasterSwitch to reboot (power cycle, really) the box. Stuff is pretty inexpensive (certainly less so than load balancers). I'm trying to avoid putting yet another server load balancer box in front of the windows box to withdraw the route so a different working box will be closest. It may be an oxymoron, but I'm trying to make the windows service (if not a particular windows box) as reliable as possible without introducing more boxes than necessary. My initial thought last night was in fact the use of load balancers. But then you need to think about redundant load balancers and so on.
whois.internic.net problems?
Anyone know what is up with whois.internic.net? It seems to be having serious problems. When using a command line whois, it either hangs forever or gets a connection refused. About 1 time in 5 can I get a query to work. I have tried it from both our local systems and a hosted server we use and get the same results. When trying to report bogus registration data using http://reports.internic.net/cgi/rpt_whois/rpt.cgi, I get Unable to connect to registry whois, please try later most of the time. Anyone have any idea what gives? Are they getting DDOSed or something? Thanks! Jon K. -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 == Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.
RE: whois.internic.net problems?
Good question. I've been seeing similar results command line, and additionally I've noted some problems with the web-based whois as well. /Alex Kiwerski -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jon R. Kibler Sent: Friday, February 20, 2004 10:41 AM To: [EMAIL PROTECTED] Subject: whois.internic.net problems? Anyone know what is up with whois.internic.net? It seems to be having serious problems. When using a command line whois, it either hangs forever or gets a connection refused. About 1 time in 5 can I get a query to work. I have tried it from both our local systems and a hosted server we use and get the same results. When trying to report bogus registration data using http://reports.internic.net/cgi/rpt_whois/rpt.cgi, I get Unable to connect to registry whois, please try later most of the time. Anyone have any idea what gives? Are they getting DDOSed or something? Thanks! Jon K. -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 == Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.
RouteScience PathControl vs. Radware Linkproof
Looking for anyone who's done a direct comparison of the two (I understand the way they fundamentally work is completely different, however they both try to achieve the same thing). I'm doing my own bake-off here and I'd like to hear others' opinions. Direct replies are OK Thanks, -Dave
Re: eBGP, iBGP, injecting networks
Ok. The way I read this is that you're redundant as far as one of your upstream links going down - it'd not cause complete meltdown as that router that had that link would still be announcing that space to the other router (over EBGP) and then to the net. What you're worrying then is what happens if actual router is down, right? But that begs the question of how you're getting the routes that router is announcing in the first place. Is it coming from some other edge router (that is also talking over local net to your 2nd core router)? If so each of your routers has complete local routes table through IBGP and you are not announcing it all because you're using static network statements in BGP config. In that case my suggestion would be to drop EBGP connection between routers and have each router announce entire ip space but put up 'as-path prepend' statements with the other adding the other router's ASN for routes that you want to be considered as being primary from that other router. Now exact configuration suggestion would depend on what hardware the routers are, i.e. is it cisco, etc. P.S. I've never been in situation of having to merge two ASN's or in situation you describe, so possibly people who have would have better suggestions. On Fri, 20 Feb 2004 [EMAIL PROTECTED] wrote: greetings list, hoping someone can hook me up on the right way to do this. --- we have two ASN's we control. we have two border/edge routers (1 in each ASN) that talks to a different backbone provider. the two border routers peer with eachother over eBGP and also are in the same OSPF process. (we are working to merge them into the same BGP ASN) my question is this: how do we achieve router redundancy between these two routers? currently if we lose a transit link, the traffic will flow fine out the other pipe. but we don't have BGP network statements in router 2 that exist in router 1 and we don't have BGP network statements in router 1 that exist in router 2. so the routes injected into BGP from router 1 will get withdrawn right if router 1 dies? is it a problem to announce the same networks from two different eBGP peers to two different upstreams? -- if you are still reading, thanks! to clearify some more- current setup: current setup: ASN 1 (we're not Genu!ty- just using for an example) :) ASN 1 injects all of its own space and announces this space to Above.net and ASN 2 ASN 2 injects all of its own space and announces this space to Savvis and ASN 1. so stuff out on the net looks like: 1 6461 etc etc and 1 2 6347 --- 2 6347 etc etc and 2 1 6461 etc etc --- so, you see we are prepending on of our AS's on the way out. the problem is tho, we only have 1 router in each respective Autonmous System injecting address space. if we lose that router, we lose announcing that ASN's space. is it totally going to cause probs to have routes originating from two different AS's? routing loops would be a real drag. what about having an iBGP router in AS 1 inject the same space as the border router in AS 1? this other router also peers with AS 2 thanks a lot! jg
Re: eBGP, iBGP, injecting networks
Note - I got confused by the subject and everything myself. The routes you have locally would not be from IBGP but just directly through IGP (i.e. OSPF or EIGRP etc). I don't think you can really do IBGP if routers are not configured with the same ASN. On Fri, 20 Feb 2004, william(at)elan.net wrote: Ok. The way I read this is that you're redundant as far as one of your upstream links going down - it'd not cause complete meltdown as that router that had that link would still be announcing that space to the other router (over EBGP) and then to the net. What you're worrying then is what happens if actual router is down, right? But that begs the question of how you're getting the routes that router is announcing in the first place. Is it coming from some other edge router (that is also talking over local net to your 2nd core router)? If so each of your routers has complete local routes table through IBGP and you are not announcing it all because you're using static network statements in BGP config. In that case my suggestion would be to drop EBGP connection between routers and have each router announce entire ip space but put up 'as-path prepend' statements with the other adding the other router's ASN for routes that you want to be considered as being primary from that other router. Now exact configuration suggestion would depend on what hardware the routers are, i.e. is it cisco, etc. P.S. I've never been in situation of having to merge two ASN's or in situation you describe, so possibly people who have would have better suggestions. On Fri, 20 Feb 2004 [EMAIL PROTECTED] wrote: greetings list, hoping someone can hook me up on the right way to do this. --- we have two ASN's we control. we have two border/edge routers (1 in each ASN) that talks to a different backbone provider. the two border routers peer with eachother over eBGP and also are in the same OSPF process. (we are working to merge them into the same BGP ASN) my question is this: how do we achieve router redundancy between these two routers? currently if we lose a transit link, the traffic will flow fine out the other pipe. but we don't have BGP network statements in router 2 that exist in router 1 and we don't have BGP network statements in router 1 that exist in router 2. so the routes injected into BGP from router 1 will get withdrawn right if router 1 dies? is it a problem to announce the same networks from two different eBGP peers to two different upstreams? -- if you are still reading, thanks! to clearify some more- current setup: current setup: ASN 1 (we're not Genu!ty- just using for an example) :) ASN 1 injects all of its own space and announces this space to Above.net and ASN 2 ASN 2 injects all of its own space and announces this space to Savvis and ASN 1. so stuff out on the net looks like: 1 6461 etc etc and 1 2 6347 --- 2 6347 etc etc and 2 1 6461 etc etc --- so, you see we are prepending on of our AS's on the way out. the problem is tho, we only have 1 router in each respective Autonmous System injecting address space. if we lose that router, we lose announcing that ASN's space. is it totally going to cause probs to have routes originating from two different AS's? routing loops would be a real drag. what about having an iBGP router in AS 1 inject the same space as the border router in AS 1? this other router also peers with AS 2 thanks a lot! jg
Re: eBGP, iBGP, injecting networks
Well, you sort of can with confederations (internally) but the external view is still the single advertised ASN. At 07:10 PM 2/20/2004, william(at)elan.net wrote: Note - I got confused by the subject and everything myself. The routes you have locally would not be from IBGP but just directly through IGP (i.e. OSPF or EIGRP etc). I don't think you can really do IBGP if routers are not configured with the same ASN. On Fri, 20 Feb 2004, william(at)elan.net wrote: Ok. The way I read this is that you're redundant as far as one of your upstream links going down - it'd not cause complete meltdown as that router that had that link would still be announcing that space to the other router (over EBGP) and then to the net. What you're worrying then is what happens if actual router is down, right? But that begs the question of how you're getting the routes that router is announcing in the first place. Is it coming from some other edge router (that is also talking over local net to your 2nd core router)? If so each of your routers has complete local routes table through IBGP and you are not announcing it all because you're using static network statements in BGP config. In that case my suggestion would be to drop EBGP connection between routers and have each router announce entire ip space but put up 'as-path prepend' statements with the other adding the other router's ASN for routes that you want to be considered as being primary from that other router. Now exact configuration suggestion would depend on what hardware the routers are, i.e. is it cisco, etc. P.S. I've never been in situation of having to merge two ASN's or in situation you describe, so possibly people who have would have better suggestions. On Fri, 20 Feb 2004 [EMAIL PROTECTED] wrote: greetings list, hoping someone can hook me up on the right way to do this. --- we have two ASN's we control. we have two border/edge routers (1 in each ASN) that talks to a different backbone provider. the two border routers peer with eachother over eBGP and also are in the same OSPF process. (we are working to merge them into the same BGP ASN) my question is this: how do we achieve router redundancy between these two routers? currently if we lose a transit link, the traffic will flow fine out the other pipe. but we don't have BGP network statements in router 2 that exist in router 1 and we don't have BGP network statements in router 1 that exist in router 2. so the routes injected into BGP from router 1 will get withdrawn right if router 1 dies? is it a problem to announce the same networks from two different eBGP peers to two different upstreams? -- if you are still reading, thanks! to clearify some more- current setup: current setup: ASN 1 (we're not Genu!ty- just using for an example) :) ASN 1 injects all of its own space and announces this space to Above.net and ASN 2 ASN 2 injects all of its own space and announces this space to Savvis and ASN 1. so stuff out on the net looks like: 1 6461 etc etc and 1 2 6347 --- 2 6347 etc etc and 2 1 6461 etc etc --- so, you see we are prepending on of our AS's on the way out. the problem is tho, we only have 1 router in each respective Autonmous System injecting address space. if we lose that router, we lose announcing that ASN's space. is it totally going to cause probs to have routes originating from two different AS's? routing loops would be a real drag. what about having an iBGP router in AS 1 inject the same space as the border router in AS 1? this other router also peers with AS 2 thanks a lot! jg Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.
Re: eBGP, iBGP, injecting networks
Hi Your problem may be is similar when one ISP buy to another ISP, sometimes is easy to modify the IGP like in this case (OSPF) because it is something inside of your company and you have the control over all the devices but you still have the problem outside of the company; client, others ISP, etc Check the feature of BGP Local-AS for routers Cisco if yours routers aren't Cisco, check for someone similar with your vendor. May be you need to do something else. This is the url where explain how it works. http://www.cisco.com/en/US/tech/tk365/tk80/technologies_configuration_example09186a00800949cd.shtml I hope it help you -Hans On Fri, 20 Feb 2004 [EMAIL PROTECTED] wrote: greetings list, hoping someone can hook me up on the right way to do this. --- we have two ASN's we control. we have two border/edge routers (1 in each ASN) that talks to a different backbone provider. the two border routers peer with eachother over eBGP and also are in the same OSPF process. (we are working to merge them into the same BGP ASN) my question is this: how do we achieve router redundancy between these two routers? currently if we lose a transit link, the traffic will flow fine out the other pipe. but we don't have BGP network statements in router 2 that exist in router 1 and we don't have BGP network statements in router 1 that exist in router 2. so the routes injected into BGP from router 1 will get withdrawn right if router 1 dies? is it a problem to announce the same networks from two different eBGP peers to two different upstreams? -- if you are still reading, thanks! to clearify some more- current setup: current setup: ASN 1 (we're not Genu!ty- just using for an example) :) ASN 1 injects all of its own space and announces this space to Above.net and ASN 2 ASN 2 injects all of its own space and announces this space to Savvis and ASN 1. so stuff out on the net looks like: 1 6461 etc etc and 1 2 6347 --- 2 6347 etc etc and 2 1 6461 etc etc --- so, you see we are prepending on of our AS's on the way out. the problem is tho, we only have 1 router in each respective Autonmous System injecting address space. if we lose that router, we lose announcing that ASN's space. is it totally going to cause probs to have routes originating from two different AS's? routing loops would be a real drag. what about having an iBGP router in AS 1 inject the same space as the border router in AS 1? this other router also peers with AS 2 thanks a lot! jg
RE: Verizon clients DOS own site?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 19, 2004 3:57 PM To: [EMAIL PROTECTED] Subject: Verizon clients DOS own site? I've tried contacting Verizon via email but I haven't received a response and their tech support had no information on this. Although we're now blocking this site and trying to clean up the clients, this is still generation a lot of noise on our network. Any ideas on how to get Verizon to take a look at this? Calling the NOC numbers available via the puck.nether.net site would be a good start (info recently updated from older Bell Atlantic references). This sounds like part of the support tools installed as part of the VOL setup discs. I'll fwd info onto VOL to confirm, though website IS valid (perhaps there is an issue interacting w/ VPN setup). Any input is welcome. Thanks, np ___ Wayne Gustavus, CCIE #7426 Operations Engineering Verizon Internet Services ___
Re: Verizon clients DOS own site?
I have already claled VZ about htis issue as i see it tons here too..their response: We only provide connectivity and we do not take actions in terms of port filtering or blocking. Wayne Gustavus (nanog) wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, February 19, 2004 3:57 PM To: [EMAIL PROTECTED] Subject: Verizon clients DOS own site? I've tried contacting Verizon via email but I haven't received a response and their tech support had no information on this. Although we're now blocking this site and trying to clean up the clients, this is still generation a lot of noise on our network. Any ideas on how to get Verizon to take a look at this? Calling the NOC numbers available via the puck.nether.net site would be a good start (info recently updated from older Bell Atlantic references). This sounds like part of the support tools installed as part of the VOL setup discs. I'll fwd info onto VOL to confirm, though website IS valid (perhaps there is an issue interacting w/ VPN setup). Any input is welcome. Thanks, np ___ Wayne Gustavus, CCIE #7426 Operations Engineering Verizon Internet Services ___ -- May God Bless you and everything you touch. My foundation verse: Isaiah 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD.
Re: eBGP, iBGP, injecting networks
greetings, from what you are saying, it appears you just got two routers in the equation.. i say it's just easier for you to merge both routers into single asn and run an igp in between. announce your aggregate(s) at both routers afterwards, now that they are in same asn. so no inconsistant-AS issue there if your transit provider is not being cooperative fast enough, temporarily use 'neighbor a.b.c.d local-as oldasn'. then you can get rid of that once they update their end. as far as announcing same space between two diff. asn's causing problems.. yes and no. as long as your FIB entries for the most specific are pointing to working path on both routers, you won't run into technical problem. but this is inconsistant-AS issue which is often perceived as 'not cool.' IMHO, its ad-hoc solution -J -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 IPv6 colocation, web hosting, network design implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE On Fri, Feb 20, 2004 at 02:41:46PM -0800, [EMAIL PROTECTED] wrote: greetings list, hoping someone can hook me up on the right way to do this. --- we have two ASN's we control. we have two border/edge routers (1 in each ASN) that talks to a different backbone provider. the two border routers peer with eachother over eBGP and also are in the same OSPF process. (we are working to merge them into the same BGP ASN) my question is this: how do we achieve router redundancy between these two routers? currently if we lose a transit link, the traffic will flow fine out the other pipe. but we don't have BGP network statements in router 2 that exist in router 1 and we don't have BGP network statements in router 1 that exist in router 2. so the routes injected into BGP from router 1 will get withdrawn right if router 1 dies? is it a problem to announce the same networks from two different eBGP peers to two different upstreams? -- if you are still reading, thanks! to clearify some more- current setup: current setup: ASN 1 (we're not Genu!ty- just using for an example) :) ASN 1 injects all of its own space and announces this space to Above.net and ASN 2 ASN 2 injects all of its own space and announces this space to Savvis and ASN 1. so stuff out on the net looks like: 1 6461 etc etc and 1 2 6347 --- 2 6347 etc etc and 2 1 6461 etc etc --- so, you see we are prepending on of our AS's on the way out. the problem is tho, we only have 1 router in each respective Autonmous System injecting address space. if we lose that router, we lose announcing that ASN's space. is it totally going to cause probs to have routes originating from two different AS's? routing loops would be a real drag. what about having an iBGP router in AS 1 inject the same space as the border router in AS 1? this other router also peers with AS 2 thanks a lot! jg
