Archive

Archive for July, 2014

The New CCNP – Combining Exams

July 30, 2014 2 comments

The new CCNP RS was just released. The last day to test with the old exams is
January 29, 2015.

What is usually seen is that people start to panic, they want to complete the
old exams before they are removed. There is no reason to panic though, you can
mix and match the old exams and the new exams. If you have taken the old
ROUTE and SWITCH, you can take the new TSHOOT and become a CCNP. If you have
the old SWITCH, you can take the new ROUTE and TSHOOT and become a CCNP.

All the valid combinations are available through a comparison tool from Cisco.

Which exams should you take? This depends on how far you are into your studies
and what your future plans are. If you plan to take the CCIE, the new ROUTE looks like
a good stepping stone to me. If you want to finish as quickly as possible, then take
the old exams. As mentioned above, if you don’t complete all three in time, you can take
one of the new ones to round off the CCNP.

Good luck to all the CCNP candidates out there!

Advertisements

CCNP RS Version 2

July 29, 2014 21 comments

I woke up to the news that CCNP RS Version 2 is now live. As usual, there is no
reason to panic. If you have been studying for the old version, nothing has been
wasted. OSPF is still OSPF, EIGRP is still EIGRP. The new exams are:

Implementing Cisco IP Routing (300-101)
Implementing Cisco IP Switched Networks (300-115)
Troubleshooting and Maintaining Cisco IP Networks (300-135)

The last day to take the old exams will be January 29, 2015.

The good news with the new blueprint is that Cisco is doing what they have been
for a while now, producing more detailed blueprints on what to study. There is also
a weighting included, which shows how much weight each section holds of the entire exam.

Implementing Cisco IP Routing (300-101)

This is the new version of the ROUTE exam. The old version was 642-902. The
new blueprint is here.

The routing protocols are still there, as expected. Let’s go through the blueprint to
see what has been added or clarified from the old blueprint.

1.0 Network Principles 10%

1.1 Identify Cisco Express Forwarding concepts
1.1.a FIB
1.1.b Adjacency table
1.2 Explain general network challenges
1.2.a Unicast
1.2.b Out-of-order packets
1.2.c Asymmetric routing
1.3 Describe IP operations
1.3.a ICMP Unreachable and Redirects
1.3.b IPv4 and IPv6 fragmentation
1.3.c TTL
1.4 Explain TCP operations
1.4.a IPv4 and IPv6 (P)MTU
1.4.b MSS
1.4.c Latency
1.4.d Windowing
1.4.e Bandwidth-delay product
1.4.f Global synchronization
1.5 Describe UDP operations
1.5.a Starvation
1.5.b Latency
1.6 Recognize proposed changes to the network
1.6.a Changes to routing protocol parameters
1.6.b Migrate parts of the network to IPv6
1.6.c Routing protocol migration

This section seems entirely new to me. Although it would have been expected by a CCNP
candidate to know about TTL, CEF and MTU, Cisco is now making it clear that you must
know these concepts. This is great that topics like these are now specifically mentioned
in the blueprint.

The above concepts are all very important and we can also see that
IPv6 is getting more and more attention. Asymmetric routing, MSS, BDP, latency are all
important concepts that you will surely run into in a role as a network engineer.

2.0 Layer 2 Technologies 10%

2.1 Configure and verify PPP
2.1.a Authentication (PAP, CHAP)
2.1.b PPPoE (client side only)
2.2 Explain Frame Relay
2.2.a Operations
2.2.b Point-to-point
2.2.c Multipoint

This is also not really new but Cisco now includes them in the blueprint.
Frame relay is still there, which may seem surprising. However, it says explain Frame Relay,
so it seems only the concepts should be known and not the configuration.
This does make sense in a way because Frame Relay concepts are similar to MPLS, DMVPN etc.

3.0 Layer 3 Technologies 40%

