Mailing List Archive

> Could you please let me know PBR (Policy Based Routing) functionality support is present in Quagga for both Static routes and Dynamic routing cases or not.

Quagga is mostly a routing protocol implementation. So you can apply policies to route distribution and acceptance within the limits of each protocol.

Quagga does not do forwarding. So if you want to make a forwarding decision based on any criteria besides the destination route, that is an forwarding plane (kernel, OS) issue. The route table is used for destination based forwarding.



> I am able to see the configuration option to configure the route-map config, but the next hop was not modified.
>
> Below is my config for static case, Please correct me if I missed any config.
>
> Before applying the PBR config, route table info
>
> K>* 0.0.0.0/0 <http://0.0.0.0/0> via 10.200.8.1,vmmgmt
> K>* 1.0.0.0/24 <http://1.0.0.0/24> via 2.0.0.1, enp2s0f3
> C>* 2.0.0.0/24 <http://2.0.0.0/24> is directly connected, enp2s0f3
> C>* 3.0.0.0/24 <http://3.0.0.0/24> is directly connected, enp2s0f1
> C>* 10.200.8.0/24 <http://10.200.8.0/24> is directly connected, vmmgmt
> S>* 25.25.0.0/24 <http://25.25.0.0/24> [1/0] via 2.0.0.20, enp2s0f3
> S>* 30.0.0.0/24 <http://30.0.0.0/24> [1/0] via 3.0.0.40, enp2s0f1
>
> Tried configuring PBR below two ways
> Using access list
> access-list anki permit 25.25.0.0/24 <http://25.25.0.0/24>
> !
> route-map qwe permit 5
> match ip address anki
> set ip next-hop 3.0.0.40
> Directly applying matching ip
> route-map aaa permit 2
> match ip address 25.25.0.0/24 <http://25.25.0.0/24>
> set ip next-hop 3.0.0.40

I would not call this policy based routing. It appears that you are trying to set a different next hop for a specific destination prefix. In other words, a static route.




>
> Thanks,
> Anki

Thanks TOM for sharing your views.

Policy can be anything right, we can set any matching criteria and its not mandatory to set 5-tupple value, Please correct me if my understanding is wrong.

I saw Cisco routers supports the PBR functionality for static routes as well, w.r.s.t static routes PBR will override the next hop address.
Does Quagga supports the PBR for static routes or it will only support route redistribution for dynamic protocols.


Thanks,
Ankaiah.

From: quagga-dev-bounces@lists.quagga.net [mailto:quagga-dev-bounces@lists.quagga.net] On Behalf Of Tom Samplonius
Sent: Tuesday, August 22, 2017 10:06 AM
To: Anki Abhi <anki.nakm@gmail.com>
Cc: quagga-users@lists.quagga.net; quagga-dev@lists.quagga.net
Subject: [quagga-dev 16647] Re: [quagga-users 14754] PBR(policy based routing in quagga)


** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution**



Could you please let me know PBR (Policy Based Routing) functionality support is present in Quagga for both Static routes and Dynamic routing cases or not.

Quagga is mostly a routing protocol implementation. So you can apply policies to route distribution and acceptance within the limits of each protocol.

Quagga does not do forwarding. So if you want to make a forwarding decision based on any criteria besides the destination route, that is an forwarding plane (kernel, OS) issue. The route table is used for destination based forwarding.




I am able to see the configuration option to configure the route-map config, but the next hop was not modified.

Below is my config for static case, Please correct me if I missed any config.

Before applying the PBR config, route table info

