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?
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.
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
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?
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.
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.
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.
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)?
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...
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.
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.