3.1 Identify, configure, and verify IPv4 addressing and subnetting
3.1.a Address types (Unicast, broadcast, multicast, and VLSM)
3.1.b ARP
3.1.c DHCP relay and server
3.1.d DHCP protocol operations
3.2 Identify IPv6 addressing and subnetting
3.2.a Unicast
3.2.b EUI-64
3.2.c ND, RS/RA
3.2.d Autoconfig (SLAAC)
3.2.e DHCP relay and server
3.2.f DHCP protocol operations
3.3 Configure and verify static routing
3.4 Configure and verify default routing
3.5 Evaluate routing protocol types
3.5.a Distance vector
3.5.b Link state
3.5.c Path vector
3.6 Describe administrative distance
3.7 Troubleshoot passive interfaces
3.8 Configure and verify VRF lite
3.9 Configure and verify filtering with any protocol
3.10 Configure and verify redistribution between any routing protocols or routing sources
3.11 Configure and verify manual and autosummarization with any routing protocol
3.12 Configure and verify policy-based routing
3.13 Identify suboptimal routing
3.14 Explain ROUTE maps
3.15 Configure and verify loop prevention mechanisms
3.15.a Route tagging and filtering
3.15.b Split-horizon
3.15.c Route poisoning
3.16 Configure and verify RIPv2
3.17 Describe RIPng
3.18 Describe EIGRP packet types
3.19 Configure and verify EIGRP neighbor relationship and authentication
3.20 Configure and verify EIGRP stubs
3.21 Configure and verify EIGRP load balancing
3.21.a Equal cost
3.21.b Unequal cost
3.22 Describe and optimize EIGRP metrics
3.23 Configure and verify EIGRP for IPv6
3.24 Describe OSPF packet types
3.25 Configure and verify OSPF neighbor relationship and authentication
3.26 Configure and verify network types, area types, and router types
3.26.a Point-to-point, multipoint, broadcast, nonbroadcast
3.26.b LSA types, area type: backbone, normal, transit, stub, NSSA, totally stub
3.26.c Internal router, backbone router, ABR, ASBR
3.26.d Virtual link
3.27 Configure and verify OSPF path preference
3.28 Configure and verify OSPF operations
3.29 Configure and verify OSPF for IPv6
3.30 Describe, configure, and verify BGP peer relationships and authentication
3.30.a Peer group
3.30.b Active, passive
3.30.c States and timers
3.31 Configure and verify eBGP (IPv4 and IPv6 address families)
3.31.a eBGP
3.31.b 4-byte AS number
3.31.c Private AS
3.32 Explain BGP attributes and best-path selection

This is the meat of the exam, as expected from a ROUTE exam. What stands out is that
the blueprint holds much more detail. Things like ARP, DHCP and address types were
not specific items on the old blueprint. We also see a continued focus on IPv6 where
v6 is now included for BGP as well. A CCNP candidate now also needs to understand 4 byte
AS numbers and private AS, which is good for real life networks.

We have a very detailed blueprint which is good. Topics like route-maps and tagging are
now specific items. It’s clear that a CCNP candidate must know routing very well to pass
the ROUTE exam. A new topic is VRF lite, this is a good addition and something that is
very common in todays networks.

4.0 VPN Technologies 10%

4.1 Configure and verify GRE
4.2 Describe DMVPN (single hub)
4.3 Describe Easy Virtual Networking (EVN)

GRE was already there, so that is not new. The topics of DMVPN and EVN has been added.
DMVPN is getting more and more common, so that is a good addition. I haven’t seen
much EVN so far but it’s still a concept you should at least have heard of.

5.0 Infrastructure Security 10%

5.1 Describe IOS AAA using local database
5.2 Describe device security using IOS AAA with TACACS+ and RADIUS
5.2.a AAA with TACACS+ and RADIUS
5.2.b Local privilege authorization fallback
5.3 Configure and verify device access control
5.3.a Lines (VTY, AUX, console)
5.3.b Management plane protection
5.3.c Password encryption
5.4 Configure and verify router security features
5.4.a IPv4 access control lists (standard, extended, time-based)
5.4.b IPv6 traffic filter
5.4.c Unicast reverse path forwarding

I don’t see the above topics as new, it’s good that they are now included in the
blueprint though. These are all topics one needs to know for a CCNP level network
engineer.

6.0 Infrastructure Services 10%

