SDN Internet Router (sir)

Mailman List Mirror (Read Only)
21

This is not a green grass problem space.

And you could probably envision how you could create your own internal scheme of route reflectors/servers, community tags, probers and updaters to achieve something similar.

Most likely Mike is referring to the sub-optimal result where a large percentage of a router's traffic is taking extra internal hops or worse, maybe even egressing from the AS into a less than optimal path, not because the AS does not have the correct route for the most likely as perceived by BGP optimal path, but that the traffic handling device was not able to be configured to accept any such routes, because doing such statically is not likely to achieve the results and more likely to result in crashed routers one unexpected fine morning.

Nanogers pointed me at this some time back, I think its germaine

RIB/FIB static configuration limitation tip:

Apply the same logic on all similar capacity devices to cut down on the RIBFIB, because thats the best way to minimize loops. And a guaranteed loop free path for the default route. Policy or tag tunnel or whatever.

Joe

Mel Beckman wrote:

22

Mike,

Thanks for that useful example. On a side note, Netflix is a thorn in all our sides :slight_smile: You could put a localpref filter route to override the default for Netflix prefixes, but this impacts resilience. Since you peer with Netflix, I suspect we probably agree that Netflix’s ideas on traffic engineering are pretty one sided.

I think it’s safe to say that BGP, which has scaled amazingly well, didn’t anticipate some of the big gorilla content systems. I don’t really see, though, how injecting FIB entries helps more than other methods. And as others have pointed out, the risk of creating routing loops is significant.

Perhaps it is time to migrate to a new version of BGP. Projects like MBGP and FP-7‘s 4WARD are working on new follow-on routing models, but nothing is on the immediate horizon. I think we all thought we should finish IPv6 migration first :slight_smile:

-mel via cell

23

And here is another interesting approach Ive left open in my browser window for who knows how long

The problem with BGP is that local actors can exact global costs trivially by consuming as many routing slots as they can get away with, add together BGP path decisions and Most Specific traffic-engineering is the goto knob. Sometimes you just want to say this is the route, do not accept any more specifics, unless this route is no longer the route. But you want that done automatically and correctly, reliably.

This is also why all the multi-homing approaches that do not involve global routing havent really taken off in any way to blunt table growth. And likely wont.

See the aggregation factor in the routing report for how bad this is.

There have been lots of BGP protocol and feature updates, but unless your going to uniformly run new systems and enterprise systems that support all of them, its hard to decide to build your entire routing strategy around them.

That BGP unlike EIGRP never tried to tie together performance indicators with routing metrics feature or misdesign, you could debate that but it was always intentional. And opex has pretty much fallen down on the side of against IGP->BGP redistribution of prefixes, let alone performance metrics.

That eBGP prefix has no good reliable way of indicating that an advertised route sucks so bad that you should never attempt to use it unless as last resort, thats why we have AS-paths wrapping screen lines.

"finish IPv6 migration"? Letting IPv6 migration state factor as decision input on anything not directly related to IPv6 migration was never logical, just naively optimistic, and should be stamped out wherever encountered. If its good, use it now and Ipv6 will adopt it as well. If it isnt, why wait to find out?

Joe

Mel Beckman wrote:

24

I love that we can't even get a full week into the new year without beating the "let's overhaul BGP" drum. Some things never change. <3

Chris

25

I don’t understand where the routing loop opportunity comes from. Ideally, you’d take the existing set of available routes and only send on the ones with high traffic levels, not necessarily injecting additional entries beyond what the table had, which would only make the too many routes problem worse. These things happen all of the time, just with different inputs (route reflectors, route servers, etc.). Those use traditional routing metrics. S-flow would just be another metric by which to filter on.

I don’t know how the linked-to projects function in that regard.

26

I didn’t know where the conversation on routing flows differently came from and just ignored it. Now I realize the thread has SDN in the title. SDN can mean many things and if someone didn’t properly evaluate the link in the original post, their understanding could be tainted by their experiences.

27

Christopher Morrow wrote:

Some of the reasoning behind 'i need/want to do SDN things' is 'low fib
device' sort of reasonings.

