Showing posts with label routing. Show all posts
Showing posts with label routing. Show all posts

Sunday, December 17, 2017

TIWA: How can you tell if PBR is routing packets?

Today I was asked: "How can you tell if Policy Based Routing is routing packets? Can you see it in the routing table or somewhere?"

I didn't have the correct answer for that at the time, so I looked it up, whipped up a lab and here we are :)



SPOILER ALERT: debug ip policy FTW!!!!

My co-worker was correct to assume, there is nothing in the routing table to tell you there is a policy based route installed or that packets are being forwarded in contrary to the routing table. Checking the routing table alone is not enough to determine the flow of packets. You must also check the ingress interface for policies.


To  build Policy Based Routing (PBR) you need 3 basic ingredients:
  1. access-list (standard or extended)
  2. route-map
  3. reachable next-hop

In the graphic above we are sourcing our traffic from the Loopback0 interface: 1.1.1.1 on R1 (on the right). In the middle is our PBR router. Using the default route traffic will traverse the PBR router using the next-hop of 10.10.10.6. We want to use Policy Based Routing to route traffic sourced from: 1.1.1.1 to the next-hop 20.20.20.6.


PBR: (configuration)


access-list 1 permit host 1.1.1.1

route-map PBR permit 10
 match ip address 1
 set ip next-hop 20.20.20.6

interface FastEthernet0/0
 ip policy route-map PBR


IOS: (verification)


To see if PBR is turned on or is in-use:


show ip interface fa0/0
show ip interface fa0/0 | i Policy

show ip policy

show cef interface fa0/0
show cef interface fa0/0 | i Policy|polic


To verify the configuration elements of PBR:


show route-map PBR

show access-list PBR

NOTE: Hit counts are good indicators your policy is getting hit.


To verify the traffic is hitting the Policy as it ingresses and interface:


debug ip policy

NOTE: Using the "debug" command on a policy which see's alot of traffic can blow up your console. Best practice to use ACL's to filter the "debug" output to a particular host or hosts.

Sunday, November 19, 2017

Future = Application Layer Networking

I was having a conversation with a peer about the future of networking. The foundation of the conversation revolved around SDN and the changes that SDN brings to network operators and engineers. The point was raised to me that 'engineers and operators of future networks won't need to have the granular low level understanding of bits, bytes and protocols.' As control of the network becomes more and more software driven the engineer/operator needs only high level understanding. My response to that is: Nothing could be further from the truth! My prediction for the future is: true application layer networking. Have a predictable and deterministic path through the network based on application only.

I think in the future, of application layer routing, we will need to incorporate some level of routing intelligence on each host/end device. I'm not sure exactly what that will look like yet but, I know it is not along the lines of OSPF or EIGRP.

In our current model, for most networks (home networks and small business networks) there is a single egress point where all traffic leaves your LAN to destinations on the internet.

In mid-sized business/enterprise you'll have redundant links a backups. You may have site-to-site tunnels with IPSEC connected remote sites but anything not on your LAN or part of your remote sites still egresses a single point to destinations on the internet.

Large businesses/Enterprises may have multiple egress points to the internet, all managed by lead engineers and operators with oversight from the senior engineers, involving multiple AS's and public IPv4 subnets that span the globe. This is expensive and the bottom line is, even with all the sophistication, the workstations and end devices are still taking the shortest path out of the network based on destination IP address and not on application specific characteristics.

Routers are doing destination based forwarding all over the globe. They are not making routing decisions based on the the type of traffic in the payload of the packet.

One thing I foresee SDN doing for us is bringing dynamic intelligence into routing. Having your controller understand the link requirements of protocols and identify those protocols as they are passing through the routers and forward them based on the application traffic they are carrying not just their destination IP address.

Another thing I believe the future holds for us is true multi-path routing, where end devices, even a common smart phone, can have multiple gateways and not just redundant default gateways, instead they would be application specific gateways. For example I could be connected to my cellular network, wifi and maybe a bunch of ad-hoc networks all at the same time. Perhaps those ad-hoc networks have gateways of their own and we can use them to egress to the internet essentially giving a device like our phone, multiple egress points. Letting our devices participate in the decision making process for routing and forwarding and how to best utilize the links available to it on a per-application basis.

Sorry I went off on a minor futuristic sci-fi routing tangent for a moment.

To bring this full circle, I feel like the engineers and operators of the future will actually need to know more about the inter-workings of each protocol more than just Layer 4. If the future is anything close to application layer networking, we will actually need to be closer to the bits and bytes to understand the protocol of the applications themselves in-order to programmatically and deterministically route them to their destinations.

P.S. - I'm not talking about getting rid of IP addresses but instead introduce more to forwarding than just the destination. I'm sure all the "every packet should be treated equal" people out there are going to have a fit with this.

Comments are welcomed.