RE: Can P2P applications learn to play fair on networks?
And of course, if you still believe just adding bandwidth will solve the problems Joe St. Sauver probably said it best when he pointed out in slide 5 here http://www.uoregon.edu/~joe/i2-cap-plan/internet2-capacity-planning.ppt the N-body problem can be a complex problem to try to solve except via an iterative and incremental process. I expect that is why sometimes adding capacity works and sometimes it doesn't. This is the sort of situation that benefits from having an architectural vision which all the independent actors (n-bodies) can work towards. A lot of P2P development work in the past has treated the Internet as a kind of black box which the P2P software attempts to reverse engineer or treat simplistically as a set of independent paths with varying latencies. If P2P software relied on an ISP middlebox to mediate the transfers, then each middlebox could optimize the local situation by using a whole smorgasbord of tools. They could kill rogue sessions that don't use the middle box by using RSTs or simply triggering the ISP's OSS to set up ACLs etc. They could tell the P2P endpoints how many flows are allowed, maximum flowrate during specific timewindows, etc. This doesn't mean that all the bytes need to flow through the middleboxes, merely that P2P clients cooperate with the middleboxes when opening sockets/sessions. --Michael Dillon
Re: Can P2P applications learn to play fair on networks?
[EMAIL PROTECTED] schrieb: If P2P software relied on an ISP middlebox to mediate the transfers, then each middlebox could optimize the local situation by using a whole smorgasbord of tools. Are there any examples of middleware being adopted by the market? To me, it looks like the clear trend is away from using ISP-provided applications and services, towards pure packet pushing (cf. HTTP proxies, proprietary information services). I'm highly sceptical that users would want to adopt any software that ties them more to their ISP, not less. Stefan
Re: IPv6 firewall support
Have to say, using screenOS 5.4 on our juniper kit and relatively happy. Elsewhere, if you just want a packet filter, v6 ACLs are fine, depending of course whether they are done in hardware or software and if this is appropriate for your application (i.e , ACL in software path is perfectly appropriate in a number of scenarios where you have dedicated router and low traffic environment) Dave. [EMAIL PROTECTED] wrote: Some people have claimed that they cannot yet sell IPv6 Internet access because there is no IPv6 firewall support. According to this ICANN study: http://www.icann.org/committees/security/sac021.pdf this is not quite true. At least 30% of the 42 vendors surveyed, had IPv6 support. According to this talk http://www.guug.de/veranstaltungen/ecai6-2007/slides/2007-ECA-I6-Status -IPv6-Firewalling-PeterBieringer-Talk.pdf many open-source and commercial firewalls supporting IPv6 are available. IPCop is based on Linux http://www.ipcop.org/index.php?module=pnWikkatag=IPCopScreenshots m0n0wall is based on FreeBSD http://m0n0.ch/wall/screenshots.php pfSense is also based on FreeBSD http://pfsense.com/index.php?id=26 FWBuilder is a management tool that builds filter setups for several different firewalls. http://www.fwbuilder.org/archives/cat_screenshots.html Checkpoint FW1 NGX R65 on SecurePlatform supports IPv6 FortiGate supports IPv6 in FortiOS 3.0 and up. Juniper SSG (formerly Netscreen) supports IPv6 in ScreenOS 6.0 and up. Cisco ASA (formerly PIX) supports IPv6 in version 7.0 and up. I suspect that the people complaining about IPv6 support are partially complaining because they have older hardware that the vendor does not plan to upgrade to IPv6 support until they have all features implemented in their newer products, and partially complaining because their vendor has not implemented some feature which they happen to use. Commercial firewall support may be lagging behind OS and router support, but not by much. And if commercial vendors are not responsive, maybe you should try pricing out an open source solution with a consultant. I believe there is a gap here that startup firewall companies could fill if they understand the enterprise market. --Michael Dillon
114/8 and 115/8 allocated to APNIC
Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in October 2007: 144/8 and 115/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space Please update your filters as appropriate. Regards, Leo vegoda Manager, Number Resources - IANA
RE: Can P2P applications learn to play fair on networks?
That and the fact that an ISP would be aiding and abetting illegal activities, in the eyes of the RIAA and MPAA. That's not to say that technically it would not be better, but that it will never happen due to political and legal issues, IMO. Fred Reimer, CISSP Senior Network Engineer Coleman Technologies, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Bethke Sent: Monday, October 29, 2007 8:37 AM To: [EMAIL PROTECTED] Cc: nanog@merit.edu Subject: Re: Can P2P applications learn to play fair on networks? [EMAIL PROTECTED] schrieb: If P2P software relied on an ISP middlebox to mediate the transfers, then each middlebox could optimize the local situation by using a whole smorgasbord of tools. Are there any examples of middleware being adopted by the market? To me, it looks like the clear trend is away from using ISP-provided applications and services, towards pure packet pushing (cf. HTTP proxies, proprietary information services). I'm highly sceptical that users would want to adopt any software that ties them more to their ISP, not less. Stefan smime.p7s Description: S/MIME cryptographic signature
Re: 114/8 and 115/8 allocated to APNIC
On 29 Oct 2007, at 16:44, Leo Vegoda wrote: The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in October 2007: 144/8 and 115/8. You can find the IANA IPv4 registry at: I made a typo in the body of this mail. APNIC was allocated 114/8 and not 144/8. Sorry for any confusion. Leo
Re: Can P2P applications learn to play fair on networks?
[EMAIL PROTECTED] wrote: And of course, if you still believe just adding bandwidth will solve the problems Joe St. Sauver probably said it best when he pointed out in slide 5 here http://www.uoregon.edu/~joe/i2-cap-plan/internet2-capacity-planning.ppt the N-body problem can be a complex problem to try to solve except via an iterative and incremental process. If P2P software relied on an ISP middlebox to mediate the transfers, then each middlebox could optimize the local situation by using a whole smorgasbord of tools. They could kill rogue sessions that don't use the middle box by using RSTs or simply triggering the ISP's OSS to set up ACLs etc. They could tell the P2P endpoints how many flows are allowed, maximum flowrate during specific timewindows, etc. When we put the application intelligence in the network. We have to upgrade the network to support new applications. I believe that's a mistake from the application innovation angle. Describing more accurately to the endpoints the properties of the network(s) to which they are attached is something that is perhaps desirable. most work in this area is historically done in the transport area, but congestion control is not really the only angle from which to approach the problem. Host's treat network's as black boxes because they don't really have any other choice in the matter. --Michael Dillon
RE: Can P2P applications learn to play fair on networks?
On Mon, 29 Oct 2007, Fred Reimer wrote: That and the fact that an ISP would be aiding and abetting illegal activities, in the eyes of the RIAA and MPAA. That's not to say that technically it would not be better, but that it will never happen due to political and legal issues, IMO. As always consult your own legal advisor, however in the USA DMCA 512(b) probably makes caching by ISPs legal. ISPs have not been shy about using the CDA and DMCA to protect themselves from liability. Although caching has been very popular outside the USA, in particular in countries with very expensive trans-oceanic circuits, in the USA caching is mostly a niche service for ISPs. The issue in the USA is more likely the cost of operating and maintaing the caching systems are more expensive than the operational cost of the bandwidth in the USA. Despite some claims from people that ISPs should just shovel packets, some US ISPs have used various caching systems for a decade. It would be a shame to make Squid illegal for ISPs to use.
Re: RIPE is just more fun.
Jared, I yanked the mp3 out of the youtube flv: http://blyon.com/ routers_died.mp3 -Barrett On Oct 26, 2007, at 1:19 PM, Jared Mauch wrote: On Fri, Oct 26, 2007 at 03:42:27PM -0400, Leo Bicknell wrote: http://www.youtube.com/watch?v=_y36fG2Oba0 Cool. Time for a remix as well! Maybe i'll go to RIPE next time!
RE: Can P2P applications learn to play fair on networks?
When we put the application intelligence in the network. We have to upgrade the network to support new applications. I believe that's a mistake from the application innovation angle. Putting middleboxes into an ISP is not the same thing as putting intelligence into the network. Think Akamai for instance. Describing more accurately to the endpoints the properties of the network(s) to which they are attached is something that is perhaps desirable. most work in this area is historically done in the transport area, but congestion control is not really the only angle from which to approach the problem. If the work focuses on making a P2P protocol that knows about ASNums and leverages middleboxes sitting in an ISP's network, then you would have a framework that can be used for more than just congestion control. Host's treat network's as black boxes because they don't really have any other choice in the matter. A router is a host that learns about the network topology by means of routing protocols, and then adjusts its behavior accordingly. Why can't other hosts similarly learn about the topology and adjust their behavior? --Michael Dillon
RE: Can P2P applications learn to play fair on networks?
The RIAA is specifically going after P2P networks. As far as I know, they are not going after Squid users/hosts. Although they may have at one point, it has never made the popular media as their effort against the P2P networks has. I'm not talking about caching at all anyway. I'm talking about what was suggested, that ISP's play an active role in helping their users locate local hosts to grab files from, rather than just anywhere out on the Internet. I think that is quite different than configuring a transparent proxy. Don't ask me why, it's not a technical or even necessarily a legal question (and IANAL anyway). It's more of a perception issue with the RIAA. If you work at an ISP ask your legal counsel if this would be a good idea. I doubt they would say yes. Fred Reimer, CISSP Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Donelan Sent: Monday, October 29, 2007 12:34 PM To: nanog@merit.edu Subject: RE: Can P2P applications learn to play fair on networks? On Mon, 29 Oct 2007, Fred Reimer wrote: That and the fact that an ISP would be aiding and abetting illegal activities, in the eyes of the RIAA and MPAA. That's not to say that technically it would not be better, but that it will never happen due to political and legal issues, IMO. As always consult your own legal advisor, however in the USA DMCA 512(b) probably makes caching by ISPs legal. ISPs have not been shy about using the CDA and DMCA to protect themselves from liability. Although caching has been very popular outside the USA, in particular in countries with very expensive trans-oceanic circuits, in the USA caching is mostly a niche service for ISPs. The issue in the USA is more likely the cost of operating and maintaing the caching systems are more expensive than the operational cost of the bandwidth in the USA. Despite some claims from people that ISPs should just shovel packets, some US ISPs have used various caching systems for a decade. It would be a shame to make Squid illegal for ISPs to use. smime.p7s Description: S/MIME cryptographic signature
Re: Any help for Yahoo! Mail arrogance?
On 10/29/07, Tuc at T-B-O-H.NET [EMAIL PROTECTED] wrote:
Unfortunately, we cannot provide you with
specific information other than to suggest a review
of the questionnaire we supplied and try to determine
where your mailing practices may be improved upon.
In other words, fix your forwarding a lot better (and possibly
segregate it from your main mail stream, clearly label the forwarding
IP as a forwarder, etc)
Yahoo arent really in the business of teaching people how to do a
better job. If that sounds like arrogance ..
srs
Fix your forwarding a lot better. Not sure what this
means. My machines are MX's for the clients domain. They
accept it, and either forward it around locally to one of the
processing MX's or ARE one one of the processing MX's. Its
then run through SpamAssassin hoping to do the best we can to
filter out REALLY bad spam, and the box either directly tries
to send to a Yahoo! MX mailer, or forwards to another outbound
box to attempt to send it out. I'm not sure where in that whole
equation we are doing anything that isn't the best we can
except if we assign a person to sit down, read each and every
email, and then forward it along to the destination user. As
it is now, I'm sure we drop some legit mail... And I know
some legit mail isn't getting through since Yahoo! relays aren't
accepting ANYTHING. (And, as a result, even my emails to them
were lagged by days while they stopped accepting anything from
us for a while).
Segregate from our main mail stream? We have this 1
customer (Yes, currently, one) who has this type of setup. They
are on a shared server. I should set up a single box just to
handle their MX? We are a hosting company, the only time
we send mail to Yahoo! otherwise is if one of their customers
fills a webform out that maybe copies them, they are on a
mailing exploder, or we reply to a customer who uses Yahoo!.
Label forwarding IP as a forwarder... We told them,
they told us that our IP was RFC1918 (Which it wasn't)
and that they wouldn't accept that. Once I could convince
them that we weren't using RFC1918 to route, and that our
IP range was Legacy Internic IP's which were perfectly
valid to be routed, they then turned around and found
another excuse.
No, they aren't in the business to teach someone
who's been in the industry all his life, and run
Managed Server Companies for over 11 years... But to
play the We aren't going to tell you why we aren't
accepting your mail, you'll just have to guess and
submit back in *6* months (AND, tell their user
to set up a filter to receive the email {WHEN ITS
IMPOSSIBLE SINCE THE MAIL NEVER MAKES IT}) is just
unbelievable and arrogant to me.
Tuc/TBOH
Re: RIPE is just more fun.
Barrett Lyon wrote: On Fri, Oct 26, 2007 at 03:42:27PM -0400, Leo Bicknell wrote: http://www.youtube.com/watch?v=_y36fG2Oba0 I yanked the mp3 out of the youtube flv: http://blyon.com/routers_died.mp3 -Barrett Better, now we just need a higher quality MP3 from the source :/ -- Michael Greb Linode.com, LLC
re: Any help for forwarding Yahoo! Mail?
On Mon, 2007-10-29 at 13:31 -0400, Tuc at T-B-O-H.NET wrote: No, they aren't in the business to teach someone who's been in the industry all his life, and run Managed Server Companies for over 11 years... Define run... you have piqued my curiosity on this issue. Please only reply to the list, not to From:/Reply-To: AND the list -Jim P.
Re: Any help for forwarding Yahoo! Mail?
On Mon, 29 Oct 2007 14:33:57 EDT, Jim Popovitch said: Please only reply to the list, not to From:/Reply-To: AND the list You could at least have set a Reply-To: so that those people who mindlessly hit 'reply' would have your desired reply destination already filled in. Requesting that people reply a particular way without bothering to specify the RFC-approved way of setting said replies is, at best, impolite. (I'd have nagged in private, but you *did* say reply to the list after all) pgp1bKAJJHQlH.pgp Description: PGP signature
Re: Any help for forwarding Yahoo! Mail?
On Mon, 2007-10-29 at 14:53 -0400, [EMAIL PROTECTED] wrote: On Mon, 29 Oct 2007 14:33:57 EDT, Jim Popovitch said: Please only reply to the list, not to From:/Reply-To: AND the list You could at least have set a Reply-To: so that those people who mindlessly hit 'reply' would have your desired reply destination already filled in. Requesting that people reply a particular way without bothering to specify the RFC-approved way of setting said replies is, at best, impolite. (I'd have nagged in private, but you *did* say reply to the list after all) LOL. From:/Sender: is all you need to worry about Valdis. ;-) I just totally dislike getting list traffic in both my Inbox AND list folder. -Jim P.
RE: Can P2P applications learn to play fair on networks?
There's a large installed based of asymmetric speed internet access links. Considering that even BPON and GPON solutions are designed for asymmetric use, too, it's going to take a fiber-based Active Ethernet solution to transform access links to change the residential experience to something symmetrical. (I'm making the underlying presumption that copper-based symmetric technologies will not become part of residential broadband market any time in the near future, if ever.) Until the time that we are all FTTH, ISPs will continue to manage their customer's upstream links. Regards, Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Donelan Sent: Saturday, October 27, 2007 6:31 PM To: Mohacsi Janos Cc: nanog@merit.edu Subject: Re: Can P2P applications learn to play fair on networks? On Sat, 27 Oct 2007, Mohacsi Janos wrote: Agreed. Measures, like NAT, spoofing based accelerators, quarantining computers are developed for fairly small networks. No for 1Gbps and above and 20+ sites/customers. small is a relative term. Hong Kong is already selling 1Gbps access links to residential customers, and once upon a time 56Kbps was a big backbone network. Last month folks were complaining about ISPs letting everything through the networks, this month people are complaining that ISPs aren't letting everything through the networks. Does this mean next month we will be back the other direction again. Why artificially keep access link speeds low just to prevent upstream network congestion? Why can't you have big access links?
Dynamically Changing Exit Policy (iBGP)
Is there a generally accepted method of automatically altering exit policies within an AS? I'd like to dynamically change from best-exit to a hot potato exit policy when an internal DS3 fails. We fail over to a much lower bandwidth link and would like to avoid sending anything but internal traffic over that link. If it's not already clear, this change needs to happen automatically. I realize that there are two means of accomplishing this: (1) Set a weight on all routes received from the eBGP peer at each location so that it prefers the direct eBGP peer. (2) Sever the iBGP session by tying the iBGP session to an interface IP address rather than a loopback IP. When the DS3 goes down, so will the knowledge of the remote exit point. The devil's in the details however. I can't figure out how to make the weight approach work on routes that were received prior to the circuit failure or how to remove the weights once the circuit comes back up. Severing the iBGP session seems drastic to me, and I'm worried that our advertised routes will be dampened by peers if the internal DS3 starts flapping. Any input from wiser peers would be greatly appreciated. -- Ben Howell
Re: Can P2P applications learn to play fair on networks?
On Thu, 25 Oct 2007 12:50:32 -0400 (EDT) Sean Donelan [EMAIL PROTECTED] wrote: Comcast's network is QOS DSCP enabled, as are many other large provider networks. Enterprise customers use QOS DSCP all the time. However, the net neutrality battles last year made it politically impossible for providers to say they use QOS in their consumer networks. re: http://www.merit.edu/mail.archives/nanog/2005-12/msg00334.html This came up before and I'll ask again, what do you mean by QoS? And what precisely does QoS DSCP really mean here? It's important to know what queueing, dropping, limiting, etc. policies and hardware/buffering capabilities are with the DSCP settings. Otherwise it's just a buzzword on a checklist that might not even actually do anything. I'd also like to hear about monitoring and management capabilities are deployed, that was a real problem last time I checked. How much has really changed? Do you (or if someone on these big nets wants to own up offlist) have pointers to indicate that deployment is significantly different now than they were a couple years ago? Even better, perhaps someone can do a preso at a future meeting on their recent deployment experience? I did one a couple years and I haven't heard of things improving markedly since then, but then I am still recovering from having drunk from that jug of kool-aid. :-) John
Re: Dynamically Changing Exit Policy (iBGP)
On Mon, Oct 29, 2007 at 04:53:50PM -0400, Deepak Jain wrote: You can nail down your announcements to external peers by tying their network blocks to a route-of-last resort on one of your loopbacks. This will prevent flapping externally. Point taken, but it's actually difficult to nail down all of our routes. We have some lone /24's that are not subnetted and thus cannot be used with an 'ip route ... null0' statement. When WAN connectivity drops, the routes flap if we don't have a stable iBGP session. Thus I'd like to steer well clear of severing the iBGP session. The weights can be added/removed automatically by using a route-map on the routes that will be added/removed by the interface going down. Only a single internal /30 route will be removed when an interface goes down. I can't come up with a route-map implementation that would add/remove the weights to the routes already received from our eBGP neighbors. If I'm missing something, please let me know. Normally, however, you wouldn't use iBGP for this and you'd use a heavier, link-aware internal routing protocol like ISIS or OSPF. We use OSPF internally, but it just carries internal infrastructure addresses. I understand that OSPF is link-aware and can carry knowledge of link bandwidth, but I don't see how it would fit into our exit path policies. We accept full routes from our eBGP neighbors and it's not advisable to inject those into OSPF. Our normal policy must be best-exit, which leaves iBGP as the decision-maker unless I'm missing something. Is there a better IGP-based method of choosing a network exit path that would solve these problems? I ask because I'm curious, not because I know the answer. -- Ben Howell Benjamin Howell wrote: Is there a generally accepted method of automatically altering exit policies within an AS? I'd like to dynamically change from best-exit to a hot potato exit policy when an internal DS3 fails. We fail over to a much lower bandwidth link and would like to avoid sending anything but internal traffic over that link. If it's not already clear, this change needs to happen automatically. I realize that there are two means of accomplishing this: (1) Set a weight on all routes received from the eBGP peer at each location so that it prefers the direct eBGP peer. (2) Sever the iBGP session by tying the iBGP session to an interface IP address rather than a loopback IP. When the DS3 goes down, so will the knowledge of the remote exit point. The devil's in the details however. I can't figure out how to make the weight approach work on routes that were received prior to the circuit failure or how to remove the weights once the circuit comes back up. Severing the iBGP session seems drastic to me, and I'm worried that our advertised routes will be dampened by peers if the internal DS3 starts flapping. Any input from wiser peers would be greatly appreciated. -- Ben Howell
Re: Dynamically Changing Exit Policy (iBGP)
Perhaps a drawing of your architecture might make your travails more clear? Benjamin Howell wrote: On Mon, Oct 29, 2007 at 04:53:50PM -0400, Deepak Jain wrote: You can nail down your announcements to external peers by tying their network blocks to a route-of-last resort on one of your loopbacks. This will prevent flapping externally. Point taken, but it's actually difficult to nail down all of our routes. We have some lone /24's that are not subnetted and thus cannot be used with an 'ip route ... null0' statement. When WAN connectivity drops, the routes flap if we don't have a stable iBGP session. Thus I'd like to steer well clear of severing the iBGP session. The weights can be added/removed automatically by using a route-map on the routes that will be added/removed by the interface going down. Only a single internal /30 route will be removed when an interface goes down. I can't come up with a route-map implementation that would add/remove the weights to the routes already received from our eBGP neighbors. If I'm missing something, please let me know. Normally, however, you wouldn't use iBGP for this and you'd use a heavier, link-aware internal routing protocol like ISIS or OSPF. We use OSPF internally, but it just carries internal infrastructure addresses. I understand that OSPF is link-aware and can carry knowledge of link bandwidth, but I don't see how it would fit into our exit path policies. We accept full routes from our eBGP neighbors and it's not advisable to inject those into OSPF. Our normal policy must be best-exit, which leaves iBGP as the decision-maker unless I'm missing something. Is there a better IGP-based method of choosing a network exit path that would solve these problems? I ask because I'm curious, not because I know the answer. -- Ben Howell Benjamin Howell wrote: Is there a generally accepted method of automatically altering exit policies within an AS? I'd like to dynamically change from best-exit to a hot potato exit policy when an internal DS3 fails. We fail over to a much lower bandwidth link and would like to avoid sending anything but internal traffic over that link. If it's not already clear, this change needs to happen automatically. I realize that there are two means of accomplishing this: (1) Set a weight on all routes received from the eBGP peer at each location so that it prefers the direct eBGP peer. (2) Sever the iBGP session by tying the iBGP session to an interface IP address rather than a loopback IP. When the DS3 goes down, so will the knowledge of the remote exit point. The devil's in the details however. I can't figure out how to make the weight approach work on routes that were received prior to the circuit failure or how to remove the weights once the circuit comes back up. Severing the iBGP session seems drastic to me, and I'm worried that our advertised routes will be dampened by peers if the internal DS3 starts flapping. Any input from wiser peers would be greatly appreciated. -- Ben Howell
Re: Any help for Yahoo! Mail arrogance?
On Oct 29, 2007 11:01 PM, Tuc at T-B-O-H.NET [EMAIL PROTECTED] wrote: Fix your forwarding a lot better. Not sure what this means. My machines are MX's for the clients domain. They accept it, and either forward it around locally to one of the processing MX's or ARE one one of the processing MX's. Its Yes, that's just how forwarding and .forwards work. And if you mix inbound email (much dirtier than outbound email even if you run a secure shop) into a mail stream that includes email sent out by your clients, you potentially have random botnet spam, spam from sbl listed spammers etc (in other words, a lot of block on sight stuff) leaking through your IP, the same IP that a bunch of your other customers use to mail out to their aunt mary on yahoo. The numbers from that one .forward are enough to screw up the rest of your numbers, a 5% or less complaint rate on email from your IP (and believe me, if your user is jackass enough to click report spam on email that comes through his .forward the complaints can go up real high) .. is enough to get your IP blocked. Dealing with tier 1 support anywhere (not the least of where is yahoo) is always a pain. Which is why what I am suggesting is avoidance and prevention rather than going around alternatively begging yahoo to fix something or accusing them on nanog of being arrogant. --srs
Re: Any help for Yahoo! Mail arrogance?
On 10/29/07, Tuc at T-B-O-H.NET [EMAIL PROTECTED] wrote: On 10/29/07, Tuc at T-B-O-H.NET [EMAIL PROTECTED] wrote: Unfortunately, we cannot provide you with specific information other than to suggest a review of the questionnaire we supplied and try to determine where your mailing practices may be improved upon. In other words, fix your forwarding a lot better (and possibly segregate it from your main mail stream, clearly label the forwarding IP as a forwarder, etc) Yahoo arent really in the business of teaching people how to do a better job. If that sounds like arrogance .. srs Fix your forwarding a lot better. Not sure what this means. My machines are MX's for the clients domain. What are the addresses of the machines? -M
Re: Dynamically Changing Exit Policy (iBGP)
On Mon, 29 Oct 2007, Benjamin Howell wrote: On Mon, Oct 29, 2007 at 04:53:50PM -0400, Deepak Jain wrote: You can nail down your announcements to external peers by tying their network blocks to a route-of-last resort on one of your loopbacks. This will prevent flapping externally. Point taken, but it's actually difficult to nail down all of our routes. We have some lone /24's that are not subnetted and thus cannot be used with an 'ip route ... null0' statement. When WAN connectivity drops, the routes flap if we don't have a stable iBGP session. Thus I'd like to steer well clear of severing the iBGP session. Not subnetting them doesn't mean you can't ip route a.b.c.d 255.255.255.0 null0 250 while still routing the /24s internally (with lower metric) or having them connected on some interface. Only a single internal /30 route will be removed when an interface goes down. I can't come up with a route-map implementation that would add/remove the weights to the routes already received from our eBGP neighbors. If I'm missing something, please let me know. ... I'd like to dynamically change from best-exit to a hot potato exit policy when an internal DS3 fails. We fail over to a much lower bandwidth link and would like to avoid sending anything but internal traffic over that link. If it's not already clear, this change needs to happen automatically. Are you talking about a single internal DS3, or the more general case of if any of our internal DS3s are down, we need to route differently? If it's a simple case of two DS3 connected routers which are iBGP peers and also have directly connected eBGP peers, could you use route-maps to set ip next-hop on iBGP exchanged external routes (setting the ip next-hop to be the IP of the other end of the internal DS3, with a second IP of an eBGP neighbor interface)? I haven't tried it, but it seems like it might do what you want. (1) Set a weight on all routes received from the eBGP peer at each location so that it prefers the direct eBGP peer. (2) Sever the iBGP session by tying the iBGP session to an interface IP address rather than a loopback IP. When the DS3 goes down, so will the knowledge of the remote exit point. Another possiblility (I've never tried) would be to configure multiple iBGP sessions...one using loopback IPs, the other using the DS3 interface IPs, exchanging internal routes over both sessions, while exchanging external routes over only the second. If the DS3 goes down, the session exchanging external routes dies. I'm not sure you can do this, but I think by having different peer/endpoint IPs (loopbacks for one session, serial interface IPs for the other), it may work. It may be appropriate to move this thread to the *-nsp list appropriate for your brand of routers. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