6.1 Configure and verify device management
6.1.a Console and VTY
6.1.b Telnet, HTTP, HTTPS, SSH, SCP
6.1.c (T)FTP
6.2 Configure and verify SNMP
6.2.a v2
6.2.b v3
6.3 Configure and verify logging
6.3.a Local logging, syslog, debugs, conditional debugs
6.3.b Timestamps
6.4 Configure and verify Network Time Protocol (NTP)
6.4.a NTP master, client, version 3, version 4
6.4.b NTP authentication
6.5 Configure and verify IPv4 and IPv6 DHCP
6.5.a DHCP client, IOS DHCP server, DHCP relay
6.5.b DHCP options (describe)
6.6 Configure and verify IPv4 Network Address Translation (NAT)
6.6.a Static NAT, dynamic NAT, PAT
6.7 Describe IPv6 NAT
6.7.a NAT64
6.7.b NPTv6
6.8 Describe SLA architecture
6.9 Configure and verify IP SLA
6.9.a ICMP
6.10 Configure and verify tracking objects
6.10.a Tracking objects
6.10.b Tracking different entities (for example, interfaces, IPSLA results)
6.11 Configure and verify Cisco NetFlow
6.11.a NetFlow v5, v9
6.11.b Local retrieval
6.11.c Export (configuration only)

Most of the topics here should be familiar. NAT between IPv4 and IPv6 has been added.
This will be something that will be used, whether we like it or not. It’s good to see
that IP SLA and NTP being included. Also, CCNP candidates must now know Netflow.

Implementing Cisco IP Switched Networks (300-115)

This is the new version of the SWITCH exam. The old version was 642-813. The
new blueprint is here.

1.0 Layer 2 Technologies 65%

1.1 Configure and verify switch administration
1.1.a SDM templates
1.1.b Managing MAC address table
1.1.c Troubleshoot Err-disable recovery
1.2 Configure and verify Layer 2 protocols
1.2.a CDP, LLDP
1.2.b UDLD
1.3 Configure and verify VLANs
1.3.a Access ports
1.3.b VLAN database
1.3.c Normal, extended VLAN, voice VLAN
1.4 Configure and verify trunking
1.4.a VTPv1, VTPv2, VTPv3, VTP pruning
1.4.b dot1Q
1.4.c Native VLAN
1.4.d Manual pruning
1.5 Configure and verify EtherChannels
1.5.a LACP, PAgP, manual
1.5.b Layer 2, Layer 3
1.5.c Load balancing
1.5.d EtherChannel misconfiguration guard
1.6 Configure and verify spanning tree
1.6.a PVST+, RPVST+, MST
1.6.b Switch priority, port priority, path cost, STP timers
1.6.c PortFast, BPDUguard, BPDUfilter
1.6.d Loopguard and Rootguard
1.7 Configure and verify other LAN switching technologies
1.7.a PAN, RSPAN
1.8 Describe chassis virtualization and aggregation technologies
1.8.a Stackwise

The blueprint is more detailed but I don’t see a lot of things added. There are
some real world additions, such as SDM templates and Stackwise. This will be useful
for CCNP candidates at their jobs. VTP version 3 has been added and also topics
on chassis virtualization such as VSS and vPC. All versions of STP are included which
is to be expected. Nothing major added here in my opinion.

2.0 Infrastructure Security 20%

2.1 Configure and verify switch security features
2.1.a DHCP snooping
2.1.b IP Source Guard
2.1.c Dynamic ARP inspection
2.1.d Port security
2.1.e Private VLAN
2.1.f Storm control
2.2 Describe device security using Cisco IOS AAA with TACACS+ and RADIUS
2.2.a AAA with TACACS+ and RADIUS
2.2.b Local privilege authorization fallback

Not many addidions in this area, private VLANs and storm control is there.
DHCP snooping, DAI, port security and IP Source Guard are all important concepts
to secure the layer 2 part of the network.

3.0 Infrastructure Services 15%

3.1 Configure and verify first-hop redundancy protocols
3.1.a HSRP
3.1.b VRRP
3.1.c GLBP

Nothing has been added here, these protocols are well known and they are the
FHRP protocols that we still use.

Overall, I don’t think much has been added to the SWITCH exam. There are no
topics on wireless, voice and video which could indicate that these topics
are getting moved to other CCNP tracks.

Troubleshooting and Maintaining Cisco IP Networks (300-135)

This is the new version of the TSHOOT exam. The old version was 642-832. The
new blueprint is here.

The new blueprint is a lot more detailed than the old one.

1.0 Network Principles 5%

1.1 Use Cisco IOS troubleshooting tools
1.1.a Debug, conditional debug
1.1.b Ping and trace route with extended options
1.2 Apply troubleshooting methodologies
1.2.a Diagnose the root cause of networking issues (analyze symptoms, identify and describe root cause)
1.2.b Design and implement valid solutions
1.2.c Verify and monitor resolution

