BGP offloading (fixing legacy router BGP scalability issues)
Hello, We've a lot of customers with Cisco 6500 routers (mostly with SUP720 supervisors) in operation. They are very popular with smaller ISPs in Africa/middle east due to their cheap price on the used marked and their fully sufficient routing performance for the given tasks. In practice the biggest problem with them is their poor BGP scalability due to the CPU/memory limitations. We're looking into options for a cheap fix for this problem. The idea is to offload BGP IPv4/IPv6 RIB calculation from the router to a standard server. All BGP sessions will be handled by the server. The server takes care of the RIB calculation and aggregates the result as much as possible (the aggregation potential of the global tables should be very high if it can completely ignore the AS path and only care about the next hop). The final optimized RIB is then pushed to the Router via an iBGP session (the only BGP session configured on the router). If there's room in the transfer net for the server and the router, the setup is simple (eBGP session is established with the server and next-hop is set to the router). In other peering situations the setup might be more challenging. E.g. with typical IXP constrains (only a single MAC address/IP address allowed) the session would have to be a multihop session and an additional static route (host route for the server) on the peer router should be installed. Another way to make the server appear completely transparent for other peers (no special configuration on the peer side) might be NAT for the BGP port to the server or proxy ARP. But we would like to avoid doing NAT with a SUP720 and proxy ARP would make us the default gateway for any incorrectly configured IXP participant router and a configuration error on our side might cause severe harm to the IXP. And of course both ideas won't work for IPv6 (SUP720 doesn't support NAT for IPv6 or proxy NDP). The only solution to make it fully transparent for IPv4 and IPv6 we came up with it is to configure the IXP router interface as unnumbered + static route for the IXP nets + host routes for the assigned IXP IPs to the server. In that case the server would have to monitor the IXP vlan and take care of responding to ARP and Neighbor Solicitation requests for the IXP IPs (using the MAC of the router). Additionally it might be necessary to inject the ARP/IPv6 neighbors into the cisco using static entries (to avoid sending ARP/NS requests with a non IXP IP). We're wondering if anyone has experience with such a setup? Best Regards, Freddy
On Wednesday, April 1, 2015, Frederik Kriewitz <frederik@kriewitz.eu> wrote:
Hello,
We've a lot of customers with Cisco 6500 routers (mostly with SUP720 supervisors) in operation. They are very popular with smaller ISPs in Africa/middle east due to their cheap price on the used marked and their fully sufficient routing performance for the given tasks. In practice the biggest problem with them is their poor BGP scalability due to the CPU/memory limitations.
We're looking into options for a cheap fix for this problem.
The idea is to offload BGP IPv4/IPv6 RIB calculation from the router to a standard server. All BGP sessions will be handled by the server. The server takes care of the RIB calculation and aggregates the result as much as possible (the aggregation potential of the global tables should be very high if it can completely ignore the AS path and only care about the next hop). The final optimized RIB is then pushed to the Router via an iBGP session (the only BGP session configured on the router).
If there's room in the transfer net for the server and the router, the setup is simple (eBGP session is established with the server and next-hop is set to the router).
In other peering situations the setup might be more challenging. E.g. with typical IXP constrains (only a single MAC address/IP address allowed) the session would have to be a multihop session and an additional static route (host route for the server) on the peer router should be installed.
Another way to make the server appear completely transparent for other peers (no special configuration on the peer side) might be NAT for the BGP port to the server or proxy ARP. But we would like to avoid doing NAT with a SUP720 and proxy ARP would make us the default gateway for any incorrectly configured IXP participant router and a configuration error on our side might cause severe harm to the IXP. And of course both ideas won't work for IPv6 (SUP720 doesn't support NAT for IPv6 or proxy NDP).
The only solution to make it fully transparent for IPv4 and IPv6 we came up with it is to configure the IXP router interface as unnumbered + static route for the IXP nets + host routes for the assigned IXP IPs to the server. In that case the server would have to monitor the IXP vlan and take care of responding to ARP and Neighbor Solicitation requests for the IXP IPs (using the MAC of the router). Additionally it might be necessary to inject the ARP/IPv6 neighbors into the cisco using static entries (to avoid sending ARP/NS requests with a non IXP IP).
We're wondering if anyone has experience with such a setup?
Best Regards,
Freddy
Do these use cases really require a full table? Could you get-by with a simple filter Less than or equal to /22 ? Especially applying such a filter to non-local / inter-continental routes? I have done similar for a long time on 7600s, works fine for me (with a default from my upstream) CB
On 1/Apr/15 19:01, Frederik Kriewitz wrote:
We're wondering if anyone has experience with such a setup?
Cisco have a feature called BGP-SD (BGP Selective Download). With BGP-SD, you can hold millions of entries in RAM, but decide what gets downloaded into the FIB. By doing this, you can still export a full BGP table to customers directly connected to your 6500, and only have a 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding to a bigger box. BGP-SD started shipping in IOS XE, but I now understand that the feature is on anything running IOS 15. This would be my recommendation. Mark.
or ignore/block russia and north korea and china network blocks takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not Colin
On 2 Apr 2015, at 07:59, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 1/Apr/15 19:01, Frederik Kriewitz wrote:
We're wondering if anyone has experience with such a setup?
Cisco have a feature called BGP-SD (BGP Selective Download).
With BGP-SD, you can hold millions of entries in RAM, but decide what gets downloaded into the FIB. By doing this, you can still export a full BGP table to customers directly connected to your 6500, and only have a 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding to a bigger box.
BGP-SD started shipping in IOS XE, but I now understand that the feature is on anything running IOS 15.
This would be my recommendation.
Mark.
Do you have data on '100% of the traffic' being bad? I happen to have a large Chinese clientbase, and this is not the case on my network. On 4/2/2015 午後 04:35, Colin Johnston wrote:
or ignore/block russia and north korea and china network blocks takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not
Colin
On 2 Apr 2015, at 07:59, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 1/Apr/15 19:01, Frederik Kriewitz wrote:
We're wondering if anyone has experience with such a setup? Cisco have a feature called BGP-SD (BGP Selective Download).
With BGP-SD, you can hold millions of entries in RAM, but decide what gets downloaded into the FIB. By doing this, you can still export a full BGP table to customers directly connected to your 6500, and only have a 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding to a bigger box.
BGP-SD started shipping in IOS XE, but I now understand that the feature is on anything running IOS 15.
This would be my recommendation.
Mark.
Of course it's not something you should generalise about all people or all traffic from certain countries. But it's obvious that there are some countries which seem to care almost not at all about abuse or maybe even are sources for planned hack-attempts. And at least some large ISPs there seem to do nothing for their reputation or the reputation of their country. Kind regards, Stefan On 04/02/2015 09:40 AM, Paul S. wrote:
Do you have data on '100% of the traffic' being bad?
I happen to have a large Chinese clientbase, and this is not the case on my network.
On 4/2/2015 午後 04:35, Colin Johnston wrote:
or ignore/block russia and north korea and china network blocks takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not
Colin
On 2 Apr 2015, at 07:59, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 1/Apr/15 19:01, Frederik Kriewitz wrote:
We're wondering if anyone has experience with such a setup? Cisco have a feature called BGP-SD (BGP Selective Download).
With BGP-SD, you can hold millions of entries in RAM, but decide what gets downloaded into the FIB. By doing this, you can still export a full BGP table to customers directly connected to your 6500, and only have a 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding to a bigger box.
BGP-SD started shipping in IOS XE, but I now understand that the feature is on anything running IOS 15.
This would be my recommendation.
Mark.
On 2/Apr/15 09:52, Stefan Neufeind wrote:
Of course it's not something you should generalise about all people or all traffic from certain countries. But it's obvious that there are some countries which seem to care almost not at all about abuse or maybe even are sources for planned hack-attempts. And at least some large ISPs there seem to do nothing for their reputation or the reputation of their country.
So when your customer calls you to complain about not being able to reach a random destination in "certain countries", you would tell them that you made a conscious decision to block access to "certain countries" because of reasons the customer probably will never understand or appreciate? You know what Randy says... that... Mark.
On 2 Apr 2015, at 08:57, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 2/Apr/15 09:52, Stefan Neufeind wrote:
Of course it's not something you should generalise about all people or all traffic from certain countries. But it's obvious that there are some countries which seem to care almost not at all about abuse or maybe even are sources for planned hack-attempts. And at least some large ISPs there seem to do nothing for their reputation or the reputation of their country.
So when your customer calls you to complain about not being able to reach a random destination in "certain countries", you would tell them that you made a conscious decision to block access to "certain countries" because of reasons the customer probably will never understand or appreciate?
Open ranges as necessary and mention will will reblock if bad traffic seen. It is called protect what you know is good and allow bad if documented and check if does not cause problems Colin
On 2/Apr/15 10:07, Colin Johnston wrote:
Open ranges as necessary and mention will will reblock if bad traffic seen.
Might be a bit too much work for a customer to figure out when access will be granted or taken away. Would be for me, if I was your customer.
It is called protect what you know is good and allow bad if documented and check if does not cause problems
Fine in you're talking about your internal users on a corporate LAN. But paying customers? Oh well... Don't get me wrong, I appreciate the issue, and when one is thinking about how to save precious FIB resources, blocking "certain countries" comes to mind. I'm just saying, from my point of view, that might not be the best beak to cull. Mark.
Filtering countries is a bad idea, but it is probably possible to create filters so 99% of your actual traffic is handled by a relatively small subset of global routes and the remaining 1% routed via a default route or via a Linux box. Anyone know of tools and methods to do this? How effective is it ( how many routes is necessary to capture 99% of the traffic)? Regards Baldur
David Barroso's (Spotify) SDN Internet Router [0] comes to mind. 0 - https://github.com/dbarrosop/sir On 4/2/2015 午後 07:47, Baldur Norddahl wrote:
Filtering countries is a bad idea, but it is probably possible to create filters so 99% of your actual traffic is handled by a relatively small subset of global routes and the remaining 1% routed via a default route or via a Linux box.
Anyone know of tools and methods to do this? How effective is it ( how many routes is necessary to capture 99% of the traffic)?
Regards
Baldur
On 04/02/2015 09:57 AM, Mark Tinka wrote:
On 2/Apr/15 09:52, Stefan Neufeind wrote:
Of course it's not something you should generalise about all people or all traffic from certain countries. But it's obvious that there are some countries which seem to care almost not at all about abuse or maybe even are sources for planned hack-attempts. And at least some large ISPs there seem to do nothing for their reputation or the reputation of their country.
So when your customer calls you to complain about not being able to reach a random destination in "certain countries", you would tell them that you made a conscious decision to block access to "certain countries" because of reasons the customer probably will never understand or appreciate?
Not fully block / null-route of course. You might however consider to not allow ssh-logins from certain countries (if you know what you're doing) to avoid noise in the logs, might monitor incoming emails with smtp-auth for suspicious activity based on country (of course there can always be someone on holiday in those countries) etc. All I'm saying is that attacks or spam sometimes seem to originate mainly from "certain" countries. Judge for yourself what you maybe want to use that additional piece of information (geo-location) for - and use it wisely. Kind regards, Stefan
On 2/Apr/15 12:34, Stefan Neufeind wrote:
Not fully block / null-route of course. You might however consider to not allow ssh-logins from certain countries (if you know what you're doing) to avoid noise in the logs, might monitor incoming emails with smtp-auth for suspicious activity based on country (of course there can always be someone on holiday in those countries) etc.
All I'm saying is that attacks or spam sometimes seem to originate mainly from "certain" countries. Judge for yourself what you maybe want to use that additional piece of information (geo-location) for - and use it wisely.
Most of the spam I get comes from North America. Go figure. I'm not about to cut access to that continent off. I'd have to consider all other options really exhausted about fixing this for myself before I have to go and fix it in the network in a way that impacts other customers who may be getting spam from non-North American sources, or who enjoy the North American spam... Mark.
Most of the spam I get comes from North America. Go figure. I'm not about to cut access to that continent off.
I'd have to consider all other options really exhausted about fixing this for myself before I have to go and fix it in the network in a way that impacts other customers who may be getting spam from non-North American sources, or who enjoy the North American spam…
It is not spam we are talking about, it is bad invalid network packets, bad web traffic probing exploits, bad port traffic looking for open network ports. All of this originates in countries not using best practice abuse process, no communication with route config errors, no communication when ddos seen. In effect it is a war on bad traffic and country blocks will be in the only way to make people take notice of this problem. Colin
On 2/Apr/15 13:06, Colin Johnston wrote:
It is not spam we are talking about,...
I'm aware - but someone mentioned it, so it deserved it's on post. But having said that...
it is bad invalid network packets, bad web traffic probing exploits, bad port traffic looking for open network ports. All of this originates in countries not using best practice abuse process, no communication with route config errors, no communication when ddos seen. In effect it is a war on bad traffic and country blocks will be in the only way to make people take notice of this problem.
... one man's spam is another man's SSH attacks. So it's really not about the type of traffic, it's about whether blocking it wholesale on a commercial network without thought to what customers think. But as they always say, Your Network, Your Rules. I say, "What Randy says..." Mark.
On Thu, 2 Apr 2015, Mark Tinka wrote:
Most of the spam I get comes from North America. Go figure. I'm not about to cut access to that continent off.
Big difference is that north america is usually responsive to abuse notifications and sometimes has LEO who will listen. china is neither. -Dan
yes, china ignores everything said beit by phone,email,chat at least if you call a us provider you can at least communicate its not a english language issue either chinatelcom,chinanet contact info might as well not be documented colin Sent from my iPhone
On 2 Apr 2015, at 19:05, goemon@anime.net wrote:
On Thu, 2 Apr 2015, Mark Tinka wrote: Most of the spam I get comes from North America. Go figure. I'm not about to cut access to that continent off.
Big difference is that north america is usually responsive to abuse notifications and sometimes has LEO who will listen.
china is neither.
-Dan
The essence of this discussion is IMHO a little...um...trite. Be that as it may how many of you have attempted to contact these providers in Chinese? Or do you all have good reason to believe that is never the problem? On April 2, 2015 at 11:05 goemon@anime.net (goemon@anime.net) wrote:
On Thu, 2 Apr 2015, Mark Tinka wrote:
Most of the spam I get comes from North America. Go figure. I'm not about to cut access to that continent off.
Big difference is that north america is usually responsive to abuse notifications and sometimes has LEO who will listen.
china is neither.
-Dan
-- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
yes have tried chinese language communication as well. none of it works, they dont believe bad traffic is a big issue where it has been proved 100% is bad we do belive this is due to bad abuse practice not informing customers and also deliberately sending bad traffic to test exploits on a large scale. ssl bad cert signing in china is just a example of this culture shutting the door if it is shown unfriendly traffic makes sense to me colin Sent from my iPhone
On 2 Apr 2015, at 20:50, Barry Shein <bzs@world.std.com> wrote:
The essence of this discussion is IMHO a little...um...trite.
Be that as it may how many of you have attempted to contact these providers in Chinese?
Or do you all have good reason to believe that is never the problem?
On April 2, 2015 at 11:05 goemon@anime.net (goemon@anime.net) wrote:
On Thu, 2 Apr 2015, Mark Tinka wrote: Most of the spam I get comes from North America. Go figure. I'm not about to cut access to that continent off.
Big difference is that north america is usually responsive to abuse notifications and sometimes has LEO who will listen.
china is neither.
-Dan
-- -Barry Shein
The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
Sounds there's a need for a higher level of dialogue. Hey, if it can be done with Iran... These are identifiable companies not sub-rosa criminal gangs (as we get with spam) so there ought to be some hope. On April 2, 2015 at 21:10 colinj@gt86car.org.uk (Colin Johnston) wrote:
yes have tried chinese language communication as well. none of it works, they dont believe bad traffic is a big issue where it has been proved 100% is bad we do belive this is due to bad abuse practice not informing customers and also deliberately sending bad traffic to test exploits on a large scale.
ssl bad cert signing in china is just a example of this culture
shutting the door if it is shown unfriendly traffic makes sense to me
colin
Sent from my iPhone
On 2 Apr 2015, at 20:50, Barry Shein <bzs@world.std.com> wrote:
The essence of this discussion is IMHO a little...um...trite.
Be that as it may how many of you have attempted to contact these providers in Chinese?
Or do you all have good reason to believe that is never the problem?
On April 2, 2015 at 11:05 goemon@anime.net (goemon@anime.net) wrote:
On Thu, 2 Apr 2015, Mark Tinka wrote: Most of the spam I get comes from North America. Go figure. I'm not about to cut access to that continent off.
Big difference is that north america is usually responsive to abuse notifications and sometimes has LEO who will listen.
china is neither.
-Dan
-- -Barry Shein
The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
-- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
If you fix that, I think you deserve an award of some kind. You sir, will have won the Internet. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Barry Shein" <bzs@world.std.com> To: "Colin Johnston" <colinj@gt86car.org.uk> Cc: goemon@anime.net, nanog@nanog.org Sent: Thursday, April 2, 2015 3:34:26 PM Subject: Re: BGP offloading (fixing legacy router BGP scalability issues) Sounds there's a need for a higher level of dialogue. Hey, if it can be done with Iran... These are identifiable companies not sub-rosa criminal gangs (as we get with spam) so there ought to be some hope. On April 2, 2015 at 21:10 colinj@gt86car.org.uk (Colin Johnston) wrote:
yes have tried chinese language communication as well. none of it works, they dont believe bad traffic is a big issue where it has been proved 100% is bad we do belive this is due to bad abuse practice not informing customers and also deliberately sending bad traffic to test exploits on a large scale.
ssl bad cert signing in china is just a example of this culture
shutting the door if it is shown unfriendly traffic makes sense to me
colin
Sent from my iPhone
On 2 Apr 2015, at 20:50, Barry Shein <bzs@world.std.com> wrote:
The essence of this discussion is IMHO a little...um...trite.
Be that as it may how many of you have attempted to contact these providers in Chinese?
Or do you all have good reason to believe that is never the problem?
On April 2, 2015 at 11:05 goemon@anime.net (goemon@anime.net) wrote:
On Thu, 2 Apr 2015, Mark Tinka wrote: Most of the spam I get comes from North America. Go figure. I'm not about to cut access to that continent off.
Big difference is that north america is usually responsive to abuse notifications and sometimes has LEO who will listen.
china is neither.
-Dan
-- -Barry Shein
The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
-- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
I, for one, wouldn't mind seeing more dialog regarding the original poster's query ...
On Apr 2, 2015, at 14:53, Barry Shein <bzs@world.std.com> wrote:
The essence of this discussion is IMHO a little...um...trite.
Be that as it may how many of you have attempted to contact these providers in Chinese?
Or do you all have good reason to believe that is never the problem?
On April 2, 2015 at 11:05 goemon@anime.net (goemon@anime.net) wrote:
On Thu, 2 Apr 2015, Mark Tinka wrote: Most of the spam I get comes from North America. Go figure. I'm not about to cut access to that continent off.
Big difference is that north america is usually responsive to abuse notifications and sometimes has LEO who will listen.
china is neither.
-Dan
-- -Barry Shein
The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
emails to the registered contacts bounce, for one, undeliverable. which is a bit of a change from the old chinanet auto-responder which auto-responded to every email with "i cannot find that IP or that IP not by my Control. Please send the correct IP". a number of years back i did have someone contact in chinese and the response was that the customer was doing nothing wrong. -Dan On Thu, 2 Apr 2015, Barry Shein wrote:
The essence of this discussion is IMHO a little...um...trite.
Be that as it may how many of you have attempted to contact these providers in Chinese?
Or do you all have good reason to believe that is never the problem?
On April 2, 2015 at 11:05 goemon@anime.net (goemon@anime.net) wrote:
On Thu, 2 Apr 2015, Mark Tinka wrote:
Most of the spam I get comes from North America. Go figure. I'm not about to cut access to that continent off.
Big difference is that north america is usually responsive to abuse notifications and sometimes has LEO who will listen.
china is neither.
-Dan
-- -Barry Shein
The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On April 2, 2015 at 14:19 goemon@anime.net (goemon@anime.net) wrote:
a number of years back i did have someone contact in chinese and the response was that the customer was doing nothing wrong.
Ok, that's progress of a sort, what's the authoritative source of right and wrong, something beyond "c'mon it's obvious!"? -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
Is port scanning illegal in China? If not the there is no reason for then to do anything about it. On 3 Apr 2015 19:00, "Barry Shein" <bzs@world.std.com> wrote:
On April 2, 2015 at 14:19 goemon@anime.net (goemon@anime.net) wrote:
a number of years back i did have someone contact in chinese and the response was that the customer was doing nothing wrong.
Ok, that's progress of a sort, what's the authoritative source of right and wrong, something beyond "c'mon it's obvious!"?
-- -Barry Shein
The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On April 3, 2015 at 20:22 baconzombie@gmail.com (Bacon Zombie) wrote:
Is port scanning illegal in China?
If not the there is no reason for then to do anything about it.
I don't think that's a minimal standard one has to use, illegal or not. Management of the internet infrastructure is primarily a cooperative, voluntary (in terms of cooperation and communication and agreement to BCPs and standards), and good-faith effort, not just bounded by what is or isn't illegal. As I said before these are companies most probably with many millions of dollars on the table, not miscreants out to cause problems. I suspect if one got them to the table the answers would be a bit more nuanced than "it's not illegal!" even if someone burdened with manning a support desk may have said something like that. All we really know at this point is that flinging emails at their admins hasn't been as effective as one might like. That's not entirely surprising. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
china says not a problem since they have head in sand and ignore cooperation phone contact with chinse folks does not help either colin Sent from my iPhone
On 3 Apr 2015, at 19:51, Barry Shein <bzs@world.std.com> wrote:
On April 3, 2015 at 20:22 baconzombie@gmail.com (Bacon Zombie) wrote: Is port scanning illegal in China?
If not the there is no reason for then to do anything about it.
I don't think that's a minimal standard one has to use, illegal or not.
Management of the internet infrastructure is primarily a cooperative, voluntary (in terms of cooperation and communication and agreement to BCPs and standards), and good-faith effort, not just bounded by what is or isn't illegal.
As I said before these are companies most probably with many millions of dollars on the table, not miscreants out to cause problems.
I suspect if one got them to the table the answers would be a bit more nuanced than "it's not illegal!" even if someone burdened with manning a support desk may have said something like that.
All we really know at this point is that flinging emails at their admins hasn't been as effective as one might like. That's not entirely surprising.
-- -Barry Shein
The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
Gentlemen, be happy .... Roderick Beck Sales Director/Europe and the Americas Hibernia Networks http://www.hibernianetworks.com Budapest and New York 36-30-859-5144 rod.beck@hibernianetworks.com This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment.
Can we please get back to the original topic? So far we have had one interesting and useful suggestion that I've seen -- Paul S. mentioned SIR https://github.com/dbarrosop/sir Have I missed any other solutions other than the prefix length filtering? --Chris
On 2015-04-03 14:18, Chris Boyd wrote:
Can we please get back to the original topic?
So far we have had one interesting and useful suggestion that I've seen -- Paul S. mentioned SIR https://github.com/dbarrosop/sir
Have I missed any other solutions other than the prefix length filtering?
Indeed. OP - How much rack space do you have available, and do you pay for power? There are some decent alternatives to 3BXL, provided these aren't a concern - some better (and larger) than others.
On 04/03/2015 12:18 PM, Chris Boyd wrote:
Can we please get back to the original topic?
Also interested in the original topic.
So far we have had one interesting and useful suggestion that I've seen -- Paul S. mentioned SIR https://github.com/dbarrosop/sir
Have I missed any other solutions other than the prefix length filtering?
Cisco BGP Selective Download was suggested on April 27th: http://seclists.org/nanog/2015/Apr/27 Best regards.
The SIR approach might not work if your switch does not support selective installing routes. Also the switch might have a very slow CPU and be memory constrained, making downloading a large number of routes impractical even if you do not install all. IX and transit providers are making this harder that it needs to be. Just allow two IP and MAC addresses on the peering network. Then you can just have a server running BIRD directly on the peering network using next hop attribute to redirect traffic through the switch. Actually I believe Cogent offers /29 on the peering link so you can do exactly that. Regards Baldur Den 03/04/2015 21.19 skrev "Chris Boyd" <cboyd@gizmopartners.com>:
Can we please get back to the original topic?
So far we have had one interesting and useful suggestion that I've seen -- Paul S. mentioned SIR https://github.com/dbarrosop/sir
Have I missed any other solutions other than the prefix length filtering?
--Chris
portscanning on mass scale where unable to get knowledgable network/sysadmins to fix gets to the point of every part of large network ranges are affected. then country blocks make sense to protect countries from armies of exploited machines and protect valuable costly network resource colin Sent from my iPhone
On 3 Apr 2015, at 19:22, Bacon Zombie <baconzombie@gmail.com> wrote:
Is port scanning illegal in China?
If not the there is no reason for then to do anything about it.
On 3 Apr 2015 19:00, "Barry Shein" <bzs@world.std.com> wrote:
On April 2, 2015 at 14:19 goemon@anime.net (goemon@anime.net) wrote: a number of years back i did have someone contact in chinese and the response was that the customer was doing nothing wrong.
Ok, that's progress of a sort, what's the authoritative source of right and wrong, something beyond "c'mon it's obvious!"?
-- -Barry Shein
The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On Fri, 3 Apr 2015, Barry Shein wrote:
On April 2, 2015 at 14:19 goemon@anime.net (goemon@anime.net) wrote:
a number of years back i did have someone contact in chinese and the response was that the customer was doing nothing wrong. Ok, that's progress of a sort, what's the authoritative source of right and wrong, something beyond "c'mon it's obvious!"?
in their case the excuse was 1) they are a paying customer (thus can do no wrong) 2) they were breaking no chinese law (attacking US hosts) -Dan
On Fri, 03 Apr 2015 13:08:40 -0700, goemon@anime.net said:
On Fri, 3 Apr 2015, Barry Shein wrote:
On April 2, 2015 at 14:19 goemon@anime.net (goemon@anime.net) wrote:
a number of years back i did have someone contact in chinese and the response was that the customer was doing nothing wrong. Ok, that's progress of a sort, what's the authoritative source of right and wrong, something beyond "c'mon it's obvious!"?
in their case the excuse was 1) they are a paying customer (thus can do no wrong) 2) they were breaking no chinese law (attacking US hosts)
And a moment's thought shows that attitude, while not very neighborly, is an economically sound one - he maximizes his profit by doing nothing about it. Actually taking action results in the costs of taking action *plus* the possibility of losing that customer's revenue. Unless you demonstrate that his total profit actually increases by dealing with the miscreants, he has no reason to do so. We've been down this road before - we've had our own problems on this side of the puddle with transit providers who refused to deal with problem customers because the provider billed by the packet, and the customers were good about paying their bill - so dealing with the problem caused less packets and thus less revenue. (The real problem here is, of course, that the *cost* of the abuse is an externality born by somebody other than the provider who's enabling the bad behavior...
On Fri, 3 Apr 2015, Valdis.Kletnieks@vt.edu wrote:
We've been down this road before - we've had our own problems on this side of the puddle with transit providers who refused to deal with problem customers because the provider billed by the packet, and the customers were good about paying their bill - so dealing with the problem caused less packets and thus less revenue.
At least in the US the provider could be charged with willful negligence and face liability. But in most cases RBL is enough pressure to get the US providers to do the right thing. -Dan
In article <Pine.LNX.4.64.1504061101030.24610@sasami.anime.net> you write:
On Fri, 3 Apr 2015, Valdis.Kletnieks@vt.edu wrote:
We've been down this road before - we've had our own problems on this side of the puddle with transit providers who refused to deal with problem customers because the provider billed by the packet, and the customers were good about paying their bill - so dealing with the problem caused less packets and thus less revenue.
At least in the US the provider could be charged with willful negligence and face liability.
Please provide legal citations. R's, John
On Mon, 6 Apr 2015, John Levine wrote:
In article <Pine.LNX.4.64.1504061101030.24610@sasami.anime.net> you write:
On Fri, 3 Apr 2015, Valdis.Kletnieks@vt.edu wrote:
We've been down this road before - we've had our own problems on this side of the puddle with transit providers who refused to deal with problem customers because the provider billed by the packet, and the customers were good about paying their bill - so dealing with the problem caused less packets and thus less revenue. At least in the US the provider could be charged with willful negligence and face liability. Please provide legal citations.
ignore a dmca takedown request, see what happens. -Dan
On Mon, Apr 6, 2015 at 2:51 PM, John Levine <johnl@iecc.com> wrote:
In article <Pine.LNX.4.64.1504061101030.24610@sasami.anime.net> you write:
At least in the US the provider could be charged with willful negligence and face liability.
Please provide legal citations.
http://www.americanbar.org/newsletter/publications/gp_solo_magazine_home/gp_... https://www.ftc.gov/news-events/press-releases/2009/06/ftc-shuts-down-notori... It happens. Not often enough. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
http://www.americanbar.org/newsletter/publications/gp_solo_magazine_home/gp_...
Nothing there about ISP liability other than noting the third-party immunity from the CDA.
https://www.ftc.gov/news-events/press-releases/2009/06/ftc-shuts-down-notori...
Well, yeah, they were actively running a crimeware service. "Don't do that."
On 2 Apr 2015, at 08:40, Paul S. <contact@winterei.se> wrote:
Do you have data on '100% of the traffic' being bad?
as a example anything in 163data.com.cn is bad Colin
I happen to have a large Chinese clientbase, and this is not the case on my network.
On 4/2/2015 午後 04:35, Colin Johnston wrote:
or ignore/block russia and north korea and china network blocks takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not
Colin
On 2 Apr 2015, at 07:59, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 1/Apr/15 19:01, Frederik Kriewitz wrote:
We're wondering if anyone has experience with such a setup? Cisco have a feature called BGP-SD (BGP Selective Download).
With BGP-SD, you can hold millions of entries in RAM, but decide what gets downloaded into the FIB. By doing this, you can still export a full BGP table to customers directly connected to your 6500, and only have a 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding to a bigger box.
BGP-SD started shipping in IOS XE, but I now understand that the feature is on anything running IOS 15.
This would be my recommendation.
Mark.
163data is announced as Chinanet, a China Telecom brand. Dropping 4134 (http://bgp.he.net/AS4134) globally will get my customers up at my doors with pitchforks fairly fast, I dunno about yours.... Simply too big to do anything that drastic against. On 4/2/2015 午後 05:04, Colin Johnston wrote:
On 2 Apr 2015, at 08:40, Paul S. <contact@winterei.se> wrote:
Do you have data on '100% of the traffic' being bad?
as a example anything in 163data.com.cn is bad
Colin
I happen to have a large Chinese clientbase, and this is not the case on my network.
On 4/2/2015 午後 04:35, Colin Johnston wrote:
or ignore/block russia and north korea and china network blocks takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not
Colin
On 2 Apr 2015, at 07:59, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 1/Apr/15 19:01, Frederik Kriewitz wrote:
We're wondering if anyone has experience with such a setup? Cisco have a feature called BGP-SD (BGP Selective Download).
With BGP-SD, you can hold millions of entries in RAM, but decide what gets downloaded into the FIB. By doing this, you can still export a full BGP table to customers directly connected to your 6500, and only have a 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding to a bigger box.
BGP-SD started shipping in IOS XE, but I now understand that the feature is on anything running IOS 15.
This would be my recommendation.
Mark.
You would be surprised at the good effect and bandwidth incoming/outgoing gained. allow blocks on exception and document and check. drastic action done due to unresponsive contacts and 100% bad traffic Colin
On 2 Apr 2015, at 09:06, Paul S. <contact@winterei.se> wrote:
163data is announced as Chinanet, a China Telecom brand.
Dropping 4134 (http://bgp.he.net/AS4134) globally will get my customers up at my doors with pitchforks fairly fast, I dunno about yours....
Simply too big to do anything that drastic against.
On 4/2/2015 午後 05:04, Colin Johnston wrote:
On 2 Apr 2015, at 08:40, Paul S. <contact@winterei.se> wrote:
Do you have data on '100% of the traffic' being bad?
as a example anything in 163data.com.cn is bad
Colin
I happen to have a large Chinese clientbase, and this is not the case on my network.
On 4/2/2015 午後 04:35, Colin Johnston wrote:
or ignore/block russia and north korea and china network blocks takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not
Colin
On 2 Apr 2015, at 07:59, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 1/Apr/15 19:01, Frederik Kriewitz wrote:
We're wondering if anyone has experience with such a setup? Cisco have a feature called BGP-SD (BGP Selective Download).
With BGP-SD, you can hold millions of entries in RAM, but decide what gets downloaded into the FIB. By doing this, you can still export a full BGP table to customers directly connected to your 6500, and only have a 0/0 + ::/0 (and some more customer routes) in the FIB to do forwarding to a bigger box.
BGP-SD started shipping in IOS XE, but I now understand that the feature is on anything running IOS 15.
This would be my recommendation.
Mark.
On 2/Apr/15 09:35, Colin Johnston wrote:
or ignore/block russia and north korea and china network blocks takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not
I think that's a little extreme, especially since customers are paying me to deliver packets to the whole Internet. But that's just me... Mark.
customers are paying for good traffic to generate eye balls and revenue, not bad traffic which clouds the good work done. I know we are getting into filtering traffic wars here but if the source admins refuse to respond, refuse to cooperate, then if 100% of the traffic is bad then why not put up walls. I would like country trade talks to get down to the technical point that there are some fundamental problems being seen with bad traffic usage and it is significant percentage of waste bandwidth. Colin
On 2 Apr 2015, at 08:42, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 2/Apr/15 09:35, Colin Johnston wrote:
or ignore/block russia and north korea and china network blocks takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not
I think that's a little extreme, especially since customers are paying me to deliver packets to the whole Internet.
But that's just me...
Mark.
On 2/Apr/15 10:00, Colin Johnston wrote:
customers are paying for good traffic to generate eye balls and revenue, not bad traffic which clouds the good work done. I know we are getting into filtering traffic wars here but if the source admins refuse to respond, refuse to cooperate, then if 100% of the traffic is bad then why not put up walls.
I would like country trade talks to get down to the technical point that there are some fundamental problems being seen with bad traffic usage and it is significant percentage of waste bandwidth.
The traffic may very well be bad, but my point is that is a point of view - one which may differ between you and your customer; never mind between you and your peers. Mark.
customers are paying for good traffic to generate eye balls and revenue, not bad traffic which clouds the good work done. I know we are getting into filtering traffic wars here but if the source admins refuse to respond, refuse to cooperate, then if 100% of the traffic is bad then why not put up walls. I would like country trade talks to get down to the technical point that there are some fundamental problems being seen with bad traffic usage and it is significant percentage of waste bandwidth. Colin
On 2 Apr 2015, at 08:42, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 2/Apr/15 09:35, Colin Johnston wrote: or ignore/block russia and north korea and china network blocks takes away 5% of network ranges for memory headroom, especially the large number of smaller china blocks. Some may say this is harsh but is the network contacts refuse to co-operate with abuse and 100% of the traffic is bad then why not
I think that's a little extreme, especially since customers are paying me to deliver packets to the whole Internet.
But that's just me...
Mark.
As a network consumer and network provider. The traffic seen by the customer should not be censored. It should be up to the consumer to protect their services. I accept the risk and want uncensored internet access and provide such to our customers. On Apr 2, 2015 11:26 AM, "Max Tulyev" <maxtul@netassist.ua> wrote:
Hello!
Very good idea is to sell that and change it to softrouter based on PC/Linux/BIRD. Config can work like 6500/SUP750 will cost much less than $1k.
On 04/01/15 20:01, Frederik Kriewitz wrote:
We're wondering if anyone has experience with such a setup?
How do you see this as a 'censoring' activity ? If the Op has a default route on their side, along with the reduced route table, at best you have less than optimal routing... Regards Faisal Imtiaz Snappy Internet & Telecom ----- Original Message -----
From: "Bryan Tong" <contact@nullivex.com> To: "Max Tulyev" <maxtul@netassist.ua> Cc: nanog@nanog.org Sent: Thursday, April 2, 2015 2:01:30 PM Subject: Re: BGP offloading (fixing legacy router BGP scalability issues)
As a network consumer and network provider. The traffic seen by the customer should not be censored. It should be up to the consumer to protect their services.
I accept the risk and want uncensored internet access and provide such to our customers. On Apr 2, 2015 11:26 AM, "Max Tulyev" <maxtul@netassist.ua> wrote:
Hello!
Very good idea is to sell that and change it to softrouter based on PC/Linux/BIRD. Config can work like 6500/SUP750 will cost much less than $1k.
On 04/01/15 20:01, Frederik Kriewitz wrote:
We're wondering if anyone has experience with such a setup?
it is not censorship to check traffic follows correct standards and does not deliberately constantly try to exploit. it could easily be solved if china abuse departments co-operate and acknowledge reports and fix if not then country bans are in place and will remain in place until culture change is done colin Sent from my iPhone
On 2 Apr 2015, at 19:01, Bryan Tong <contact@nullivex.com> wrote:
As a network consumer and network provider. The traffic seen by the customer should not be censored. It should be up to the consumer to protect their services.
I accept the risk and want uncensored internet access and provide such to our customers.
On Apr 2, 2015 11:26 AM, "Max Tulyev" <maxtul@netassist.ua> wrote:
Hello!
Very good idea is to sell that and change it to softrouter based on PC/Linux/BIRD. Config can work like 6500/SUP750 will cost much less than $1k.
On 04/01/15 20:01, Frederik Kriewitz wrote: We're wondering if anyone has experience with such a setup?
On Wed, Apr 1, 2015 at 1:01 PM, Frederik Kriewitz <frederik@kriewitz.eu> wrote:
In practice the biggest problem with [Cisco 6500s] is their poor BGP scalability due to the CPU/memory limitations.
Hi Frederik: Are you sure about that? I would expect you to hit the wall on the TCAM long before CPU/RAM limitations. Check your log for errors along the lines of "FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched." This might be masked as a CPU problem since routing for destinations which fall out of the TCAM is forced up to the main CPU. If this is your problem and you're talking about sup-720-3bxl's with a 1M TCAM, you can change how much of the TCAM is allocated to which functions for now. Longer term, you either upgrade to something with a bigger TCAM or you reduce the number of routes you carry by introducing superset routes such as a default route and then filtering out the more-specifics your customers are least likely to use. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Thank you very much for all your responses. First of all, the problems we see are really RIB (Processor memory) and CPU related. The TCAM/FIB limits are properly configured. From the FIB capacity view they should last a couple of more years. Software routing doesn't cause the problem. The most extreme case of Cisco 6500/SUP720 abuse I'm aware of is a setup with 4 full table transit connections + 2 RR sessions + ~20 peerings, no downstreams. Besides the IPv4 and IPv6 peerings it's pretty much only handling a small amount of OSPF and MPLS (<5k prefixes ~500 routers). No netflow or any other memory hog. Under normal condition it's running at 20% CPU and 90% processor memory (1G/SUP720 XL). In case a session with a lot of prefixes (e.g. a transit) fails, it takes up to 5 minutes for the BGP Router process to recompute the RIB, etc.. During that time it's running at 100% CPU. Low priority processes are completely ignored (e.g. SNMP based monitoring stops working). Occasionally it even drops OSPF neighbours or other BGP sessions due to expired hold timers causing further havoc. I had a look at David Barroso's SDN Internet Router project. While it's definitely a very interesting project it focuses on FIB limitations, in our case the RIB is the problem. Using netflow and traffic stats as additional metric is something I'm missing from today's routers too (not to work around FIB limits but to allow more intelligent load balancing/avoid congested ports). Applying a /22 filter was suggested. In order to actually safe the RIB memory we would have to disable soft-reconfiguration on the corresponding sessions. I don't like that option for various reasons as it trades less memory usage for longer convergence times and significant bigger impacts on route map updates. Due to the IPv4 exhaustion we expect to see more small prefixes in the future which can't be aggregated (considering the AS path). Simply dropping them would result in less optimal routing. Having a hardware router with just a small subset of routes to handle most of the traffic and send remaining traffic via a default route to a software router with a full table is a different approach to FIB limits. It shares similar problems as mentioned in the original post (how to make two routers appear as one, ...). On the edge towards the end customers we already make heavy use of Linux routers based on standard servers. While we would love to replace all hardware routers with feature rich software routers we still consider them necessary towards the internet facing edge in order to allow us the mitigation certain (D)DoS attacks. Dropping entire ASs is not an option as already discussed here. Another suggestion was to use OpenFlow PacketIn/Out messages to inject/extract the BGP packets. That probably would be a nice way to do it but unfortunately legacy routers typically don't support OpenFlow. The Cisco 6500/SUP720 is no exception. I'll probably will setup a small test environment to see if this actually works as expected. Best Regards, Freddy
Hi Frederik,
On 09 Apr 2015, at 13:24, Frederik Kriewitz <frederik@kriewitz.eu> wrote:
Thank you very much for all your responses.
First of all, the problems we see are really RIB (Processor memory) and CPU related. The TCAM/FIB limits are properly configured. From the FIB capacity view they should last a couple of more years. Software routing doesn't cause the problem. The most extreme case of Cisco 6500/SUP720 abuse I'm aware of is a setup with 4 full table transit connections + 2 RR sessions + ~20 peerings, no downstreams. Besides the IPv4 and IPv6 peerings it's pretty much only handling a small amount of OSPF and MPLS (<5k prefixes ~500 routers). No netflow or any other memory hog. Under normal condition it's running at 20% CPU and 90% processor memory (1G/SUP720 XL).
The main limit here apart from the rather slow CPU for RP is the amount of memory you can have. I’d setup a CSR1000v as RR and offload the 6500 from the control-plane completely. It’s nice box to do very fast hardware forwarding as long as the FIB fits in the TCAMs, which it seems it does in your scenario.
In case a session with a lot of prefixes (e.g. a transit) fails, it takes up to 5 minutes for the BGP Router process to recompute the RIB, etc.. During that time it's running at 100% CPU. Low priority processes are completely ignored (e.g. SNMP based monitoring stops working). Occasionally it even drops OSPF neighbours or other BGP sessions due to expired hold timers causing further havoc.
You can tune this with process time tweaks.
Applying a /22 filter was suggested. In order to actually safe the RIB memory we would have to disable soft-reconfiguration on the corresponding sessions. I don't like that option for various reasons as it trades less memory usage for longer convergence times and significant bigger impacts on route map updates. Due to the IPv4 exhaustion we expect to see more small prefixes in the future which can't be aggregated (considering the AS path). Simply dropping them would result in less optimal routing.
If you have to filter somewhere on something, I’d rather try to filter by AS_PATH (neighbors, etc) than prefix lengths. -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski@jabber.org about." John von Neumann | http://lukasz.bromirski.net
Freddy, did you get your test up ? I too am facing the same BGP scalability constraints as you are, and the only real viable solution seems to be filtering. <snip> I'll probably will setup a small test environment to see if this actually works as expected. Best Regards, Freddy
On Mon, May 11, 2015 at 8:38 PM, Chaim Rieger <chaim.rieger@gmail.com> wrote:
Freddy, did you get your test up ?
Finally had some time to setup a lab environment and do some basic testing regarding the fully transparent approach mentioned in the initial email. My biggest concern was that the cisco wouldn't like packets with it's own MAC source address. But luckily it's dumb enough to just forward them. Hacked together a small scapy program to implement "selective proxy ARP/NDP spoofing". It's working perfectly fine in my lab setup. As it turns out a quick reality check on our peering ports shows that most BGP implementations are correctly setting TTL to 1 for ebgp sessions by default. That of course breaks my initial plan to just route the BGP packets to the server (cisco will drop them due to TTL expiration). Using a vlan access-map it might be possible to redirect the packets to another interface to fix that. The worst case solution for that should be a RSPAN session with corresponding filter. Essentially all the bricks are there, they just need to be assembled. Best Regards, Freddy
participants (25)
-
Bacon Zombie -
Baldur Norddahl -
Barry Shein -
Bryan Holloway -
Bryan Tong -
Ca By -
Chaim Rieger -
Chris Boyd -
Colin Baker -
Colin Johnston -
Faisal Imtiaz -
Frederik Kriewitz -
goemon＠anime.net -
John Levine -
John R. Levine
-
Mark Tinka -
Max Tulyev -
Mike Hammett -
Octavio Alvarez -
Paul S. -
Rod Beck -
Stefan Neufeind -
Valdis.Kletnieks＠vt.edu -
William Herrin -
Łukasz Bromirski