What?

SDN is a poor alternative for those who can't construct a
network with fully automated QoS guarantee.

Even with SDN, QoS guarantee implies QoS routing requiring
dedicated routing table entry for each flow, which will not
shrink but bloat routing tables regardless of whether you
call it FIB or not.

            Masataka Ohta

28

Thanks for this example.

It sounds like you are describing egress peer engineering, but kinda in reverse.

In ‘traditional’ EPE, the routers have all the routes, and you are using the external controller to perform the performance tests that matter to you, and signal the network where to take the traffic based on those tests.

It seems like you want to do the same thing , but instead of having the controller signal the network where to carry bits, you want the controller to signal the networks what routes are present, and direct the bits that way.

Do I have this right?

29

Christopher Morrow wrote:

Some of the reasoning behind ‘i need/want to do SDN things’ is ‘low fib
device’ sort of reasonings.

What?

SDN is a poor alternative for those who can’t construct a
network with fully automated QoS guarantee.

Even with SDN, QoS guarantee implies QoS routing requiring
dedicated routing table entry for each flow, which will not
shrink but bloat routing tables regardless of whether you
call it FIB or not.

I’m going to have to “what?” you right back there. You don’t need to program each individual flow, just each FEC.

SDN does not imply QoS routing, it’s just one aspect of it. Some use it for classifying guest traffic etc.

M

30

Maybe?

I don’t need any additional performance tests, though. Just watching which prefixes are the top talkers and leaving the rest to default.

I’m not looking at this to do what a BGP optimizier would do and find the best tested path to the top talkers and then massage BGP to get it routed that way. Determine the top talkers, then let BGP do its thing for those top talkers.

I don’t want to manually say X traffic from Y POP manually goes here, but I don’t want to just leave it to default routing either. Something in the middle.

31

Gotcha.

Setup a Quagga/Bird box. Do your top talker analysis , use that box to inject the routes you deem important with communities. On your routers , create policy structure to only take a default plus those communities.

Obviously lots of devils in the details of the implementation , but something like that is all you need to do.

32

Right.

Only I’m not the guy to build that solution.

What I originally linked to (and another link or two contributed since then) seem to be people that already built that solution.

33

What I originally linked to (and another link or two contributed since then) seem to be people that already built that solution.

What’s been shared isn’t the same as what I described. faucet / sir are doing the decision part and the signaling part together.

I am saying separate them. BGP doesn’t know how to make the decision you want, but it does know how to process signals that you send it.

34

Matthew Walster wrote:

SDN does not imply QoS routing,

As long as the shortest path is comfortable enough, no, it
does not have to.

it's just one aspect of it. Some use it for
classifying guest traffic etc.

If special path is provided for guest or otherwise
prioritized traffic, that's QoS routing.

Anyway, prioritization needs more, not less,
routing table entries.

          Masataka Ohta

35

Matthew Walster wrote:

it’s just one aspect of it. Some use it for
classifying guest traffic etc.

If special path is provided for guest or otherwise
prioritized traffic, that’s QoS routing.

No… It’s action based. You can send it a different route, you can replicate it, you can drop it, you can mutate it… You can send it to a different destination for stateful filtering when it doesn’t match an expected pattern!

SDN is not just QoS routing, please stop saying that.

Anyway, prioritization needs more, not less,
routing table entries.

Nope, not true. Had 1000 routes, only 100 available in FIB. So you filter to the top 50 doing traffic and default route the rest of the traffic. Less entries.

M

36

You might want to search for “policy based add-path”, same idea (BGP listener + flow collector), different issue (60M+ entries BGP RIB), all clouds use some version of that, not sure about open sourcing it though

Cheers,

Jeff

37

Matthew Walster wrote:

No... It's action based. You can send it a different route, you can
replicate it, you can drop it, you can mutate it...

Replication is a poor alternative for multicast.

For other actions, why, do you think, they are performed?

Just for fun? Or to differentiate treatment of some packets,
that is, prioritization?

You can send it to a
different destination for stateful filtering when it doesn't match an
expected pattern!