Nothing new here really, these are all tools expected to be known by a CCNP candidate.

2.0 Layer 2 Technologies 40%

2.1 Troubleshoot switch administration
2.1.a SDM templates
2.1.b Managing MAC address table
2.1.c Troubleshoot Err-disable recovery
2.2 Troubleshoot Layer 2 protocols
2.2.a CDP, LLDP
2.2.b UDLD
2.3 Troubleshoot VLANs
2.3.a Access ports
2.3.b VLAN database
2.3.c Normal, extended VLAN, voice VLAN
2.4 Troubleshoot trunking
2.4.a VTPv1, VTPv2, VTPv3, VTP pruning
2.4.b dot1Q
2.4.c Native VLAN
2.4.d Manual pruning
2.5 Troubleshoot EtherChannels
2.5.a LACP, PAgP, manual
2.5.b Layer 2, Layer 3
2.5.c Load balancing
2.5.d EtherChannel misconfiguration guard
2.6 Troubleshoot spanning tree
2.6.a PVST+, RPVST +, MST
2.6.b Switch priority, port priority, path cost, STP timers
2.6.c PortFast, BPDUguard, BPDUfilter
2.6.d Loopguard, Rootguard
2.7 Troubleshoot other LAN switching technologies
2.7.a SPAN, RSPAN
2.8 Troubleshoot chassis virtualization and aggregation technologies
2.8.a Stackwise

Most topics here are definitely familiar, VTPv3 has been added. Stackwise has also
been added to the blueprint as well as SDM templates. The other topics are not really
new but are specifically mentioned in the blueprint, which is a good clarification.

3.0 Layer 3 Technologies 40%

3.1 Troubleshoot IPv4 addressing and subnetting
3.1.a Address types (Unicast, broadcast, multicast, and VLSM)
3.1.b ARP
3.1.c DHCP relay and server
3.1.d DHCP protocol operations
3.2 Troubleshoot IPv6 addressing and subnetting
3.2.a Unicast
3.2.b EUI-64
3.2.c ND, RS/RA
3.2.d Autoconfig (SLAAC)
3.2.e DHCP relay and server
3.2.f DHCP protocol operations
3.3 Troubleshoot static routing
3.4 Troubleshoot default routing
3.5 Troubleshoot administrative distance
3.6 Troubleshoot passive interfaces
3.7 Troubleshoot VRF lite
3.8 Troubleshoot filtering with any protocol
3.9 Troubleshoot between any routing protocols or routing sources
3.10 Troubleshoot manual and autosummarization with any routing protocol
3.11 Troubleshoot policy-based routing
3.12 Troubleshoot suboptimal routing
3.13 Troubleshoot loop prevention mechanisms
3.13.a Route tagging, filtering
3.13.b Split-horizon
3.13.c Route poisoning
3.14 Troubleshoot RIPv2
3.15 Troubleshoot EIGRP neighbor relationship and authentication
3.16 Troubleshoot loop free path selection
3.16.a RD, FD, FC, successor, feasible successor
3.17 Troubleshoot EIGPR operations
3.17.a Stuck in active
3.18 Troubleshoot EIGRP stubs
3.19 Troubleshoot EIGRP load balancing
3.19.a Equal cost
3.19.b Unequal cost
3.20 Troubleshoot EIGRP metrics
3.21 Troubleshoot EIGRP for IPv6
3.22 Troubleshoot OSPF neighbor relationship and authentication
3.23 Troubleshoot network types, area types, and router types
3.23.a Point-to-point, multipoint, broadcast, nonbroadcast
3.23.b LSA types, area type: backbone, normal, transit, stub, NSSA, totally stub
3.23.c Internal router, backbone router, ABR, ASBR
3.23.d Virtual link
3.24 Troubleshoot OSPF path preference
3.25 Troubleshoot OSPF operations
3.26 Troubleshoot OSPF for IPv6
3.27 Troubleshoot BGP peer relationships and authentication
3.27.a Peer group
3.27.b Active, passive
3.27.c States and timers
3.28 Troubleshoot eBGP
3.28.a eBGP
3.28.b 4-byte AS number
3.28.c Private AS

There is added focus on IPv6, as expected. As mentioned before, 4 byte AS numbers
and private AS has been added. VRF lite is also included and I think these are
good additions.

4.0 VPN Technologies 5%

4.1 Troubleshoot GRE

