Routing

 View Only
last person joined: 5 hours ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Broken communication with FBF and next-table for route leaking

    Posted 28 days ago

    Hi,

    I have an MX960 configured as a BNG with two VRFs: one for subscriber access and another for Internet access. Some subscribers have static public IP addresses assigned by Radius, and their traffic needs to be forwarded directly to the Internet VRF. I achieve this by using a forwarding-options input filter FBF. In the Internet VRF, I return the subscriber traffic using a static route with next-table.

    At the subscribers' endpoints, I can ping 8.8.8.8 without any issues. However, web browsing is not working properly; some websites load while others do not. I have ruled out problems with MTU and TCP-MSS. Additionally, I noticed that the subscribers' Internet access works fine when both subscriber and Internet access are in the global routing instance.

    The configuration is some like this:

    firewall {
        family inet {
            filter REDIRECT-SUBS-TRAFFIC {
                term NO_REDIRECT {
                    from {
                        destination-prefix-list {
                            PL-NO-REDIRECT;
                        }
                    }
                    then {
                        log;
                        accept;
                    }
                }
                term SUBSCRIBERS-TO-INTERNET {
                    from {
                        source-prefix-list {
                            PL-SUBSCRIBERS-PUBLIC-POOLS;
                        }
                    }
                    then {                  
                        log;
                        routing-instance VRF-INTERNET;
                    }
                }
                term ACCEPT-ALL {
                    then accept;
                }
            }
        }
    }

    prefix-list PL-SUBSCRIBERS-PUBLIC-POOLS {
        10.10.2.0/24;
    }
    prefix-list PL-NO-REDIRECT {
        10.99.99.0/30;
        10.145.0.2/32;
        10.245.144.6/32;
    }


    routing-instances {
        VRF-INTERNET {
            instance-type vrf;
            routing-options {
                static {
                    route 0.0.0.0/0 next-hop 10.55.55.1;
                    route 10.10.2.0/24 next-table VRF-ACCESS-SUBs.inet.0;
                }
            }
            interface ge-1/1/9.555;
            route-distinguisher 66666:6101;
            vrf-target {
                import target:66666:6101;
                export target:66666:6101;
            }
            vrf-table-label;
        }
        VRF-ACCESS-SUBs {
            instance-type vrf;
            routing-options {
                router-id 10.245.144.6;
            }
            forwarding-options {
                family inet {               
                    filter {
                        input REDIRECT-SUBS-TRAFFIC;
                    }
                }
            }
            route-distinguisher 66666:6099;
            vrf-target {
                import target:66666:6099;
                export target:66666:6099;
            }
        }
    }

    Plaese, can anyone explain why internet communication breaks when I use this route leaking between VRFs?

    Thanks in advance.



    ------------------------------
    PABLOXJE
    ------------------------------


  • 2.  RE: Broken communication with FBF and next-table for route leaking

    Posted 27 days ago

    I do not have any comment about the FBF, but note that it is possible to return the name of the routing-instance from RADIUS, so you should not need to do FBF.

    /Per



    ------------------------------
    PER GRANATH
    ------------------------------



  • 3.  RE: Broken communication with FBF and next-table for route leaking

    Posted 24 days ago

    Hi Per,

    Thanks for you answer. 

    We are assigning the name of the VRF through Radius but  due to design requirements, subscribers' PPPoE access must be in their own VRF. From the subscribers' VRF we decide where to send the traffic through FBF. Subscribers with public IP pass directly to the Internet VRF and subscribers requiring CGNAT pass to a CGNAT VRF.

    We have a topology like this:

    ONT-----OLT-----PE------P-------BNG------INTERNET_EDGE

    We connect the OLT through a Pseudowire

    We have replicated the problem in a laboratory environment and realized that the problem focuses on the PPPoE access of the subscriber. We have detected that the problem occurs when PPPoE access is in a VRF. When the PPPoE access of the subscriber is in the Global Routing Table this problem does not occur.

    Do you know of any best practices for this type of deployment?

    Thanks in advance.



    ------------------------------
    PABLOXJE
    ------------------------------



  • 4.  RE: Broken communication with FBF and next-table for route leaking

    Posted 24 days ago

    If ICMP is working, and some web browsing, but not all, then perhaps it is not a pure FBF problem. Seems that perhaps the traffic is going through some NAT anyway. Perhaps do some traceroutes in both directions, to see where traffic really is.

    Still, still seems that different subs should be sent to different routing-instances using RADIUS.



    ------------------------------
    PER GRANATH
    ------------------------------