K>* 0.0.0.0/0<http://0.0.0.0/0> via 10.200.8.1,vmmgmt
K>* 1.0.0.0/24<https://clicktime.symantec.com/a/1/r4yQSxShvpue9IgFWCrOuj4OONKmAKuHtkdvpcfGVe8=?d=CNNCkzCHkeweOKcBwOa8BJFAuAsDMvoFz3vlR1QGBUSQ3lkHgdHZJF8udkl9JAPEjkafmdqMKGdzFgKzD4qk4wXyRDaE3V-zHJBglx0Ic3AMEP_qhEmhtmHpjXRBRhFK01yqzfWTG2h7FOCf8Te8153a9llLSjPEWocsB-8W3_3s6vI57Iw8FXag6hTNBRt3MzLfcLCEp1jxH4VTJ8deIgsXG2za2329kSqeKBJJzamLzjrD5hiZO6NVvoMQQ4anpc2WyeJ8hoJeiCuabftD6NwBKVDAkecEuj8YXckPeVyszVln_MHN9clb42c9Z8Sl-ouNRMxfuwyOL4Q7yJJCXLGy4H_K62S6HzQsiru2qtt_AU-pexCFSDtGfUdT3slNWOfn1djd8hSfreZ3rvovldpZoZbKTYKrEaEGSDQoY264a_R4e8VnTilBICbZa_adtfU-fOmI08twv94%3D&u=http%3A%2F%2F1.0.0.0%2F24> via 2.0.0.1, enp2s0f3
C>* 2.0.0.0/24<https://clicktime.symantec.com/a/1/ohTQSwVBWF0qxpGSI8p3oNIztnvDi9LjEdrm0WVhnRw=?d=CNNCkzCHkeweOKcBwOa8BJFAuAsDMvoFz3vlR1QGBUSQ3lkHgdHZJF8udkl9JAPEjkafmdqMKGdzFgKzD4qk4wXyRDaE3V-zHJBglx0Ic3AMEP_qhEmhtmHpjXRBRhFK01yqzfWTG2h7FOCf8Te8153a9llLSjPEWocsB-8W3_3s6vI57Iw8FXag6hTNBRt3MzLfcLCEp1jxH4VTJ8deIgsXG2za2329kSqeKBJJzamLzjrD5hiZO6NVvoMQQ4anpc2WyeJ8hoJeiCuabftD6NwBKVDAkecEuj8YXckPeVyszVln_MHN9clb42c9Z8Sl-ouNRMxfuwyOL4Q7yJJCXLGy4H_K62S6HzQsiru2qtt_AU-pexCFSDtGfUdT3slNWOfn1djd8hSfreZ3rvovldpZoZbKTYKrEaEGSDQoY264a_R4e8VnTilBICbZa_adtfU-fOmI08twv94%3D&u=http%3A%2F%2F2.0.0.0%2F24> is directly connected, enp2s0f3
C>* 3.0.0.0/24<https://clicktime.symantec.com/a/1/NdK02snySpEfguF8FZyivNYzFgsksmVoLBrL_QemtLg=?d=CNNCkzCHkeweOKcBwOa8BJFAuAsDMvoFz3vlR1QGBUSQ3lkHgdHZJF8udkl9JAPEjkafmdqMKGdzFgKzD4qk4wXyRDaE3V-zHJBglx0Ic3AMEP_qhEmhtmHpjXRBRhFK01yqzfWTG2h7FOCf8Te8153a9llLSjPEWocsB-8W3_3s6vI57Iw8FXag6hTNBRt3MzLfcLCEp1jxH4VTJ8deIgsXG2za2329kSqeKBJJzamLzjrD5hiZO6NVvoMQQ4anpc2WyeJ8hoJeiCuabftD6NwBKVDAkecEuj8YXckPeVyszVln_MHN9clb42c9Z8Sl-ouNRMxfuwyOL4Q7yJJCXLGy4H_K62S6HzQsiru2qtt_AU-pexCFSDtGfUdT3slNWOfn1djd8hSfreZ3rvovldpZoZbKTYKrEaEGSDQoY264a_R4e8VnTilBICbZa_adtfU-fOmI08twv94%3D&u=http%3A%2F%2F3.0.0.0%2F24> is directly connected, enp2s0f1
C>* 10.200.8.0/24<http://10.200.8.0/24> is directly connected, vmmgmt
S>* 25.25.0.0/24<https://clicktime.symantec.com/a/1/P4jmt8yo-cOZaeIl2-watzBUbk1V8_LJiERAbH1wFJ4=?d=CNNCkzCHkeweOKcBwOa8BJFAuAsDMvoFz3vlR1QGBUSQ3lkHgdHZJF8udkl9JAPEjkafmdqMKGdzFgKzD4qk4wXyRDaE3V-zHJBglx0Ic3AMEP_qhEmhtmHpjXRBRhFK01yqzfWTG2h7FOCf8Te8153a9llLSjPEWocsB-8W3_3s6vI57Iw8FXag6hTNBRt3MzLfcLCEp1jxH4VTJ8deIgsXG2za2329kSqeKBJJzamLzjrD5hiZO6NVvoMQQ4anpc2WyeJ8hoJeiCuabftD6NwBKVDAkecEuj8YXckPeVyszVln_MHN9clb42c9Z8Sl-ouNRMxfuwyOL4Q7yJJCXLGy4H_K62S6HzQsiru2qtt_AU-pexCFSDtGfUdT3slNWOfn1djd8hSfreZ3rvovldpZoZbKTYKrEaEGSDQoY264a_R4e8VnTilBICbZa_adtfU-fOmI08twv94%3D&u=http%3A%2F%2F25.25.0.0%2F24> [1/0] via 2.0.0.20, enp2s0f3
S>* 30.0.0.0/24<https://clicktime.symantec.com/a/1/NnVFgloFTmBev2kxcCBWD3pKam0zqyURsFGAYjoZI_s=?d=CNNCkzCHkeweOKcBwOa8BJFAuAsDMvoFz3vlR1QGBUSQ3lkHgdHZJF8udkl9JAPEjkafmdqMKGdzFgKzD4qk4wXyRDaE3V-zHJBglx0Ic3AMEP_qhEmhtmHpjXRBRhFK01yqzfWTG2h7FOCf8Te8153a9llLSjPEWocsB-8W3_3s6vI57Iw8FXag6hTNBRt3MzLfcLCEp1jxH4VTJ8deIgsXG2za2329kSqeKBJJzamLzjrD5hiZO6NVvoMQQ4anpc2WyeJ8hoJeiCuabftD6NwBKVDAkecEuj8YXckPeVyszVln_MHN9clb42c9Z8Sl-ouNRMxfuwyOL4Q7yJJCXLGy4H_K62S6HzQsiru2qtt_AU-pexCFSDtGfUdT3slNWOfn1djd8hSfreZ3rvovldpZoZbKTYKrEaEGSDQoY264a_R4e8VnTilBICbZa_adtfU-fOmI08twv94%3D&u=http%3A%2F%2F30.0.0.0%2F24> [1/0] via 3.0.0.40, enp2s0f1