GRE is still there, it’s worth 5% of the exam which is good to know.

5.0 Infrastructure Security 5%

5.1 Troubleshoot IOS AAA using local database
5.2 Troubleshoot device access control
5.2.a Lines (VTY, AUX, console)
5.2.b Management plane protection
5.2.c Password encryption
5.3 Troubleshoot router security features
5.3.a IPv4 access control lists (standard, extended, time-based)
5.3.b IPv6 traffic filter
5.3.c Unicast reverse path forwarding

These topics should not be new, access lists are still there, maybe with the addition of
IPv6. The other topics seem quite straight forward.

6.0 Infrastructure Services 5%

6.1 Troubleshoot device management
6.1.a Console and VTY
6.1.b Telnet, HTTP, HTTPS, SSH, SCP
6.1.c (T) FTP
6.2 Troubleshoot SNMP
6.2.a v2
6.2.b v3
6.3 Troubleshoot logging
6.3.a Local logging, syslog, debugs, conditional debugs
6.3.b Timestamps
6.4 Troubleshoot Network Time Protocol(NTP)
6.4.a NTP master, client, version 3, version 4
6.4.b NTP authentication
6.5 Troubleshoot IPv4 and IPv6 DHCP
6.5.a DHCP client, IOS DHCP server, DHCP relay
6.5.b DHCP options (describe)
6.6 Troubleshoot IPv4 Network Address Translation (NAT)
6.6.a Static NAT, Dynamic NAT, PAT
6.7 Troubleshoot SLA architecture
6.8 Troubleshoot tracking objects
6.8.a Tracking objects
6.8.b Tracking different entities (for example, interfaces, IPSLA results)

This section has some additions such as VTPv3, SNMPv3, NTP and IP SLA.
These are all good additions and something a CCNP level engineer would be expected
to know, at least at a basic level. All these topics are worth 5%, the same as GRE,
so they are not major topics.

Summary

CCNP RS version 2 is here, but there is no reason to panic. This post has taken a look
at the blueprint and it seems it is just a revamped version. It’s not a major overhaul.
A guesstimate would say that maybe 20% of the topics are new, the blueprint is mostly
the same but much more detailed and with weights, this makes it easer for a CCNP
candidate to build a study plan and study at the correct depth.

There are some additions such as VRF lite which are good real world additions.
In summary I think Cisco has done a good job of updating the CCNP curriculum.

Potential Issues with Multicast within a VLAN Spanning Switches

July 11, 2014 7 comments

Background

I ran into an interesting issue yesterday at work. There is a new video system
being installed, which takes the video output from computers, encodes it and
sends it as multicast to a controller. The controller then displays it on
a video wall. I had been told that the network has to support multicast.
As all the devices were residing in the same VLAN, I did not expect any issues.
However, the system was not able to receive the multicast. At first we expected
it could be the virtual environment and that the vSwitch did not support multicast,
because one server was deployed on the ESX cluster. The topology was this:

Snooping1

Multicast at Layer 2

Before describing the issue, let’s think about how multicast at layer 2 works.
The source will send to a multicast destination IP. This IP is the converted to a
destination MAC address. If the group is 227.0.0.1, this would map to the MAC
address 0100.5e00.0001. Switches forward multicast and broadcast frames to all
ports in a VLAN. This is not effective in the case of multicast as the traffic
may not have been requested by the host connected to a port receiving the
traffic.

IGMP Snooping

IGMP is the protocol used by hosts to indicate that they are interested in
receiving traffic for a multicast group. Cisco switches will by default run a
feature called IGMP snooping. Instead of forwarding multicast traffic to all ports
in the VLAN, the switch will only forward it to the ports that are interested in
receiving it. This works by “snooping” on the IGMP reports from the hosts, if the
switch sees an IGMP report on a port for a group, it knows that the host is interested
in receiving the traffic. The switch will then only forward that traffic to ports
where interested hosts reside. This is a nice feature but it can cause issues
if running multicast in the same VLAN between different switches.

The Issue

Going back to the topology at the start, the source is now sending multicast
traffic into the VLAN. The receiver has sent an IGMP report, because it wants
to receive the traffic.

Snooping2