Unless pattern is as simple as having certain port number,
stateful filtering almost always needs all packets including
those matching expected pattern, I'm afraid.

SDN is not just QoS routing, please stop saying that.

See above.

Nope, not true. Had 1000 routes, only 100 available in FIB. So you filter
to the top 50 doing traffic and default route the rest of the traffic. Less
entries.

If default route is acceptable, just rely on it along with
50 non default routes with plain IP routers.

            Masataka Ohta

38

Matthew Walster wrote:

No… It’s action based. You can send it a different route, you can
replicate it, you can drop it, you can mutate it…

Replication is a poor alternative for multicast.

You conveniently ignore things like IDS, port mirroring, things like that.

For other actions, why, do you think, they are performed?

Just for fun? Or to differentiate treatment of some packets,
that is, prioritization?

No. There are far more actions than for prioritisation.

What if you want to make sure certain classes of traffic do not flow over a link, because it is unencrypted and/or sensitive, but you’re happy to send as much TLS wrapped data as you like?

What if you want to sample some flows in an ERSPAN like mechanism?

What if you want to urgently drop a set of flows based on a known DDOS signature?

You can send it to a
different destination for stateful filtering when it doesn’t match an
expected pattern!

Unless pattern is as simple as having certain port number,
stateful filtering almost always needs all packets including
those matching expected pattern, I’m afraid.

Or a certain set of IP addresses. Policy based routing.

SDN is not just QoS routing, please stop saying that.

See above.

Nope, not true. Had 1000 routes, only 100 available in FIB. So you filter
to the top 50 doing traffic and default route the rest of the traffic. Less
entries.

If default route is acceptable, just rely on it along with
50 non default routes with plain IP routers.

That’s what OP is suggesting. That’s what SIR is. Classifying prefixes by traffic and only keeping the ones with the highest volume of traffic, discarding the rest, relying on the default route to infill.

M

39

Matthew Walster wrote:

No... It's action based. You can send it a different route, you can
replicate it, you can drop it, you can mutate it...

Replication is a poor alternative for multicast.

You conveniently ignore things like IDS, port mirroring, things like that.

Wrong. Instead, you conveniently ignore that such forwarding
requires a link between an SDN router and a monitoring device
have the same or larger MTU than an incoming link of the SDN
router, which means the router and the monitoring device must
be tightly coupled effectively to be a single device.

Sometimes, packet loss possibility between them often requires
they must actually be the same device.

No. There are far more actions than for prioritisation.

Just for fun? I'm afraid I already mentioned so.

What if you want to make sure certain classes of traffic do not flow over a
link, because it is unencrypted and/or sensitive, but you're happy to send
as much TLS wrapped data as you like?

You are wrongly assuming TLS wrapped packets can be identified
packet by packet, as I wrote:

>> Unless pattern is as simple as having certain port number,
>> stateful filtering almost always needs all packets including
>> those matching expected pattern, I'm afraid.

So?

What if you want to sample some flows in an ERSPAN like mechanism?

See above for MTU issues.

What if you want to urgently drop a set of flows based on a known DDOS
signature?

Urgently? Even though a DDOS signature is known in advance?

Why?

Unless pattern is as simple as having certain port number,
stateful filtering almost always needs all packets including
those matching expected pattern, I'm afraid.

Or a certain set of IP addresses. Policy based routing.

That's even simpler than port number to be treated by
having or not having proper routing table entries.

If default route is acceptable, just rely on it along with
50 non default routes with plain IP routers.

That's what OP is suggesting.

With plain IP routers?

That's what SIR is. Classifying prefixes by
traffic and only keeping the ones with the highest volume of traffic,
discarding the rest, relying on the default route to infill.

Given the connectionless nature of the Internet, route change based
on volume of traffic averaged over certain period of time is rather
harmful than useful.

              Masataka Ohta

40

From what perspective?

How often do Netflix, Cloudflare, Akamai, Google, etc. change what prefixes they’re using in a given area? (Rhetorical). But I’d imagine it’s not that much. I know one particular geography where you can measure the time between those changes in years. Not all may be so static, but they aren’t THAT variable.