Tried configuring PBR below two ways

1. Using access list
access-list anki permit 25.25.0.0/24<https://clicktime.symantec.com/a/1/P4jmt8yo-cOZaeIl2-watzBUbk1V8_LJiERAbH1wFJ4=?d=CNNCkzCHkeweOKcBwOa8BJFAuAsDMvoFz3vlR1QGBUSQ3lkHgdHZJF8udkl9JAPEjkafmdqMKGdzFgKzD4qk4wXyRDaE3V-zHJBglx0Ic3AMEP_qhEmhtmHpjXRBRhFK01yqzfWTG2h7FOCf8Te8153a9llLSjPEWocsB-8W3_3s6vI57Iw8FXag6hTNBRt3MzLfcLCEp1jxH4VTJ8deIgsXG2za2329kSqeKBJJzamLzjrD5hiZO6NVvoMQQ4anpc2WyeJ8hoJeiCuabftD6NwBKVDAkecEuj8YXckPeVyszVln_MHN9clb42c9Z8Sl-ouNRMxfuwyOL4Q7yJJCXLGy4H_K62S6HzQsiru2qtt_AU-pexCFSDtGfUdT3slNWOfn1djd8hSfreZ3rvovldpZoZbKTYKrEaEGSDQoY264a_R4e8VnTilBICbZa_adtfU-fOmI08twv94%3D&u=http%3A%2F%2F25.25.0.0%2F24>
!
route-map qwe permit 5
match ip address anki
set ip next-hop 3.0.0.40

