To avoid asymmetric routing

chongch01chongch01 Member Posts: 41 ■■□□□□□□□□
Hi,

I have a scenario here

Branch has 1 JSeries & 1 SSG. JSeries is connected to 2MB leased line (IPVPN) & SSG is connected to ADSL (ADSL network & extranet to IPVPN).

Customer requested critical traffics to HQ using leased line & non-critical traffics via ADSL.

branch ---->LL
(IPVPN)
LL--HQ
|
> ADSL ---(DSL net - link to ipvpn)

Problem: returning path for non-critical traffic always go via IPVPN & back to branch's leased line because IPVPN has better preference than ADSL network & it cause asymmetric routing. We need to ensure that the ADSL traffics from branch to HQ will have the same path to go back to branch

Do u have the solutions ? & URL

Comments

  • stuh84stuh84 Member Posts: 503
    Use more specific routes for traffic destined to not go via the leased line?
    Work In Progress: CCIE R&S Written

    CCIE Progress - Hours reading - 15, hours labbing - 1
  • AldurAldur Member Posts: 1,460
    You're trying to influence how the return traffic will flow, which is not the easiest thing to do. Is BGP in use here? BGP has many functions that'll allow you the flow of return traffic.
    "Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."

    -Bender
  • chongch01chongch01 Member Posts: 41 ■■□□□□□□□□
    Ya, not easy because the SP cloud always consider the IPVPN cloud instead of DSL cloud due to their local-pref set by SP. Hence returning traffic will always choose IPVPN. The lab is yet to ready & might consider using tunnel.

    thanks
  • APAAPA Member Posts: 959
    Are you able to ensure the non-critical traffic that is using the extranet VPN via the SSG appears as a source address only reachable via the SSG VPN?

    It doesn't sound like you have BGP in operation so that throws that out the window in this instance.

    Tunneling could be your answer here but the tunnel endpoint will need to be before the HQ router, therefore encaps\deencaps will occur at this point only, therefore hiding the original src/dst address before routing through the VPN, also you would need to ensure that the tunnel endpoint is only reachable via the SSG VPN...then exposing the real src\dest address of the packet after it has passed through the IPVPN and been de-encapsulated on the SSG VPN.

    Very hacky.... but it would work..... Actually routing traffic onto the tunnel could be interesting though.... you could run a routing protocol between the tunnel endpoints and ensure the destinations for non-critical traffic are reachable though it.... or perhaps you would need to policy route the non-critical interesting traffic through the tunnel.

    CCNA | CCNA:Security | CCNP | CCIP
    JNCIA:JUNOS | JNCIA:EX | JNCIS:ENT | JNCIS:SEC
    JNCIS:SP | JNCIP:SP
  • APAAPA Member Posts: 959
    Aldur wrote: »
    You're trying to influence how the return traffic will flow, which is not the easiest thing to do.

    Ain't that the truth.... :)

    CCNA | CCNA:Security | CCNP | CCIP
    JNCIA:JUNOS | JNCIA:EX | JNCIS:ENT | JNCIS:SEC
    JNCIS:SP | JNCIP:SP
  • chongch01chongch01 Member Posts: 41 ■■□□□□□□□□
    problem resolved by enabling NAT at SSG
Sign In or Register to comment.