The multicast traffic from the source reaches the 3650 stack but never leaves,
keeping the traffic from passing through the other switches to the receiver.
Why? The switches are running IGMP snooping, when the Catalyst 3550 at the far
right receives the IGMP report, it adds the port of receiver to receive traffic
for the multicast group. It does not however forward the IGMP report.
This means that the 3650 stack does not know that there are receivers that want
to receive this multicast traffic. The 3650 stack has no entry for the multicast
group in its snooping table. The traffic is essentially black holed.

The Fix

To understand the fix, you must first know about the mrouter port. The mrouter port
is a port leads to a multicast enabled router. For multicast traffic to pass through
IGMP snooping enabled switches, there must be a mrouter port. This port can be
statically assigned or can be dynamically learned. When the switch has a mrouter
port it will forward some of the IGMP reports out the mrouter port, which means that
the IGMP reports will reach the switch where the source is located. Not all reports
must be relayed, it’s enough that the switch learns that there are receivers out there.

Snooping3

In my case I configured the 3650 stack to be an IGMP querier.

SW-1#sh run | i querier
ip igmp snooping querier

This is a dynamic feature that when configured on a switch it considers itself
to be a mrouter, acting as a proxy instead of a router. It will send out general
queries and when the other switches sees this query, they will learn that as a
mrouter port.

SW-3#show ip igmp snooping mrouter 
Vlan    ports
----    -----
  10    Gi0/1(dynamic)

After turning on the IGMP querier feature, the issue was solved.
I hope this post can help someone in case you have issues with multicast in a
switched environment. There is an excellent post about it here from Cisco.

Routing Considerations in DDoS Protection Environments

July 7, 2014 2 comments

Lately I have done some studying for the CCDE and one of the things I was
looking at is how to protect against DDoS attacks. I’m not expecting it
to be a big topic for the CCDE but it has some interesting concepts relating
to routing. Take a look at the following topology:

Main

There is an attacker at the top left. R1 is the edge device and then there are a
few more routers, all peering BGP with the RR, which is R5. The server of interest
is 100.100.100.100 and there is a scrubbing device to the far right. All routers
peer iBGP from their loopbacks to the RR, including the scrubbing device.

Normally traffic to 100.100.100.100 would flow through R1 to R4 and then to the
server.

Normal_flow

The attacker now starts to flood the server with malicious traffic. This is detected
by the DDoS scrubbing device which starts to announce via BGP a more specific route
than the one advertised by R4. R4 normally advertises 100.100.100.0/24 but the
scrubbing device advertises 100.100.100.100/32. All the other routers will start
to forward traffic to 100.100.100.100 towards the scrubbing device. The traffic flow
is then like this:

Bad_flow1

The scrubbing device does it job, sends the traffic towards R3 and BAM!
Traffic is looped… Why? R3 has a route to 100.100.100.100/32 pointing at 6.6.6.6.
When the scrubbing device sends the traffic to R3 it gets looped back.

Loop

So this is what I find interesting. What can we do to bypass normal forwarding rules
and to keep the traffic from looping?

One method is to apply policy based routing. Put a route-map on the interface that
is facing the scrubbing device with an ACL for traffic that needs special treatment.

PBR

Create an extended ACL called “PBR_SPECIAL_TRAFFIC” where traffic that is destined
for 100.100.100.100 gets a next-hop of 2.2.2.2. The problem is though that this
would not work in this case because R2 has a route back towards R3. For this to
work, R2 would have to be excluded from the forwarding path and the server would
then be connected to R2. R2 would need a static route to override the BGP /32 route.

PBR2

This solution is a bit of a kludge and traffic can easily get looped if you are
not careful. Also, PBR always has the risk of becoming CPU forwarded if you configure
unsupported actions in the route-map.

Another solution is to create a GRE tunnel between the scrubbing device and the router
where the server resides.

GRE

The traffic would then be tunneled from the scrubbing device to the attaching router.
Because R4 has a /32 route in BGP, a static route should be added to overcome this.
Make sure that GRE is forwarded in hardware and account for the increased packet
size which could lead to fragmentation of not careful. Make sure that the MTU
supports GRE tunneling and a payload of at least 1460 bytes.

There is also the possibility of reinjecting the traffic into another VRF.
The VRF can have other routing than the global table. Either VRF Lite or
MPLS would be needed to support this solution.

VRF

The final solution seems like the best to me but it requires that you have
an infrastructure supporting the use of VRFs.

This post gives you a brief overview of how a DDoS protection appliance works
and how we sometimes must overcome the normal forwarding rules of the network.