1. Directly applying matching ip
route-map aaa permit 2
match ip address 25.25.0.0/24<https://clicktime.symantec.com/a/1/P4jmt8yo-cOZaeIl2-watzBUbk1V8_LJiERAbH1wFJ4=?d=CNNCkzCHkeweOKcBwOa8BJFAuAsDMvoFz3vlR1QGBUSQ3lkHgdHZJF8udkl9JAPEjkafmdqMKGdzFgKzD4qk4wXyRDaE3V-zHJBglx0Ic3AMEP_qhEmhtmHpjXRBRhFK01yqzfWTG2h7FOCf8Te8153a9llLSjPEWocsB-8W3_3s6vI57Iw8FXag6hTNBRt3MzLfcLCEp1jxH4VTJ8deIgsXG2za2329kSqeKBJJzamLzjrD5hiZO6NVvoMQQ4anpc2WyeJ8hoJeiCuabftD6NwBKVDAkecEuj8YXckPeVyszVln_MHN9clb42c9Z8Sl-ouNRMxfuwyOL4Q7yJJCXLGy4H_K62S6HzQsiru2qtt_AU-pexCFSDtGfUdT3slNWOfn1djd8hSfreZ3rvovldpZoZbKTYKrEaEGSDQoY264a_R4e8VnTilBICbZa_adtfU-fOmI08twv94%3D&u=http%3A%2F%2F25.25.0.0%2F24>
set ip next-hop 3.0.0.40

I would not call this policy based routing. It appears that you are trying to set a different next hop for a specific destination prefix. In other words, a static route.





Thanks,
Anki


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

On 08/22/17 06:24, ankaiah.nallamekala@wipro.com wrote:
> Policy can be anything right, we can set any matching criteria and its
> not mandatory to set 5-tupple value, Please correct me if my
> understanding is wrong.

If you're doing routing on something other than destination address,
then that's an OS kernel-level feature. You should look into iptables,
IP-Filter, ipchains, or whatever your local OS supports for rule-based
packet filtering/rewriting.

That sort of thing isn't really related to a routing protocol suite such
as Quagga.

--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

Thanks James.

Could you please let me know Quagga version which supports route redistribution(PBR) in BGP.

Thanks,
Ankaiah.

-----Original Message-----
From: James Carlson [mailto:carlsonj@workingcode.com]
Sent: Tuesday, August 22, 2017 5:43 PM
To: Ankaiah Nallamekala (MFG & Tech) <ankaiah.nallamekala@wipro.com>; Tom Samplonius <tom@samplonius.org>; Anki Abhi <anki.nakm@gmail.com>
Cc: quagga-users@lists.quagga.net; quagga-dev@lists.quagga.net
Subject: Re: [quagga-dev 16649] Re: [quagga-users 14754] PBR(policy based routing in quagga)

** This mail has been sent from an external source. Treat hyperlinks and attachments in this email with caution**

On 08/22/17 06:24, ankaiah.nallamekala@wipro.com wrote:
> Policy can be anything right, we can set any matching criteria and its
> not mandatory to set 5-tupple value, Please correct me if my
> understanding is wrong.

If you're doing routing on something other than destination address, then that's an OS kernel-level feature. You should look into iptables, IP-Filter, ipchains, or whatever your local OS supports for rule-based packet filtering/rewriting.

That sort of thing isn't really related to a routing protocol suite such as Quagga.

--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com ______________________________________________________________________
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

On 08/22/17 08:29, ankaiah.nallamekala@wipro.com wrote:
> Thanks James.
>
> Could you please let me know Quagga version which supports route redistribution(PBR) in BGP.

All versions do; redistribution is a core feature. But I suspect that
you have other requirements and you should post details to the list of
exactly what you're trying to do (with detailed examples) and what you
expect the system to do for you. It would probably also help if you
could post more about the OS you're using, because Quagga doesn't live
on an island.

It doesn't redirect traffic based on ToS/QoS, nor based on source
address, nor on IP header options, nor packet length, nor based on
transport (layer-4) protocol, nor on other layer-4 features (such as
port numbers), nor on any higher level protocol feature (e.g., URL). It
really can't do that unless the underlying kernel interfaces were to
support it. It doesn't, in fact, handle *any* data packets -- it just
computes data ("routes") to send to the kernel. It's a control plane
tool, not data plane.

Routing in a datagram network is done based on destination address.
(And, possibly, interface and VRF tags.)

If those other things are the sorts of things you're trying to do, then
it sounds like you're looking for OS features for packet redirection and
rewriting, as previously described. I.e., something in the data plane.

These things certainly interact with each other in network design, but
they're logically distinct. (Even with Cisco, you can't redistribute
"policies" via BGP, as far as I know.)

--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev